Critical Chain Scheduling for Software Projects


In 1997 Eliyahu Goldratt published a business novel titled Critical Chain in which he introduced a new way of scheduling and executing projects similar to the more familiar Critical Path method. Goldratt's version removes many of the estimating games that go on between managers and their staff. This results in projects that typically deliver in about 75 percent of the normal time. In this column, Clarke Ching demonstrates some of the ideas from Critical Chain and will show how to use it easily within agile projects.

In practice the Critical Chain technique has been used in multi-billion-dollar and multi-year projects, but I'll demonstrate the ideas using an extremely simplified example of a small project with just one developer and one project manager. The project manager and the developer have broken down the featureset into six tasks—A, B, C, D, E, and F—which can be performed sequentially.

With the tasks identified, the project manager knows how long the project should take, so she asks the developer to estimate how long it will take to complete each task. The developer looks at task A and says, "I could probably do that in one to three days, but that's only a guess. With all the interruptions that go on around here it could easily take me four to seven days. Heck, it could even take as much as eight days, maybe even more." He thinks for a bit and says, "Eight days." The developer knows that although the project manager has asked for an "estimate," which is a range, she really wants a commitment in the form of a single date. After all, her project management software only takes a single date.

Let's say, for the sake of this simple example, that the developer estimates that the tasks can be completed in about 8 days. The plan will then look like this:


The total duration is 6 x 8 = 48 days.

It's quite likely that the some project manager will automatically chop a bit of time off the high estimates but also keep some estimates as they are—as an informal contingency. These project managers won't tell their bosses; otherwise, they'd be accused of "padding." Let's just assume this doesn't happen.

