Project Management, as Taught by Eli Goldratt · Lesson 3 of 7
Where the safety goes
Every estimate hides a lot of safety, and almost none of it reaches the end of the project. Goldratt's step-by-step explanation: the long tail of uncertainty, estimates that turn into commitments, Parkinson's Law, the student syndrome, and why gains are never passed on while delays always are.
The common practice, and the common knowledge
The common practice: to make sure the project finishes on time, try to make every task finish on time.
The common knowledge: it is not important to complete each task on time; it is essential to complete the project on time.
The common practice assumes that local optima, each task on time, are the best way to reach the global optimum, the project on time. Goldratt showed why that assumption wastes the very safety that could protect the project.
Estimates become commitments
Projects carry high uncertainty, so task times can’t be determined, only estimated. But the common practice turns the estimates into commitments.
Leo: “How long will the control panel design take you?”
Engineer: “Hmm. I really can’t tell.”
Leo: “I need a number.”
Engineer: “About… three weeks?”
Three weeks later.
Leo: “Three weeks have passed. Why aren’t you finished?”
The engineer learns the lesson. Next time, the estimate will be realistic, and a realistic estimate takes into account that things won’t go smoothly. It embeds safety. An estimate without safety isn’t realistic.
How much safety is in an estimate?
Any estimate with more than a 50% chance of being met embeds safety. With a symmetrical distribution, choosing an 80% estimate adds only a little. But in reality, where uncertainty governs, the distribution is not symmetrical: it has a long tail, and the higher the uncertainty, the longer the tail.
Goldratt’s example: there is a 50% chance a task will be done in under two months, but a 20% chance it won’t be done even in four. To be 99% safe, you would have to estimate more than a year. In most project environments, at least half the estimated time is safety.
And it grows on the way up. Each level of the hierarchy adds its own safety to the estimates beneath it.
Check yourself: you’re asked for one number for a task, you know the probability curve looks like the one above, and you know your number will become your commitment. What do you give?
- A number with a 50% chance
- A number with 80% or more
Almost everyone gives 80% or more. Being considered reliable is a vital interest, and a 50% estimate risks missing the commitment by a mile.
So why don’t tasks finish early?
If estimates carry so much safety, most tasks should finish well before their estimate. They don’t. Follow the logic, from a person’s point of view:
- It is very important to be considered a reliable person.
- So we try as hard as we can to meet our commitments.
- If I give an estimate without much safety, I risk missing it badly.
- So we give high estimates: 80% and up.
- There is constant pressure to be more efficient.
- So we make sure our safety isn’t trimmed.
- If I report finishing early, next time my estimates will be cut.
- So we use the spare time to do a better job, rather than report early completion.
Director: “You finished a month early and fifty thousand under budget? I’m very impressed.”
(To himself:) “Next time I’ll cut his estimates in half.”
People protect their vital interest, being seen as reliable, by giving high estimates and avoiding early completions. The phenomenon is so widespread it has a name: Parkinson’s Law: work expands to fill the time available.
The result is visible in any project data. With high uncertainty, actual task times should scatter widely around the estimates. Instead, a striking number of tasks finish exactly on their estimate. Turning estimates into commitments makes them self-fulfilling prophecies.
The student syndrome
Another mechanism wastes the safety even when people mean well.
Engineer: “I’ve put suitable safety in my estimate. My estimates are realistic.”
Leo: “The previous task finished early. You can start now; you have two extra weeks.”
Engineer: “Plenty of time. What’s the rush?”
Like a student who starts studying the night before the exam, people with safety in hand start late, and then Murphy strikes with no safety left. That is the student syndrome.
Gains are lost, delays are passed on
The two mechanisms together mean gains are not transferred to the next task, while delays are transferred in full. So, despite the large safety in every task, a chain of dependent tasks has little chance of finishing on time. Two more mechanisms make it worse.
Integration: two paths of 12 days and 5 days feed one point; the project is planned for 17 days. The first path finishes 5 days early; the second is 5 days late. How long does the project take?
- 17 days: they cancel out
- 12 days
- 22 days
12 + 5 + 5 = 22. At an integration point, the latest path decides. The early finish of the other path is worth nothing.
Multi-tasked resources: task D needs material from task B, and the resource that is busy on task A. B and A each have a 50% chance of finishing on time. What is the chance D starts on time?
- 50%
- 25%
- 75%
D needs both: 50% × 50% = 25%.
Conclusion so far: there is plenty of safety in projects, but it is masked and wasted by our mode of operation, through Parkinson’s Law, the student syndrome, integration and multi-tasked resources.
Check your understanding
Answer all five. Get four right to complete the lesson.
1. Why does an 80% estimate embed so much safety in projects?
- Task-time distributions have a long tail
- People are lazy
- Managers demand it in every plan they approve
- Software adds it
The higher the uncertainty, the longer the tail.
2. People avoid reporting early completion because…
- They don’t notice
- It is forbidden
- Their future estimates would be cut
- Clients object
Protecting the safety they need to look reliable.
3. The student syndrome means…
- Working overtime near the deadline to recover lost time
- Asking for training
- Finishing early
- Starting late because there seems to be plenty of time
Then Murphy strikes with no safety left.
4. In a chain of dependent tasks…
- Gains and delays cancel out
- Delays are passed on in full; gains are not passed on
- Gains are passed on to the next task; delays are absorbed by the buffer
- Nothing is passed on
Hence projects are late despite padded tasks.
5. Two 50%-likely preconditions give a task a chance of starting on time of…
- 50%
- 100%
- 25%
- 75%
Both must happen.