Statoil’s representatives had read The Goal, and were convinced that if anyone could figure out a solution for project management, it would be Eli Goldratt. They gave him two small booklets containing, they said, everything they knew about project management. Goldratt learned that lead time was the key for projects, and that lead time was determined by the Critical Path, a concept first pioneered in the late 1950s. Additionally, he learned that in one of their projects – originally comprised of 40,000 tasks – the Critical Path actually only totaled about 40 tasks, or 1/10th of 1% of the project. The idea that the overall duration of a project is determined by a very small number of tasks captured his attention, and he agreed to work on the problem.

Two weeks later Goldratt boarded an airplane for Oslo. Unfortunately, in spite of the fact he had come to these understandings, he had yet to construct a solution.

"What would I tell Statoil?"

He started going over the situation in his head once again. His thought process went something like this:

1. Critical path provides companies with a fantastic ability to focus. Nevertheless they are chronically late, even when they multiply by 4 and pray!
2. These are not stupid people, and Statoil in particular is the best in the world at projects! Their estimates must be, on average, good enough… How could it be that multiplying by such a large factor still does not provide enough time?
3. There must be a fundamental assumption that is missed, which is devouring the time…
4. The duration of a project is the sum of the duration of the tasks along its critical path…
5. But the actual duration of any task varies – often quite significantly – from the estimate…
6. When a task on the critical path takes longer than its estimate, the whole project takes longer…
7. But when a task on the critical path takes less time than its estimate, the project should be shorter. But this is apparently not happening! Why?
8. Show me how you’ll measure me, and I’ll show you how I’ll behave…
9. If estimated task durations tend to become committed task durations, peoples’ estimates will be inflated to contain enough “safety”…
10. If I am a task manager, since I have lots of safety and there are other urgent tasks, I can afford to start later…
11. If things magically go well and I finish early and report I’m done, I’ll lose my safety for next time, when things might not go so well. So I’d better not report an early finish…
12. If I as a task manager have nothing else to do, and if being idle is frowned upon, I need to look busy—so I’ll pace myself to make sure I don’t finish early…
13. This explains why only delays accumulate…
14. And in projects there are many dependencies and variables… so these behaviors happen over and over again…

As the plane neared Oslo, the answer came to him—the first major premise of Critical Chain:

Remove safety from tasks and aggregate the safety into a project buffer and feeding buffers! Use the safety only when you need it!