Multi Project Management

Multi Project Management

woensdag 25 maart 2015

Are KPI’s blocking improvement in project management?

A lot of effort is done in organizations to improve performance. Introducing project management is one of them. I have experienced the introduction of a lot of KPI’s in this field. But in parallel I see also a lot of disappointing results. In my view the usage of KPI’s is not always helping but constraining organizations in the performance improvement. Let me show you why KPI’s don’t help and also give you a direction of the solution.
It is well accepted to control projects on budget, time and scope. Nothing wrong with that. As long as we do this on project level. But, what happens is that these KPI’s are getting deployed to individuals. They are used to control employees on activity level. You have to deliver the activity on time, you have to explain why you used 40 hours instead of the 30 hours estimated. KPI’s on activity level become targets. People respond immediately to targets. They try to protect themselves against failure of meeting the targets. In this struggle between management and employees the result is typically more detailed planning and control. Eventually this proces will only increase projects duration and budget.
A lot of managers think detailled planning and control is the best way to improve a project management environment, but it is not. It will make it even worse. Funny thing is that software suppliers support this micro direction.
Let’s reflect on the situation. In project management the level of uncertainty is high. The scope is not completely clear and estimation of needed budget and time is complicated. In such a situation detailled planning and control is not going to help. Instead, we should give people information which will help them to make better decisions. In the 80-ties Decision Support Systems (DSS) were introduced. I plea to re-introduce the concept of DSS in its pure form.
Let me give an example with the following graph.
processed flow
figure 1. Historical development of the capacity (Blue), load (Red) and output (green) of a group.
The information in the graph shows that in the beginning, the group achieved an output of 2 man-hours per hour (green line) while the capacity was 4.8 and the estimated load was 6! This load is the total amount of work coming to this team from all active projects. In the KPI-world the group had to defend themselves why they did not achieve an output of 6 or at least 4.8 man-hours per hour.
I would like to turn it around. Let’s use this information as a DSS and start a discussion within the group about the needed versus realized output. The objective is to balance the load and output. The group responded as follows. First they tried to focus more on their work. They did this by reducing the amount of distraction coming from outside the projects. Within 2 weeks the output immediately improved to more than 3 man-hours per hour. After this the group discussed with management to reduce the total load to the level of the assumed capacity. As they were not any longer overloaded, they were able to even further improve the output.
What we see is that the information shown in this graph can actually help people to solve situations of overload combined with the associated poor productivity. The information will help them to immediately see the effect of any interventions. It is really supporting the right decisions. In this case the output more than doubled! Just to make sure, this graph is not made up, this actually happened at our customers.
In order to support our claim to stop using KPI’s / targets on personal level and to go back to Decision Support Systems, co-owner Albert Ponsteen and myself both started a PhD research study to investigate this hypothesis. So far our clients have substantiated the hypothesis. And they love the results.
As a closing remark, the graph above is coming from our DSS software FLOW MPM which is connected to ERP, PPM or Workflow systems from our clients. Typically all the needed data is already available in the databases from our clients. This means fast implementations and relatively small impact on the way people work with their current systems.
Jan Willem Tromp

Geen opmerkingen: