The Skeptic’s Guide to Project Management, Part III: The Critical Chain
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In previous installments of this series, I covered ethical ways to gain influence and use negotiation skills. In this article I provide a different tool for your toolbox -- an entirely different way of conceptualizing project work called critical chain project management.
What is Critical Chain?
Critical chain prescribes a different way to organize your projects, focusing on protecting the results for the entire project over individual tasks. It does this by having very aggressive estimates, then using that “saved” time at the end of the project to protect project results, not the result of any individual task.
This approach is not for every team, or for every project. Instead, it fixes a certain kind of problem--projects where (a) tasks are never completed early; they are always on time or later, thus (b) projects are always be on time or late.
Take a moment to think about your last handful of projects. How many of them were early? How many on time? How many late? If early projects are the exception and late projects happen at least occasionally, critical chain might be for you.
To understand the solution, we first have to understand the problem: How a classically organized project can wind up in this situation. Once we understand that, we'll cover the critical chain fix in a bit more depth, followed by how you can use this tool.
The Classic View of a Project
Let's start with this definition:
"A project is a collection of dependent tasks, coordinated to provide a complete deliverable on a given day."
In this view, a project is successful if it hits four goals: On time, on budget, feature-complete, and high quality (or "few defects"). To organize the project, you collect estimates for each task, string them together to fit, come up with an end date, and monitor and control performance. The set of things that must be done in order from beginning to end is called the "critical path," with the idea being that if any one of those tasks is delayed a single day, the entire project is off a day.
That's a simplified definition but it's good enough for our purposes. (Larger projects will include things like work in parallel and slack.).
In order to come up with that “given date,” someone has to estimate the work-- ideally the person who is assigned to that work. We'll call that person the estimator. Notice that the estimator needs to make some tradeoff between efficiency (get the task done quickly) and confidence (knowing it will really be done on time.) Most of the time, if the deadline is important, we want to pad our estimate, offering a task schedule that is longer. On the other hand, under pressure, we may want to give a shorter estimate. Giving different numbers doesn't change the work to be done, nor the ability of the person doing the work; it just allows us to make different plans. The reality is that the task has some sort of probability distribution, as illustrated in the chart below:
)
Many tasks have this sort of a breakdown. There is no chance the work will be done in an hour or two. When we hit some minimum possible time, we see a line emerge, which ticks upward in probability as time increases. Once we reach our most likely time, we begin a long, slow, trailing curve at the end. The area under the curve represents the total percentage change the task will be done in that time period. Thus, a 10% estimate might be "aggressive," a 50 percent estimate might be "average," 90% "conservative," and so on. No matter how your project is organized, when you gather estimates, you can use these terms to measure stress and project schedule risk. ("Is that a conservative estimate?" is a good question to ask. Likewise, when people warn that an estimate is aggressive, take note.)
Note that there is a huge difference between a confident estimate and an average one. If tasks really are only on time or late, a project estimated conservatively is going to involve a lot of waste.
Assertion: Tasks are All on Time or Late
Goldratt[1] comes up with four forces that conspire to make projects done on time or late: Student Syndrome, Gold-Plating, Multi-Tasking, and other dependent tasks.
Student Syndrome. Most of us are familiar with the term paper we had months to write ... and started on Friday before it was due. "Student Syndrome" gives a name to this problem, meaning that serious effort on a task doesn't tend to happen until the deadline is close. Most of the time before a task will be wasted.
Gold-Plating. If team members are dedicated and diligent, they may finish the task early. If someone does finish early, he faces a conflict; if the work is turned in early, he will be "rewarded" with more work. Yet there is always more work to do; more i's to dot and t's to cross. A programmer can always do more refactoring; a tester can always find more tests to do, a graphic designer can always twiddle the colors and samples. We'll call this extra work to fill the deadline "Gold-Plating," and it's certainly possible to let this extra work eat up any schedule gains.
Multi-Tasking. If the team member is working on multiple tasks and projects, then it's likely that she will work on the most pressing task. This kind of behavior encourages student syndrome at the beginning of the task (robbing time from Peter to pay Paul). If the team member finishes the task early, it's likely she will switch to another task instead of working to hand-off the completed work.
Other Dependent Tasks. Even if you manage to fight all these forces and turn your work in a week early, in most cases you are handing it off to the next person in the chain. Of course, that person is probably scheduled to work on something else this week and the dependent task next week. As a result, any time saved from turning this task in early is lost, because the next person in line is not available to work on it.
Even if that next person is able to work on the assignment, it is likely that he will fall victim to Student Syndrome, Gold-Plating, or Multitasking.
If every individual task is on time or late, what does that do to the project?
Assertion: The Project Will Be On Time or Late
Given that tasks will always be on time or late, it makes sense the project will always be on time or late. The question is: What are our odds that project will be on time, verses late?
With a one-task project, the odds are simple: The percentage of confidence we have in the task matches the odds that it will be on time. For example, if the task can be completed with 90% confidence, you have a 90% chance to finish on time.
Most projects are composed of more than one task; in that case, the odds stack. With two tasks, each independently calculated at 90%, the odds will be 90%*90%, or about 81%. With three tasks, we get to 90%*90%*90%, or closer to 72%. After a few tasks, if the estimates are the least bit aggressive, the odds quickly approach unreasonable. I implemented this logic as a graph a few years back; it may be illustrative here:
)
According to our logic, if we estimate tasks to 80% confidence, once the project hits ten tasks the overall success rate drops to 20%. Likewise, even if we estimate to 99% confidence, padding each task to protect it, once we reach 150 tasks, our chance of success is still out around 20%.
Before I continue, I want to be clear: These numbers are, at best, estimates based on certain logic. It might, for example, be possible to motivate the team so that some tasks do come in early, or shift the planning process to avoid this problem. We'll talk about that more in an upcoming article. Also, it's hard to put a figure on exactly how much padding an estimate has; it is entirely a subjective, human call to make. Still, if the logic holds, or if it's even close, well ... something is rotten in Denmark.
So far we’ve demonstrated that organizing a project by task, then padding the time estimates for each task invites failure. By “padding”--adding time to protect tasks-- we drive costs up. (Now each task will take longer than the 50% “more likely” estimate. Remember--tasks are on time or late, never early). Yet we need that extra time, because a single late task can cause a late project. As Lister and Demarco wrote so well in their book "Waltzing With Bears: Managing Risk on Software Projects":
Without knowing anything at all about your current project, I'll bet even money that you'll be late. After all, well over half of all projects deliver late or deliver less than was promised by the original deadline. It's far worse when a project is on an admittedly aggressive schedule. Project people seem disconcerted when I proclaim I am willing to bet against them ... what usually happens is that everyone agrees that the deadline is very tight; everyone works very hard; and then, when people see that they won't make it, they are shocked, disappointed, and deeply dismayed.
It may sound like bad news, but think about it another way: Now, instead of being surprised when projects are late, we have some thinking tools to predict outcomes. That's a good thing. Even better, critical chain offers a solution to this problem.
The Fix: Stop Protecting the Tasks and Re-Organize to Protect the Project
Once we realize this problem, the fix is relatively easy: Shrink each individual estimate down to the most realistic possible time for that task--the fifty-percent likelihood estimate. Make it culturally acceptable to be late on a given task. Take the exact amount of time you took out and add it to the end of the project as a buffer.
You can apply to this to any project, even to existing project plans. To senior management, you are making the same commitment to a delivery date, only you can actual make it with some confidence. The team will have a 'goal' date, when the tasks end, but it remains that: A goal. Using those terms--Goals vs. Commitments--will allow you to make the conversation with both sides--the technical team and Senior Management, or whoever is cutting the checks for the projects--a great deal more realistic.
I may have glossed over that, and I think it is worth re-iterating: A critical chain project is “just” a traditional project with aggressively scheduled tasks combined with a strategic reserve of time at the end. You can literally convert a traditional "Gantt Chart" project plan into a critical chain project by slicing the time for each estimate and adding it to the end.
In the past, I have tried this technique, with the results you would expect. Some senior managers saw that extra time and the end and wanted to shift the due date back, transforming “early” into “on time.” It’s happened more than once, and I usually end up saying something like this: "My commitment to the business is to deliver the project by June 1st. We do have a one-month risk mitigation period built into that commitment. It's possible we deliver a little early. If you want to take responsibility for the project dates, you could take that reserve out, but I will not promise to deliver without that risk management reserve."
Every time I bring up the terms 'responsibility' and 'risk', the buffers have stayed in, and I have used this technique to deliver multi-million dollar projects on time.
What now? Bringing Critical Chain to Your Organization
On paper, Critical Chain sounds wonderful. Why, just get more aggressive estimates, add buffer at the end, and have more successful outcomes. Sounds a bit like a fairy tale, doesn't it?
Except that your technical staff has been trained to protect their estimates, the senior management expects a project plan that has a certain look, and the organization is multitasking. Moving to critical chain requires an entire culture shift--one your organization might not be ready for yet.
Still, even if you can't shift to Critical Chain, knowing the concept can make you more effective at the work you do. Here are a few examples:
- When gathering estimates, you can talk in terms of confidence, and get a range, instead of reducing the task to a single number
- When someone asks why every project is late, you can answer the question, and present them with options in the future
- When conducting retrospectives on projects, gather data on the tasks and planning process. If you can explain what happened and why it happened, not as an individual failure but a series of predictable events, you are more likely to avoid blame, create change, and, just possibly, prevent future problems.
- When the company has a crisis and the project needs to hit a deadline, you may find people suddenly open to new techniques and methods.
Adopting Critical Chain
I fondly remember one project with an immoveable deadline, which is to say, if we moved the deadline, the government would step in and disqualify the company from selling that product for at least a year. I was the project manager set to lead it, and, time and again, the technical staff would make, and then break, deadlines for deliverables.
After two months had passed (and we had accomplished perhaps a month of work), the technical leads started to talk about “making it up later.”
You may have heard the “make it up later” strategy, and let me ask: Did you? Did you ever make it up later?
If a project is late, it is likely that it got that way because of aggressive scheduling. I’m not sure how an overly-aggressive schedule will suddenly pick up speed, going faster than the original schedule to pick up the slack.
Instead of planning to make it up later, I gathered the core technical staff, and, every single day, we would rebuild the release schedule, with dates as aggressive as possible.
The point wasn’t the schedule; I had no faith in it either. The point was to eliminate student syndrome and multitasking. With work that needed to be done right now on the place for right now, each team member had to stretch.
It was a crisis. It was a challenge. We kept blowing the schedule. Each morning, I’d erase the whiteboard and re-plan. But the commitment date? We made that.
There’s no way that would have happened if we aimed for the commitment date in the first place, with nice long task durations. If we had aimed for that, then student syndrome, multitasking, and gold-plating would have torn into us, and, I suspect we’d have shipped two months late.
If your project is in crisis, you might be able to save it by re-organizing the schedule to be based on critical chain techniques.
Then again, you might not. Even if you insist, the organization may find some other project manager willing to try traditional tools.
Sometimes organizations, like people, need to fail themselves in order realize they need a new way.
You might not be able to use critical chain this time, but, perhaps, next time, the company will be more receptive.
Critical chain is a tool. You can use it to plan projects, to mitigate risks, or use the thinking tools above to predict project outcome and steer people towards better decisions.
[1] The inventor of “The Theory of Constraints”, Eli Goldratt, was an Isreali physicist who became a business management advisor and consultant. His first book, The Goal, took Goldratt’s ideas about managing the work by the constraint, or bottleneck, and introduced them onto the manufacturing floor. His third book, Critical Chain, applied those ideas to project management. Dr. Goldratt died Jun 11, 2011, while Matt was composing this article.