Critical Chain Project Management
By Nicola Hill
One of the misconceptions that is unstated in the current Agile vs Waterfall debate is the idea that there is only one style of “waterfall”. Agile is wonderful for the creative process of working closely with a customer to deliver what they want, but is not very useful when one group of resources is spread across many projects.
When you’re dealing with a physical thing, like a data center, or an aircraft, or a new bridge, the sequence of actions becomes much more significant. And when you’ve got lots of different resources working on different projects in parallel, you will end up with some groups becoming a bottleneck. Often what ends up happening is that these key resources become spread across too many projects, constantly multi-tasking, and never able to see anything through to completion. Every time they sit down to concentrate, the phone rings, or there is an emergency, and they get diverted onto something else. Or they start working on a task, but find that they need others to do things first, and so can’t complete it. Everything ends up taking far too long, and the team is always in panic mode.
Critical chain project management addresses this in two ways:
Firstly, it restricts the multi-tasking that the key “drum” resources are doing, perhaps to one project at a time. In reality, that might be one project in start up / design / consultation stage, one current task, and one still open for troubleshooting and questions. By reducing the multi-tasking, tasks get done a whole lot quicker, so the projects are processed is faster, not slower.
Secondly, it puts in place slack in front of the “drum” resources, to ensure that everything they need is in place once they are available to work on it. For example, a firewall engineer will be available to a particular project on the 15th of May, for that one day. Other deliverables need to be in place in order for the firewall engineer to do everything necessary: cabling installed and tested, network configured, servers fully installed with the application software, documentation ready, and so on. The project manager should plan that these all be in place by, say, the 8th of May, to ensure that nothing can derail the success of the 15th.
This may sound wasteful, but the point is that the drum resource is the key to the flow, the beat to which the projects flow through the organization. By putting some slack in front of their tasks, and ensuring the drum resource can start and finish their work swiftly, everything gets done more quickly. In one example of aircraft maintenance, fix times came down from 135 days to under 30 days.
Nicola Hill, PMP, APMP specializes in managing difficult projects, with wide experience in blue-chip and SME companies. She brings strong problem-solving and facilitation skills with an ability to operate at all levels, and is particularly good at the interface between business and technical viewpoints. She is highly qualified in both Agile and Waterfall project management. You can read from Nicola on his blog.