How do you estimate and plan when your project has too many unknowns and uncertainties? A common shortcut and a wishful thinking is to ‘pad-up’ the estimates with some ‘magic number’ based on past experiences, like +30% effort, or +10% costs, etc. These numbers are then very carefully added at each activity and its sub-activity level. We thus end up inflating the final estimates completely beyond shape. However, many of such projects still end up with delays and cost overruns. Why?
It is human nature to seek comfort in safety. Whenever and wherever possible, we add buffers to trade risk with increased duration or effort for the task. Sometimes, this might be the right way (or, even the only way), but many a times we do it without analyzing if this is the best approach. Consider this nice little story:
It was autumn, and the Red Indians asked their New Chief if the winter was going to be cold or mild. Since he was a Red Indian chief in a modern society, he couldn’t tell what the weather was going to be.
Nevertheless, to be on the safe side, he replied to his Tribe that the winter was indeed going to be cold and that the members of the village should collect wood to be prepared.
But also being a practical leader, after several days he got an idea. He went to the phone booth, called the National Weather Service and asked ‘Is the coming winter going to be cold?’
‘It looks like this winter is going to be quite cold indeed,’ the weatherman responded.
So the Chief went back to his people and told them to collect even more wood. A week later, he called the National Weather Service again. ‘Is it going to be a very cold winter?’
‘Yes,’ the man at National Weather Service again replied, ‘It’s definitely going to be a very cold winter.’
The Chief again went back to his people and ordered them to collect every scrap of wood they could find.
Two weeks later, he called the National Weather Service again.
‘Are you absolutely sure that the winter is going to be very cold?’
‘Absolutely,’ The man replied. ‘It’s going to be one of the coldest winters ever.’
‘How can you be so sure?’ the Chief asked.
The weatherman replied, ‘The Red Indians are collecting wood like crazy.’
Do you plan your project the same way? While an Indian Chief might have all the resources available to collect every scrap of wood to derisk the winter, you might not have such luxury! And even if you do have such luxury – guess what, we actually end up eating the safety margins. Hofstadter’s Law is a colloquial oversimplification of this reality - “It always takes longer than you expect, even when you take into account Hofstadter’s Law”.
This eponymous law seems to hold itself extremely well in software development, which has also been compared to ‘wicked problem’ thus making it extremely difficult to solve. Perhaps, if you include the aspect of time running out and the fact that those seeking to solve it are the ones also causing it, then we can perhaps call it as the ‘super wicked problem’!
So, it is only natural that people add a safety buffer in every task in the hope that the buffer will address all ‘force majeure’ events. However, it could be argued that the statistical probability of all events needing to eat up that safety buffer on a single project is near zero. Surely, some of those events might need such buffer, but certainly not all the activities.
Goldratt discussed this problem so eloquently in Critical Chain that people add-up ‘safety’ to ensure very high chances of completing it. From taking the 50% probability to complete a task to over 90% probability, we probably end up adding 200%-300% schedule to it. However, for primarily three key reasons discussed below, we often still end up not hitting the deadlines:
- Student syndrome: it is natural to negotiate for more time to do something – just so that you have enough contingency buffers to deal with any delays, reworks or simply underestimation of the task in the first place (“planning fallacy“); but once you have that extra buffer, we tend to take it easy for the initial part, and then sprint to somehow complete it just when the deadline start looming over. I believe this happened at Harvard. Students were typically given one week to complete end-term assignments, and pretty much all students would stay awake most nights and somehow complete on time. The professors felt this was too much for students, and decided to make their life easier by giving them two weeks for the assignments. Guess what - the students would party in the first week, and then again sit the whole night in the second week to somehow complete the tasks! Most of us don’t take up the opportunity to ‘early start’ a task until it is inevitable - by which time, it has already eaten up the buffers that were created for precisely those reasons - to handle any uncertainties, delays or rework.
- Multitasking: multitasking is the killer of productivity. If someone is working on several activities at a time and must constantly move back and forth between them, there is a context-switch time that slows down immediately starting the new task. Similarly, even to ‘suspend’ a currently running task, we must ‘save’ its current state so that we can pick it up easily the next time. The worst part is that none of the tasks get completed earlier then if they were take up sequentially – even with assuming zero downtime during the task switch. So, multitasking creates a false impression that progress is being made on all tasks, but doesn’t lead to any improvement in lead time to complete any of the tasks.
- Delays accumulate while advances do not: what happens when you complete a task early? The normal tendency is not to inform your manager – lest you be given lesser time to complete similar tasks in future! Other reasons could simply be do more testing just to be just that before-time completion was not a fluke. Whatever the reason, the end result is that and time saved, or advances, don’t accumulate – we tend to use to completely, but any delays in the task travel downstream. Now imagine if you had buffers in a task that got completed early. Theory says it that you check it in early and start work on the next task thus leading to gaining crucial time in a project. However, in reality, human behavior trumps such wishful thinking, and hardly ever people ‘deposit’ the advances back into project’s buffers. However, the delays, one day at a time, continue to accumulate and suddenly you realize that you are running a month late!
Goldratt presented compelling logic to highlight this problem, and presented a deceptively simple solution – take away individual buffers and manage with a much smaller centralized buffer. Obviously, this is easier said than done – for, how do you change people behavior to forego their safety margins? If people are going to be made accountable for deadlines, it just makes it little tougher for everyone involved. However, each meaningful journey must begin with a small step.
To begin with, do you know the safety margins and wastage in your project?
