Using their experience and Critical Chain, they have the following customer results (see www.goldratt.com ) (2.3):

www.toc-goldratt.com has a TOC reference bank of results that includes (2.4):

Realization lists several customer summaries, brief case studies, and customer videos at http://www.realization.com (2.6).

High Tech New Product Development. HP Digital Camera Group:

Aircraft Repair and Overhaul. US Air Force, Warner Robins Air Logistics Center, C17 Production Line:

ProChain lists several customer success stories as well at http://www.prochain.com (2.7). Clients have experienced:

There is also an example of Habitat for Humanity using Critical Chain scheduling to set a new world record building a four bedroom house in 3 hours, 44 minutes, and 59 seconds. (2.8)

“So Tim, these are some very compelling results. Can I expect these same results in my organization?”

“That is a great question, Randal. It depends on your individual circumstances. In implementing Critical Chain, some organizations have found huge opportunities where they can significantly improve their operations. Other companies have found significant improvements, but not as dramatic as these. As we walk through better understanding Critical Chain as well as how your organization works, we can highlight the opportunities and potential impacts of implementing Critical Chain.”

“Okay, Tim, that makes sense. These results look promising. Individual results may vary. So tell me how can Critical Chain really deliver?”

“So Randal, as I asked before, what is the key issue in project management?”

“Managing project risks effectively, hitting deadlines, staffing, managing scope, and building the right product all come to mind, Tim.”

“Sure Tim, I have some familiarity with variability. It is what Gary talks about all the time when his team misses a deadline. He talks about there being more work involved than originally expected, that additional scope and requirements were added, resources were not available, tasks took longer than expected, and worse project disasters happened that can totally sink a project.”

“True and when we originally build a schedule, how do they take into account this variability?”

“Well of course Gary does. Kinda… Well, maybe not exactly. He asks the engineers for their estimates, he ties everything together, and then we call it a schedule. Well, actually an initial estimate. Then management looks at the estimate and starts cutting out time. Then we end up with something that management feels is aggressive and somewhat realistic and something that engineering doesn’t scream too excessively about.”

“And how often do you meet these schedules, Randal?”

“The original schedule or the latest version of the revised schedule?”

“The original.” asks Tim.

“Well Tim, in general, not at all or at least never consistently. Engineering hits the typical unexpected and unplanned issues—they’re juggling multiple projects, complain about being stretched out and understaffed. They ask for more time; sometimes we replan and give them more time, and even then they’re likely to miss it. If we don’t give them more time, they’re likely to push out anyway or cut major features.”

“So Randal, does it look like this process is working for you in the long run?”

“Well… No, not really”

Tim draws the following diagram.

“So, Critical Chain sets up a formal system to better manage project variability. When an engineer estimates a task, there can be two sets of time. Focused time is the ideal time the task would take if the engineer just worked on that one task with no problems and no interruptions. Safety time is the padding the engineer adds to that focused time estimate to take into account possible issues, such as the other work they are doing, paranoia, etc. For Critical Chain, we build the schedule based on the focused time and aggregate the safety time from all tasks to create a project buffer at the end of the project [frt 1].”

“So Tim, is this similar to using aggressive task estimates and then putting a management buffer at the end of the project since you figure they will run late?”

Tim then draws the following diagram.

“Close, but there are some fundamental differences. A management buffer is simply adding more time to a schedule that includes safety time in it. So you are adding a management buffer to an engineering task buffered schedule. This stretches out the schedule even more. Critical Chain uses aggressive focused times and the project buffer at the end of the project is more strategic and effective. In addition, you define strategies to manage this buffer and trigger actions if the buffer is being consumed too quickly too soon, so there is more to it than a management buffer at the end of a schedule. Since the project buffer is more strategic than buffering each task, we find that we can often use less time and still get good protection against delays. To help effectively manage the project time, we also focus on behaviors to reduce bad multi-tasking and look at ways to more rigorously build the schedule, which leads us to our next two items.”

“Okay, Tim that sounds a bit more developed than what we are currently using.” I will have to bring in Gary and see what he thinks.”

“So Randal, have you ever driven on Highway 101 during lunch time?”

“Sure, it’s a breeze; I can often finish my work commute in 20 minutes or so.”

“And Randal, during the 5:00 rush hour, how long is your commute?”

“Horrendous. It can take up to an hour; worse if there is an accident.”

“So your commute time can actually triple, but the distance from work to your house never changed.”

“Correct.”

“So that is what we look for with bad multi-tasking . A highway has a certain capacity of cars it can handle. When there are not a lot of cars, traffic can flow rather quickly and just adding more cars has minimal effect. But once you start to swamp the road’s capacity, all the cars slow down more and more. The distance people have to drive has not changed, just the rate at which they can travel. The same is true with assigning projects to resources and to organizations. At a minimal point, we can just assign a handful of projects and they get done quickly—this is a reasonable amount of multi-tasking. But when we assign too many projects and all of them need to get done, the work starts to slow down more and more. This is a big sign of bad multi-tasking, where work and the time to finish our projects is getting more and more stretched out.”

