Project Management - Lessons from a cross-country drive
I'd like to introduce you to Critical Chain Project Management (CCPM). And if you think this is simply an alternative to critical path and earned-value, you might be interested to learn that it is much more than that... Let me illustrate with an example of a cross-country drive.
Say I need to catch the Dover-Calais ferry at 22:00 later today. Google tells me the journey is 273 miles, and will take me 4h48.
I could break this down to a simple sequential project:
- Drive home to M6 = 18 minutes
- J18 - M6 Toll = 40 minutes
- M6 Toll = 20 minutes
Adding up to 4h48 minutes.
In practice I would take Google's 4h48, I would add a couple of stops, say 40 minutes, and I would add a buffer for the whole journey (M25 at about 18.00...mmmmm.. let’s add 2 hours. I know that about 250 miles is on motorways, at a legal limit of 70mph, so Google hasn't included much for bad traffic and accidents). So my project planned duration is 7h28m. I’ll round it up and leave by 14:30.
But what would we do if this was a project?
Each of the sequential tasks would be done by a different manager - or in my field of capex projects, a different company. Most project managers manage progress with task deadlines and milestones, and insist on getting reliable commitments for each task. In my road journey analogy, this means a highly reliable time for each leg of the journey.
But that is not what I have included in the first plan. Each stage of the journey is based on a reasonable average, and I have added contingency time to cover the whole project. How many of us do this in our day jobs? Most project managers don't want an average task time in their plan, they want a commitment that an individual is held accountable for.
So if I plan again, but this time using highly reliable times for each leg, I might get:
- Drive home to M6 = 30 minutes
- J18 - M6 Toll = 70 minutes
- M6 Toll = 27 minutes
... Adding up to 7h30m.
Then I might add some time for stops (40m) and a smaller project-level contingency (40m), meaning I might plan my journey to last 8h50, and I need to leave home at 13:10. In total I have 50 per cent more safety (3h22 v 2h02), with most of it built into task commitments.
Now you might think that this longer duration is OK. What harm does a bit of extra safety do?
Well for one thing, on my kind of project (capex and construction), it has added significantly to the cost. All the task suppliers have given me a highly-reliable commitment, and I have tied them up with a fixed-price contract with damages for lateness. Meaning if one supplier doesn't need the safety they built in, they profit. They are not going to pass the unused time or money back to the project - and they shouldn't be expected to, that is simply part and parcel of fixed-price contracting. Holding people to task-level commitments is obviously silly in my driving story. Imagine if on stage 1 it only took me 16 minutes, and I then park up for 14 minutes so that I hit my 30 minute “commitment” - remember some project managers seem to hate early finishes as much as late ones!
The other thing is that when I have a lot of safety, I am much more relaxed about time. I might take a detour to find a nice high street coffee shop rather than the same-old same-old motorway service station. I might call in on a tourist spot near my route. I might drive at 60 mph and emit less CO2. We can all relate to the "student syndrome", where we have plenty of time to do an assignment…but still end up burning the midnight oil and often end up late. The same can happen on projects where we have too much safety. On a project though, rather than slowing down and taking in the scenery, most of us take on other work. "Sure I can fit that in, I have plenty of time to complete my project task". Then we find ourselves inefficiently switching from one task to the other. We are overloaded, and everything takes longer!
So what are the project management learnings from this cross-country drive?
- There is no point in trying to predict with certainty how individual tasks (the stages of my journey) will turn out.
- Task estimates are only useful in setting a reliable project completion date and budget. They are not firm commitments.
- Shared, project-wide contingency buffers are much more effective than including contingency in each task.
- Task milestones, based on highly-reliable commitments, add to the project time and cost, without adding value. They don’t make the project any more reliable.
- Task managers should complete as quickly as possible – known as “Focus & Finish”.
- Project managers should remove the obstacles to rapid task completion, and “project flow”.
- You need to choose the right performance measures on your project. Measure the wrong thing (like task managers hitting their commitments) and you will get a project taking longer and costing more than it needs to, and you wont notice early signs of real problems.
In short we need just a good-enough plan, and great, agile and real-time execution.
And yes, there is a formal methodology that incorporates these learnings. It is not yet very common but companies that have used it have made significant improvements in their projects - making them more reliable, whilst costing much less and taking less time. Mazda said it reduced their project duration by about 50 per cent, allowing their R&D team to complete over 35 per cent more projects than they used to. And a division of Siemens in the USA used this method to halve the time to design new wind turbines - from two years to one year.
The method is Critical Chain Project Management (CCPM). And if you think this is simply an alternative to critical path and earned-value, you might be interested to learn that it is much more than that. Typical results from companies using CCPM include:
- 35% faster than before
- 25% increase in project throughput
- 90%+ due date performance
Ian recently presented a webinar for APM on CCPM, and what else is needed to be able to use it on construction and capital projects, where contracts can often get in the way.
You can see the webinar recording, and the Q&A here.