Chapter 12
This chapter talked about a steel company and how its people focussed on a metric (tons per hour), which drove them to go after local optima while sacrificing the global optimum.
To make a long story short, they became convinced that all the other problems were either relatively insignificant or were significant because of the existing chaotic environment. There was a real, true consensus that the core problem, the constraint of the company, was the fact that their prime operational measurement was tons-per-hour.
Don pointed out to them that this was actually very good news. Yes, very good news, because all their competitors suffered from exactly the same core problem. Correcting it would give this company a tremendous advantage.
even if the other companies didn't do this, it's good news.
----
Chapter 13
This chapter gets back to the problem of figuring out how much safety people put into their estimates.
“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."
“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."
... "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."
“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 each step gets it's own safety. and then a collection of steps are combined into a single step, and that combining acts like a step too, needing it's own safety.
“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 done, they demand the lead time of the project be cut by, say, twenty percent. This global cut is usually translated into everyone, across the board, having to cut their times by twenty percent. By now everybody is used to it, so they inflate the final estimates by twenty-five percent to start with."
that's funny. it's similar to how in some cultures people are expected to come late to a scheduled social gathering and to deal with that sometimes people will lie about the starting time of an event, like they'll subtract an hour.
I turn to the board and draw two boxes. "Suppose these boxes represent two consecutive steps in a project. The estimated time for each step is ten days. Now suppose that the first step took twelve days. That means that the second step will start two days later than planned. That's obvious. But what will happen if the first step finishes in eight days?"
"Is it a trick question?" someone asks.
"If the first step finishes in eight days, when will the second step start?" I repeat my question.
A light is coming on in Ted's eyes. "It will start when it was originally planned to," he confidently states, and smiles.
“Why?”
"Because the team that finished ahead of time wont report it. You see, the way we are set up, there is no reward for finishing early, but there is, in fact, a big penalty." And he explains, "If you finish early you just invite pressure from management to cut the times. Your friends, in charge of other similar teams, will not like it, to say the least."
This reminds me of companies that pressure individual awesome workers to produce less so he doesn't make the other workers look bad. I guess they think other workers looking bad somehow worsens their productivity.
... "We try to protect the performance of each step." That sounds to me like a cost world mentality. "The only thing that counts is the performance of the project as a whole." That sounds much more like the throughput world mentality. Is it possible that we are facing here the conflict that Johnny Fisher was talking about? Is it possible that bad performance is the result of a wrong assumption? What assumptions have we made?
skipping ahead...
“How can they," Mark agrees. "I think that their priority system is according to who shouts loudest. And every project has several people who know how to shout."
ugh. that's a very nasty way to set priorities. it's like a standard way people act, not just in business. I guess lacking rational prioritization methods means having to rely on irrational prioritization methods.
No comments:
Post a Comment