Critical Chain - Eliyahu M. Goldratt [46]
"If that's all you wanted," Charlie says, "then I did find something."
"Let's hear it."
"From my inquiries, one thing came out very clearly." And he makes the following declaration: "The time estimates are impacted, in a major way, by the last overrun the programmer had."
Everybody is laughing. They too are aware of this phenomenon.
Then Charlie continues. "I don't think that there is much point in asking computer programmers to evaluate their chance of finishing on time. Computer programmers will never admit ninety percent chance, not even eighty, because a programmer who finished on time has not yet been born. At the same time, let me tell you, there is nobody like an experienced programmer to pad himself with safety."
Not knowing much about programming, I ask, "Why?"
"It's obvious. Otherwise they wouldn't have the time to add all the bells and whistles that nobody needs. If you don't sit on a programmer, he will never finish, he always has another something he must add."
Thanks to Charlie, the class mood is cheerful again. Even Ted is less gloomy.
"I didn't ask the right questions," he says. "But from my experience I can tell you what the answer will be."
"Yes?"
"Every foreman will say that if everything is ready for him, and that's a big if, then he won't have much difficulty finishing his share on time. They don't talk in terms of probabilities, but they mean over ninety percent."
Now that everybody understands what they were supposed to do, more share their experiences. Their experiences are amusing, but not leading us anywhere.
Not entirely happy, I ask the class, "Does anyone have anything more than just general impressions?"
"Yes," says Mark. "We did force people to give their evaluations. We even prepared a questionnaire for that. It's in our report. As you can see there, except for one person who is known to be paranoid, the vast majority said they think that they have better than an eighty percent chance of finishing on time."
"There is a caveat to it," Ruth adds. "Almost everybody emphasized that their answer is dependent on others not delaying them, and not being loaded with too many other things at the same time."
"That's reasonable," I say. "So, where do you think we stand?"
And I answer my own question. "I think that we did confirm what we said last time. We expected people to give estimates that would give a good chance of finishing their step on time, well over a fifty percent chance. And that's what you found. At the same time, we predicted that people would not realize how much safety this over fifty percent means, and you verified that as well. That basically sums up your findings."
"That's not all," Fred calmly says. "Mark, Ruth and I found something else. We found that five plus five equals thirteen."
"What?"
"It's very common," Mark comments.
"It's very common that five plus five equals thirteen," I repeat. "What kind of a joke is that?"
"Whenever a step in a project is a collection of several tasks, each done by a different person," Ruth explains, "the boss of this project asks each person for their own estimates, adds them up and then adds his own safety factor on top."
"So, if one estimates his task to take five days," Fred continues, "and the following task of the same team is estimated to take another five days, the person in charge will give an estimation of thirteen days."
"I see."
"That's standard," Ted confirms.
"Sometimes," Brian interjects, "there are several management levels involved. Each level adds safety."
This phenomenon is news to me. Considering human nature, it makes sense, but it doesn't appear in the textbooks I have read. "Is this the case at your companies as well?" I ask the class.
Many confirm it.
"There is something else," Fred adds. "In our environment, top management is frequently not happy with the final estimation of when a project is expected to be finished. They want the results sooner. So in half the cases, when all the estimates are