With good estimating techniques, a subject matter expert (SME) can estimate effort reasonably well. Lines of code per hour, objects per day, story points per sprint, all of these we can measure and plot./1/ Estimating a project’s duration, however, vexes every good project manager, and a delayed delivery date is what makes headlines. As opposed to effort, duration is plagued by interruptions, dependencies and merely waiting for, as Dr. Suess says, “a mind-maker-upper to make up his mind.”/2/ In September, I proposed a KPI for getting a handle on project duration called “project duration efficiency” (PDE). In this article, I would like to run through an example to show how easy and helpful it can be.
Project duration efficiency measures how efficiently we use the calendar time available to us. Maximum efficiency occurs when our effort matches the duration: 20 days of effort completed in 4 weeks time gives a PDE score of 1; 20 days of effort over 8 weeks yields 0.5. Please see Part 1 for a fuller explanation.
Why is duration – calendar time – important for projects? Since, benefits accrue only once we can actually use the product, speedy delivery allows us to start enjoying the benefits, i.e. earning the return on investment, earlier. We thus count any delay as cost based on the return we lost by waiting. PDE shows how efficiently we used the time available. Its a measure of the delays’ effects on a project that is comparable across projects.
So, let’s explore an example and see what it tells us.
A company needs an interface between two software systems to automate the transfer of some financial data. Currently, the manual process is slow and error prone, literally with copy and paste in and out of Excel. The monetary benefit is the reduced effort for processing and correcting the data. Let’s assume that this effort costs one FTE, or €400 per day. (We won’t try to quantify the happiness factor for the staff who no longer needs to do this tedious job.)
Our project team consists of 4 developers (two per system) and 2 testers (1 per system). In addition, there is a project manager and various stakeholders. Here’s the breakdown for the project:
These people cost on average €500 per day, making the total cost to the project €80,000 (assuming no other costs). The benefits are €400 * 220 days = €88,000. /3/ Since the project costs could be recouped within one year, the management decided it was worth it.
With 7 individuals involved, the best possible result (PDE=1) would mean finishing the project in 22.86 days (160/7 = 22.86) or 4.6 weeks. /4/ Of course, the testers can only test once something has been produced. Futhermore, the PM’s efforts will be spread across the project. Such factors make a PDE of 1 almost utopian.
An ideal (but realistic) project might, therefore, look like this:
So, we really need 7 weeks, or 35 days, duration. Thus, our PDE is
What does this mean for the benefits? Compared with the ideal, the customer lost 85 days’ use of the product (120 days to delivery minus the 35 in the plan)./5/ If the fast, error-free data transfer has a value of €400 per day, then the cost of the lost benefits was equal to 85 X €400 = €34,000. With the project cost totalling €80,000, our delay added nearly 50% to the projects’ costs in the form of missed benefits.
So, what can we do with the PDE number?
The project manager can calculate the real PDE at any time during the project. If it starts to fall behind the organizational norm, it would give an objective measure of the effect of the delays. It is, of course, a late measure. If the project is truly important, the project board will already be screaming about slipping deadlines. But, most projects are muddling in the middle.
The PMO can monitor PDE for all projects. PDE helps show where we’re putting our real effort. A comparison against benefits’ rankings will reveal the difference between our stated priorities (benefits’ rankings) and our real priorities (PDE). A low PDE means that a project is likely being neglected. Is the project important? If yes, something needs to change. By the way, the best solution is to put low-PDE, low-benefit projects fully on hold, so that the organization can deliver the high benefit projects first.
An honest evaluation of the causes of delays (low PDE) can lead to different approaches to project planning, team coordination and resource prioritization. Here are some typical factors:
So let’s suppose that our company starts measuring PDE. We discover after 10 projects, that most projects show a PDE between 0.1 and 0.25, with the best PDE at 0.30. We should therefore expect our project to fall within this range (assuming no major organizational initiative to raise it). A project manager should calculates the PDE in his plan based on the planned delivery dates. If the PDE is much higher, say 0.5, the project manager should realize that the plan is not realistic.
Another approach would be to start with the effort estimates and simple divide it by the company average. The equation is thus:
Feedback? A useful measure? I would be delighted to hear your comments.
Part 3 of this series, you'll find here: Measuring Strategic Speed with PDE
/2/ The full quote from Dr. Suess’s Oh, the Places You’ll Go
/4/ As discussed in Part 1, we count all resources who contribute to the project result except for stakeholders such as project board members. And, we count them as individuals under the assumption that they *could* work 100% for the project. In many cases, they will not. We don’t count FTEs committed to the project because that would always yield a PDE of 1.
/5/ The idealized scenario shows the necessity of 35 days, so we don't count those as cost of delay.
/6/ Paradoxically, rework can actually raise the PDE. Rework frequently occurs toward the end of the project, where a deadline is looming. With the threat of a deadline, the organisation gives the project priority, and the team dedicates 100% of its time to the project. Thus, the team works at nearly a PDE of 1. Added to the project, this “1” for the final sprint thus raises the PDE for the whole project. Did someone just say “sprint”? Hmmm…. maybe we could find a method for working at nearly 1 PDE all the time?
Project duration efficiency measures how efficiently we use the calendar time available to us. Maximum efficiency occurs when our effort matches the duration: 20 days of effort completed in 4 weeks time gives a PDE score of 1; 20 days of effort over 8 weeks yields 0.5. Please see Part 1 for a fuller explanation.
Why is duration – calendar time – important for projects? Since, benefits accrue only once we can actually use the product, speedy delivery allows us to start enjoying the benefits, i.e. earning the return on investment, earlier. We thus count any delay as cost based on the return we lost by waiting. PDE shows how efficiently we used the time available. Its a measure of the delays’ effects on a project that is comparable across projects.
So, let’s explore an example and see what it tells us.
A simple, but realistic project scenario
A company needs an interface between two software systems to automate the transfer of some financial data. Currently, the manual process is slow and error prone, literally with copy and paste in and out of Excel. The monetary benefit is the reduced effort for processing and correcting the data. Let’s assume that this effort costs one FTE, or €400 per day. (We won’t try to quantify the happiness factor for the staff who no longer needs to do this tedious job.)
Our project team consists of 4 developers (two per system) and 2 testers (1 per system). In addition, there is a project manager and various stakeholders. Here’s the breakdown for the project:
| Role | Count | Effort per person (days) | Tasks |
| Developers | 4 | 30 PD | development, error correction and rework based on test results |
| Testers | 2 | 15 PD | creating test scenarios and testing |
| Project Manager | 1 | 10 PD | planning, issue management, reporting etc. |
| Total | 7 | 160 PD |
These people cost on average €500 per day, making the total cost to the project €80,000 (assuming no other costs). The benefits are €400 * 220 days = €88,000. /3/ Since the project costs could be recouped within one year, the management decided it was worth it.
With 7 individuals involved, the best possible result (PDE=1) would mean finishing the project in 22.86 days (160/7 = 22.86) or 4.6 weeks. /4/ Of course, the testers can only test once something has been produced. Futhermore, the PM’s efforts will be spread across the project. Such factors make a PDE of 1 almost utopian.
An ideal (but realistic) project might, therefore, look like this:
PDE = (total effort / number of people working on project) / durationSo, even this idealized scenario yields a PDE of just 0.65, and few would believe finishing the project in less than 7 weeks is possible. In reality, however, many organizations need upwards of 6 months (120 workdays) to complete such a project. That would yield a PDE of 0.19, or less than one-third of the idealized value. Compared to the idealized scenario, the project was just 29% time efficient.
0.65 = (160 / 7) / 35
What does this mean for the benefits? Compared with the ideal, the customer lost 85 days’ use of the product (120 days to delivery minus the 35 in the plan)./5/ If the fast, error-free data transfer has a value of €400 per day, then the cost of the lost benefits was equal to 85 X €400 = €34,000. With the project cost totalling €80,000, our delay added nearly 50% to the projects’ costs in the form of missed benefits.
So, what can we do with the PDE number?
Alarm signal to management about threats to benefits and priorities
The project manager can calculate the real PDE at any time during the project. If it starts to fall behind the organizational norm, it would give an objective measure of the effect of the delays. It is, of course, a late measure. If the project is truly important, the project board will already be screaming about slipping deadlines. But, most projects are muddling in the middle.
The PMO can monitor PDE for all projects. PDE helps show where we’re putting our real effort. A comparison against benefits’ rankings will reveal the difference between our stated priorities (benefits’ rankings) and our real priorities (PDE). A low PDE means that a project is likely being neglected. Is the project important? If yes, something needs to change. By the way, the best solution is to put low-PDE, low-benefit projects fully on hold, so that the organization can deliver the high benefit projects first.
Organizational learning
An honest evaluation of the causes of delays (low PDE) can lead to different approaches to project planning, team coordination and resource prioritization. Here are some typical factors:
- Waiting for work from other parties (internal or external)
- Waiting due to coordination. Planning of meetings etc.
- Waiting for decisions on requirements, changes, project issues etc.
- Waiting because other projects have a higher priority and delay when we can use our resources.
- Unplanned rework. Some rework can and should be planned, but unplanned rework hits us doubly hard because it includes cost from real additional effort as well as cost of delay (compared to the original plan)./6/
Controlling our estimates
So let’s suppose that our company starts measuring PDE. We discover after 10 projects, that most projects show a PDE between 0.1 and 0.25, with the best PDE at 0.30. We should therefore expect our project to fall within this range (assuming no major organizational initiative to raise it). A project manager should calculates the PDE in his plan based on the planned delivery dates. If the PDE is much higher, say 0.5, the project manager should realize that the plan is not realistic.
Another approach would be to start with the effort estimates and simple divide it by the company average. The equation is thus:
Duration = (Effort / Persons working on project) / PDEAnd, if the company's average PDE is just 0.15, then our project is going to take about seven and half months:
152.4 workdays = 160 / 7 / 0.15I am well aware that this is not the answer the project board wants to hear. And, they are right to want the result earlier. But, under the current circumstances, the number is realistic. Therefore, the PDE number supports the PMs planning assumptions, and can initiate a constructive discussion with the project board about expectations, priorities and resources. Of course, if a company desires a PDE of 0.5, but is achieving much lower numbers, it should start a major initiative to improve its ways of working or simply hire more people.
Feedback? A useful measure? I would be delighted to hear your comments.
Part 3 of this series, you'll find here: Measuring Strategic Speed with PDE
Notes
/1/ See Jan Fischbach's post on Relatives Schätzen./2/ The full quote from Dr. Suess’s Oh, the Places You’ll Go
Simple it’s not, I’m afraid you will find,/3/ I assume a savings of 1 FTE of manual work at a cost basis of €400, and €500 for the development costs. Such numbers in Germany are realistic. Feel free to plug in your own numbers. Please keep in mind that avoiding the manual work justified the project in the first place. If the costs of the manual work are really low, then we would have never chosen to invest the 80 TEUR in the first place.
for a mind-maker-upper to make up his mind.
/4/ As discussed in Part 1, we count all resources who contribute to the project result except for stakeholders such as project board members. And, we count them as individuals under the assumption that they *could* work 100% for the project. In many cases, they will not. We don’t count FTEs committed to the project because that would always yield a PDE of 1.
/5/ The idealized scenario shows the necessity of 35 days, so we don't count those as cost of delay.
/6/ Paradoxically, rework can actually raise the PDE. Rework frequently occurs toward the end of the project, where a deadline is looming. With the threat of a deadline, the organisation gives the project priority, and the team dedicates 100% of its time to the project. Thus, the team works at nearly a PDE of 1. Added to the project, this “1” for the final sprint thus raises the PDE for the whole project. Did someone just say “sprint”? Hmmm…. maybe we could find a method for working at nearly 1 PDE all the time?
Kommentare
Kommentar veröffentlichen