Critical Chain - Eliyahu M. Goldratt [16]
Agreed.
From the back row, "Can you please repeat the CEO's explanations?"
"Certainly. One: Particularly bad weather. Two: Unforeseeable difficulties at the vendors. Three: Longer than expected negotiations with the Malaysian government. Can you see a pattern here?"
"Yes," Ted is once again the first to answer. "Blame it all on uncertainty."
"Explain."
"Particularly bad weather," he quotes, "unforeseeable difficulties, longer than expected. . . . They are all expressions of uncertainty; of the things that are hard to estimate at the start of a project."
"And you think that there is nothing to it?"
"Not at all," he backs up. "Uncertainty is what typifies projects. It's the nature of the beast."
"If that's the case," I point out, "if that's actually the nature of the beast, then we should find uncertainty underlying the reasons of everybody involved in the project, not just the top managers."
"We do," Ruth quietly says.
We go over Fred's list again. She is right. The project leader's complaints all revolve around the uncertainty. He complains about an unrealistic schedule to start with, unrealistic compared to his estimations of the uncertainties. The vendors were chosen according to cost and not according to their reliability, or in other words not according to their ability to cope with uncertainties. And because of the uncertainty of the date at which the plant equipment would be available, recruitment had to be delayed.
We move to analyzing the complaints of the people reporting to the project leader. The vendors' issue. Surprisingly, initially the class reacted as if it had nothing to do with uncertainties. It took some time to agree that the vendors didn't want to deliberately sabotage the project (a major portion of their pay was pending completion of their job). Why were they delayed? For the same reason Fred's company was; they also suffered from uncertainties. Then we agreed that most fires were a direct or indirect result of uncertainties, and the constant efforts to re-synchronize stemmed from the fires and the ensuing delays.
"Let me summarize," I say. "We observed that fingers are also pointed internally. We agreed that this finger pointing does have merit, and we concluded that the company can do something about it.
"Then we examined the details and reached the conclusion that the thing to do is to better manage the project.
"What we now are saying is that the uncertainties embedded in the projects are the major causes of what we called mismanagement."
"So there's nothing anybody can do," is Charlie's conclusion. "You cannot force certainty on a situation that contains major uncertainties."
These same thoughts haunted me all summer. Is the lousy performance that we witness in most projects a force-majeure? A result of the embedded uncertainty? Or is there something that we can do?
At first it seemed like a stone wall. I would probably have given up, if it weren't for the U-2 example.
I start to steer the class toward the crack Jim showed me.
"Everybody in projects knows that projects involve a high degree of uncertainty. We are not the first ones to conclude it," I remind them. "Why isn't the uncertainty properly factored into the original estimation?"
"Because we cannot," Mark booms.
"What do you mean?" I ask. "Who prevents us?"
"Top management," he answers, and then elaborates, "take my project, for example. It was originally estimated to be completed in thirty months. But top management said that was unacceptable and trimmed all the safety. My boss agreed to try and do it in less than two years, which is an impossibility."
"So, you wanted thirty months and top management forced it down to twenty-four months. The difference is twenty percent. Mark, do you really believe, considering the magnitude of uncertainty in product development, that twenty percent safety is enough?"
"It isn't, but what can we do? Top management doesn't allow us even that."
"I don't think so, but maybe our disagreement stems from the fact that we