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.

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

StickyMinds is a TechWell community.

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