Let's see how our project manager would prepare the equivalent Critical Chain plan. Having been given eight days as the "estimate," she asks the developer if eight days is a commitment-level estimate (i.e., a date to which, most of the time, the developer could commit). If not, she would ask the developer to re-estimate. Then she would tell the developer—and this is extremely important—that she only needs this estimate for her planning and that she doesn't care if the developer takes longer than eight days or less. She even promises that if she ever penalizes the developer (even if it's just with a dirty look) for taking more or less than eight days that she'll buy the entire team lunch for a week. (Maybe she even records a video of herself making that promise.) But then she does something that will scare the developer the very first time he sees it happen: She chops all of the commitment-level estimates in half, and she takes the bits she's chopped off, puts them on the end of the project plan, and calls this time a buffer.So the project plan now looks like this:

AAAABBBBCCCCDDDDEEEEFFFFxxxxxxxxxxxxxxxxxxxxxxxx (where x is buffer time).

The duration is still 48 days.

The developer will probably say something like, "You're kidding me, right? I've only got half the time I promised. That sucks."

The project manager reminds the developer of the promise she made—about buying lunch if she ever penalizes anyone for taking more or less time than the eight days, or even the four days. She then says, "Besides, I'm going to make it easier for you to finish each of these tasks quickly by protecting you from all the interruptions you get. In fact, I'm going to fight to make sure that you only ever work on one task at a time."

Hopefully, the developer will think that with many of the interruptions gone, four days isn't an aggressive deadline after all. He asks what the buffer is for. The project manager says that since some tasks are going to take longer than the four days she has in her plan, she will use the buffer time to absorb the extra time. If they finish sooner than expected, then she'll add the time gained back into the buffer. So, if task A takes six days, task B takes five days, and task C takes four days, then the buffer will have three days eaten out of it.

Note that there are some rules during execution that are vitally important:

  • The developer is asked always to single task, except during emergencies—that is, he's asked to work on A, then B, then C, and not to switch between them. Multitasking dilutes the effort applied to each task. Try to complete three tasks by multitasking, each of which should take about four days to complete, and you'll notice how each task suddenly takes twelve days or more
  • The project manager protects the developer from being asked to multitask
  • The project manager and developer check in daily—just like they do in a normal agile daily meeting

I add the following fourth question to Scrum's normal three: How many days do you have left on the first task you are currently working on? This is different from the question, What percentage of the task have you completed? This new question reinforces the single-tasking rule, plus it gives you real-time information. Don't be surprised if the estimate goes up and down, though, as the developer learns more about the task. High estimates often reflect uncertainty, which disappears as you learn by doing a task. On the second day of working on the task, the estimate may well drop down from eight days to three, but the estimate may equally go up as well. That's why you have the buffer there—to protect you. Estimates are guesses after all.The project manager must always keep her promise that she won't penalize the developer when estimates go up or down, or take more or less time than originally estimated. Estimates are guesses, not commitments.

Finally, given all these behavior changes, you'll find that the buffer is too long. You can chop it in half as well, and you'll still have a reliable project plan. There's loads of good statistical reasoning why you can do it, but take a look at the plan above where the buffer was half of the total duration and ask yourself if you really need it. If you think you do, then keep it, but plan to finish early.

So here's our new plan, with the buffer taking only one-third of the duration:

AAAABBBBCCCCDDDDEEEEFFFFxxxxxxxxxxxx (where x is buffer time).

The duration is now 36 days.

Given the behavior changes—especially the enforced single tasking—you've now got a project that is far more likely to finish on time even though it's only 75 percent of the original duration. You can now do twelve months' worth of projects in nine months. That's a whopping 33 percent increase in capacity—for free. The biggest but least obvious benefit is that using this approach builds trust between managers and staff by removing all the unhealthy game playing that goes on with estimates.

You can scale this process to fit huge projects or for an iterative process. Let's say you are running a Scrum project where you promise to deliver a few features off the top of your backlog in, say, three weeks. Your resulting plan will have two weeks' worth of aggressive (and halved) tasks and a single week of buffer. So you add just enough features to fit in that time box. You'll find that each iteration will finish sometime during the third week. This approach means you can make more reliable promises, and, believe it or not, you can deliver more work in the same period of time.

Further Reading:

User Comments

1 comment
Stephan Toth's picture
Stephan Toth

I think that Sanat is missing the point here, the buffer is created by taking 95 percent the maximum time that the contractor says that he can confidently do the the selected tasks and then taking fifty percent of that number of days. This means that the contractor will finish early or finish late fifty percent of the time.

Then one models the risk surrounding this date by uses a modeling program like Palisades @Risk for Projects to do a Monte Carlo or Latin Hypercube simulation in order to find out where the risk to the date converges and how confident one can be of the final date range. The next step is to present ranges of the task dates and the range of the final project for approval.

Presenting the data in this form accommodates the decision makers need for a range of completion dates that satisfies his risk appetite. A cautious decision maker would focus on seventy plus percent of the range while an optimistic decision maker would focus nearer to the fifty percent margin.

Having all of the buffer accumulated at the end of the project allows the project manager to monitor the project buffer usage. S/he is then able to see if the buffer is being used up faster than the number of project tasks being completed. If this is the case s/he can take corrective action in good time. If the buffer is being used up slower than the number of project tasks being completed, the project manager can be confident that the project will finish before the 100 percent estimate and could if desired adjust the ultimate completion date to reflect this.

This article did not cover the cost buffer associated with the critical chain method. Obviously the cost buffer would only reflect the variable cost associated with each task. Including this element, and conducting a similar Monte Carlo or Latin Hypercube simulation as outlined above, the project manager could present a cost risk range to the decision maker. This would also enable him or her to see if the variable cost elements of running the project were rising at a greater rate in comparison to the projects completion date.

Again, cost that were rising much faster than the project completion dates would sound alarm bells and trigger the need for investigation.

The only real problem that I can see with the critical chain method is when one is dealing with projects that use in-house teams. Here, the methods doctrine of 'tasks being started and completed as soon as possible' runs into scheduling time difficulties especially if the company is running a multitude of projects.

Administratively speaking, this could become a scheduling nightmare with project data and task team notifications having to be updated and sent out on a daily basis. Obviously this would increase administrative cost and risks of errors and oversights to the projects time and cost functions.

I must admit that I have not yet come across any information that addresses this logical problem in the critical chains ideology.

Obviously projects that are using contractors who have agreed to the doctrine of Just In Time (JIT) would not suffer in this way and would be expected to adjust their schedules according to the changing needs of the project.

January 19, 2013 - 10:07am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.