We commonly rate a project’s success based on whether it is on time and in budget. But, as common as these KPIs are, they may not be good measures. As Jan Fischbach has shown, delays and budget overruns can look like project failure even though the benefits vastly exceed the costs and vastly outmatch the benefits of an on-time project./1/ Furthermore, a project can be on time, but lousy at using the available time efficiently. Isn’t something wrong when a project only requires small total effort, but takes months to finish?
Fortunately, there is a simple way to measure the time efficiency of projects. I’ll call this indicator “project duration efficiency” (PDE), which compares effort (hours or days worked) with duration (calendar time)./2/
In an ideal world, all effort would flow seamlessly from task to task, and in optimally matched, parallel streams. Thus, the project duration would be the sum of the effort of one stream: 20 days invested by 3 persons each of would result in a finished product in 20 days’ time (and a total effort of 60 person days). Put another way, every hour spent on the project contributed productively to the product’s creation. This utopia would look like this:
The PDE is a simple calculation:
To keep the results comparable, we normalize the effort by dividing the number of people involved by the total effort./3/ A project with 6 persons working a total of 120 person days would have a normalized effort of 20 days. If this project takes 8 weeks (40 workdays) in duration to complete, its PDE equals 20/40 or 0.5. It might look like this:
So, the final, full equation would be:
The best possible result is 1, although this value is rare.
Why is this KPI important? It shows us how efficiently we are using calendar time for delivering our results. It is based on the premise “fast delivery means early benefits”. PDE thus helps us see the cost of delay (CoD) in a project. CoD occurs when we deliver a project’s results later than they could have been delivered. It is equal to the benefits we forego by not having the product on the market. For example, a company is developing an innovative widget. If it forecasts selling €10,000 worth of new widgets each day, then each day that the project is late incurs a CoD of €10,000./4/
In the project example above, the “possible completion” date is the point at which we could have started reaping the benefits if the work had been organized to eliminate the gray days. I am aware that this ideal situation will appear impossible to many readers./5/ But, Scrum teams achieve massive productivity gains precisely through the compression of the gray boxes to near zero./6/
The measure does not distinguish between time lost due to poor scheduling, from project delays whatever their cause. From a CoD perspective, it doesn’t matter why we deliver late, our customers still can’t buy the widget. PDE is thus the starting point for the investigation. Of course, every project manager or team feels any delay with full force. We’re under pressure to deliver, and trivial delays like scheduling a workshop can drive us bats. We know it’s endangering the delivery date, and we know this long before the steering committee has asked about it. So why do we need to calculate the PDE?
PDE has many uses. With it, we can compare projects to each other objectively, since PDE is calculated from simple, observable facts. In a status report, it highlights schedule slippage to the steering committee, hopefully provoking a thoughtful discussion about priorities. And, in a large project, it might signal trouble ahead before it is too late. Across the whole company, the PDE can reveal that overall throughput is suffering. The cause is likely too much work in progress. Again, a review of priorities is in order.
PDE also helps in evaluating and adjusting estimates. Let’s assume, for example, that a company completed 25 projects last year. The average PDE value was 0.15, with most projects falling between 0.10 and 0.20. This company’s projects will thus have durations of 5 to 10 times their normalized efforts. If a director says, “we’ve budgeted 5 people for a total of 200 days, I expect this project to be finished in 2 months”, we can show that this is unrealistic.
This approach is similar to and compatible with velocity calculations in agile methods. Please note, PDE does not attempt to measure productivity in terms of completed items (say, story points). Rather, it’s focus is on time slippage only. Like velocity, however, it gives a transparent view of our schedule performance. That way, we know what we’re able to do under the current circumstances. Like any good KPI, it's just an honest measure. What we do with the result is up to us.
As always, feedback is welcome. What is the PDE of the projects in your organization?
Part 2 of this series, you may find here: Measuring Project Duration Efficiency pt. 2 – a practical example
/1/ Jan Fischbach, “Die zwei wichtigsten Regeln für IT-Projekte, Wie Sie mit zwei Regeln mehr Erfolg und weniger Stress haben”, appearing in HR Performance, S. 60-63, Ausgabe 6/2014, which can be ordered at www.datakontext.com.
/2/ This metric is similar to value stream calculations in Lean approaches.
/3/ Who do we include? I recommend including everyone who is invoicing or actively recording her time for the project. The project manager should be included. The steering committee will usually be excluded. Most important for cross-project comparisons is a consistently applied definition.
We can find the data for PDE easily. Most companies a system for recording time, and the project manager is often responsible for controlling the time and/or preparing the data for invoicing. If no time recording is available, a simple tally sheet could be posted in the project office. To figure the duration take a look at a calendar: when was the kick-off and what’s the date today?
Note, we count the persons involved and not the number of planned FTEs. To understand why, let’s assume the example above is going exactly according to plan. Thus, each person is working a scheduled 50% for the project. With that we would tempted to divide the total effort by 3 FTEs instead of 6 persons. The result would be 40 days of normalized effort, for a PDE of 1. With that, the index tells us nothing.
/4/ The best source on CoD is Donald G Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (Redondo Beach, Calif.: Celeritas, 2009).
Cost of delay is a vital measure for prioritizing products (or projects). The product with the highest cost of delay should be finished first, so that we can deliver it as early as possible.
/5/ Perhaps, you might argue, the team is working effectively on a second project during the gray days. Yes, of course, this seems efficient from a resource point of view. But, from a benefits or a cost-of-delay perspective it is not. We need to recognize that project 2 is also delayed, namely, during the colored days of project 1. So, why not dedicate the whole team first to project 1 and then to project 2? That way, we start to realize the benefits from project 1 after 20 workdays. The benefits from project 2 come after 40 workdays in either scenario.
/6/ The compression is possible for main two reasons: 1) the teams are dedicated to a product and are thus not distracted by multiple projects; 2) the teams are cross-functional, so that when one person gets delayed, others can step in and take on their tasks. See Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time (New York: Crown Business, 2014).
Fortunately, there is a simple way to measure the time efficiency of projects. I’ll call this indicator “project duration efficiency” (PDE), which compares effort (hours or days worked) with duration (calendar time)./2/
In an ideal world, all effort would flow seamlessly from task to task, and in optimally matched, parallel streams. Thus, the project duration would be the sum of the effort of one stream: 20 days invested by 3 persons each of would result in a finished product in 20 days’ time (and a total effort of 60 person days). Put another way, every hour spent on the project contributed productively to the product’s creation. This utopia would look like this:
The PDE is a simple calculation:
PDE = normalized effort / duration
To keep the results comparable, we normalize the effort by dividing the number of people involved by the total effort./3/ A project with 6 persons working a total of 120 person days would have a normalized effort of 20 days. If this project takes 8 weeks (40 workdays) in duration to complete, its PDE equals 20/40 or 0.5. It might look like this:
So, the final, full equation would be:
PDE = (total effort / number of people working on project) / duration
The best possible result is 1, although this value is rare.
Why is this KPI important? It shows us how efficiently we are using calendar time for delivering our results. It is based on the premise “fast delivery means early benefits”. PDE thus helps us see the cost of delay (CoD) in a project. CoD occurs when we deliver a project’s results later than they could have been delivered. It is equal to the benefits we forego by not having the product on the market. For example, a company is developing an innovative widget. If it forecasts selling €10,000 worth of new widgets each day, then each day that the project is late incurs a CoD of €10,000./4/
In the project example above, the “possible completion” date is the point at which we could have started reaping the benefits if the work had been organized to eliminate the gray days. I am aware that this ideal situation will appear impossible to many readers./5/ But, Scrum teams achieve massive productivity gains precisely through the compression of the gray boxes to near zero./6/
The measure does not distinguish between time lost due to poor scheduling, from project delays whatever their cause. From a CoD perspective, it doesn’t matter why we deliver late, our customers still can’t buy the widget. PDE is thus the starting point for the investigation. Of course, every project manager or team feels any delay with full force. We’re under pressure to deliver, and trivial delays like scheduling a workshop can drive us bats. We know it’s endangering the delivery date, and we know this long before the steering committee has asked about it. So why do we need to calculate the PDE?
PDE has many uses. With it, we can compare projects to each other objectively, since PDE is calculated from simple, observable facts. In a status report, it highlights schedule slippage to the steering committee, hopefully provoking a thoughtful discussion about priorities. And, in a large project, it might signal trouble ahead before it is too late. Across the whole company, the PDE can reveal that overall throughput is suffering. The cause is likely too much work in progress. Again, a review of priorities is in order.
PDE also helps in evaluating and adjusting estimates. Let’s assume, for example, that a company completed 25 projects last year. The average PDE value was 0.15, with most projects falling between 0.10 and 0.20. This company’s projects will thus have durations of 5 to 10 times their normalized efforts. If a director says, “we’ve budgeted 5 people for a total of 200 days, I expect this project to be finished in 2 months”, we can show that this is unrealistic.
This approach is similar to and compatible with velocity calculations in agile methods. Please note, PDE does not attempt to measure productivity in terms of completed items (say, story points). Rather, it’s focus is on time slippage only. Like velocity, however, it gives a transparent view of our schedule performance. That way, we know what we’re able to do under the current circumstances. Like any good KPI, it's just an honest measure. What we do with the result is up to us.
As always, feedback is welcome. What is the PDE of the projects in your organization?
Part 2 of this series, you may find here: Measuring Project Duration Efficiency pt. 2 – a practical example
/1/ Jan Fischbach, “Die zwei wichtigsten Regeln für IT-Projekte, Wie Sie mit zwei Regeln mehr Erfolg und weniger Stress haben”, appearing in HR Performance, S. 60-63, Ausgabe 6/2014, which can be ordered at www.datakontext.com.
/2/ This metric is similar to value stream calculations in Lean approaches.
/3/ Who do we include? I recommend including everyone who is invoicing or actively recording her time for the project. The project manager should be included. The steering committee will usually be excluded. Most important for cross-project comparisons is a consistently applied definition.
We can find the data for PDE easily. Most companies a system for recording time, and the project manager is often responsible for controlling the time and/or preparing the data for invoicing. If no time recording is available, a simple tally sheet could be posted in the project office. To figure the duration take a look at a calendar: when was the kick-off and what’s the date today?
Note, we count the persons involved and not the number of planned FTEs. To understand why, let’s assume the example above is going exactly according to plan. Thus, each person is working a scheduled 50% for the project. With that we would tempted to divide the total effort by 3 FTEs instead of 6 persons. The result would be 40 days of normalized effort, for a PDE of 1. With that, the index tells us nothing.
/4/ The best source on CoD is Donald G Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (Redondo Beach, Calif.: Celeritas, 2009).
Cost of delay is a vital measure for prioritizing products (or projects). The product with the highest cost of delay should be finished first, so that we can deliver it as early as possible.
/5/ Perhaps, you might argue, the team is working effectively on a second project during the gray days. Yes, of course, this seems efficient from a resource point of view. But, from a benefits or a cost-of-delay perspective it is not. We need to recognize that project 2 is also delayed, namely, during the colored days of project 1. So, why not dedicate the whole team first to project 1 and then to project 2? That way, we start to realize the benefits from project 1 after 20 workdays. The benefits from project 2 come after 40 workdays in either scenario.
/6/ The compression is possible for main two reasons: 1) the teams are dedicated to a product and are thus not distracted by multiple projects; 2) the teams are cross-functional, so that when one person gets delayed, others can step in and take on their tasks. See Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time (New York: Crown Business, 2014).
Kommentare
Kommentar veröffentlichen