“Interesting, Tim. Our engineers are getting busier and busier. And it certainly seems like they are getting overworked and are slowing down; in fact the more work we add, the more it just piles up and we have to just sit and wait for them to even get to it.”

“This is exactly what we look for in trying to address this area. Give resources clear priorities; focusing resources on key projects versus spreading them out on multiple projects; drive the resources on focused time so they focus on the key task; minimize set up and set down time; encourage quick hand-offs when tasks are completed; and don’t punish resources for finishing early or for when their tasks take longer than the focused time and consume some of the project buffer.”

“This is an interesting observation, Tim. We’ll have to go into this one a bit more when Gary is here.”

“Fair enough.”

“So Tim, project buffers and reducing bad multi-tasking are the key differences that Critical Chain has?”

“Two main differences, but let me share the last two major differences as well.”

“So Randal, there are a variety of approaches to building a project schedule. The one key thing I have seen is that true dependencies are not always called out.”

“Okay…” Randal responds a bit hesitantly.

“In building the schedule, back to front, we first outline the goal of the project. From there, we work backward, in regard to what is essential to accomplish that goal. This helps us identify what is critical and confirm we have captured the true dependencies.”

“Tim, that kinda makes sense, but do you have a real example that I can better relate to?”

“Sure, let me give you my interpretation of one example I have seen. At the time, the industry average for building a semiconductor plant was 54 months. This was based on building the facility, installing the machines, and then training the employees. All of these areas must be operational before revenues from the project would be realized. It was a very involved and linear process. Using Critical Chain, Harris Semiconductor identified and challenged these assumptions. That, in turn, allowed them to significantly compress their entire schedule. They completed an industry average task of 54 months in 13 months. Think three and half years of additional revenue!”

“This example seems to be too good to be true, Tim. From what little I understand, semiconductor plants are extremely complex and involve very technical and experienced people to build them. And people have been building them for years. What could the whole industry miss that Harris didn’t ?”

“You are losing me here, Tim. Why was one large project going to revenue be any better than the multiple sub-projects?”

“It changed the mindset. Instead of just focusing on the sub-project goal of finishing the building, the team was able to focus on how to get the plant operational and generating income. It drove them to think about several key and previously assumed questions. Did you really have to finish the entire building or just key parts before installing the machines? Did you really have to install all the machines before you could start hiring and training? Why could you not train people as each machine was installed and parts of the building were being finished? In this way, they were able to find ways to run large parts of these previously assumed sequential tasks in parallel.”

“Okay, I think I get you Tim. With the teams looking at revenues (throughput of the organization as you would say) as opposed to just the sub-project goals, they focused on the real value of the project. By building the schedule backward from this goal, they could really look at what items were the most important.”

“Exactly.”

“Hmm, I get the ‘set the right goal/throughput’ part. We talked about goal setting in my MBA classes. The ‘building schedules back to front’ part is more of a Gary thing. Perhaps you could walk through an example of this with him.”

“Sure.”

“Tim, goal setting and building schedules back to front does not sound like something exclusive to Critical Chain.”

“Sort of. It is an important piece of building a Critical Chain schedule. And Critical Chain looks at pulling several project management best practices together and having them reinforce each other so it creates a complete solution. You can use some pieces individually and use them with other methodologies, but you would then miss out on the full and combined benefit when you use all of the techniques together.”

“Sure Tim, synergy. The value of the parts working together is greater than the sum of their individual pieces.”

“So Randal, this is the last major piece.”

“Sounds good Tim! My head is spinning and I’m almost out of coffee.”

“So Randal, when you implement any process, its success and value heavily depend on the environment you are implementing the solution into. If the culture does not support the solution, it will not work. If the process only addresses part of the organization’s problems, then the new process may fail to work. This is true for Critical Chain, Agile, Scrum, and so on.”

“Makes sense, Tim. It also explains why some organizations have great success with a proven solution, and others fail miserably with the exact same process. The organization’s willingness to adopt the solution as well as its culture, and the nature of the organization all heavily influence the level of success. I’ve seen case studies highlighting this point time and time again.”

“So the Theory of Constraints Thinking Process (TOC TP) provides a way to do a root cause analysis of your organizations issues. From there, you can not only see which issues the Critical Chain general solution can help you address, but, as important, you can also see what other areas you will need to work on that need to be addressed outside of the Critical Chain solution. This enables you to develop a complete and overall solution that will significantly improve your organization.”

“Makes sense. Can you possibly show me an example another time?”

“Sure.”

“So Randal, all of these areas come to come together to make a more rigorous project management system. We can use the organizational analysis to look at the company’s environment and use Critical Chain to ensure the projects are planned and executed based on bottom line impact and effectively manage project variability.”

“Hey Tim, what about other solutions such as extreme programming, Lean, and Agile? Are all of these mutually exclusive?”

“You can certainly mix project management methodologies, but you really need to have a solid grounding in each of the methodologies you are trying to mix. For example, I have seen people use Critical Chain for the high-level strategic schedule and use Scrum to drive the tactical deliverables into the high-level schedule. In some cases it works really well. In some cases it is put together incompletely and gets poor results. If you really want to learn more about combining methodologies like Lean, Six Sigma, and TOC, take a look at the book Velocity .”