Miracle Workers

One of my favorite movie scenes is in Star Trek III: The Search for Spock. Of course, the Enterprise has some mechanical problems. Kirk asks Engineer Scott, “Scotty, how long will it take to make the repairs?” Scotty replies,”Eight weeks, Captain; but you don’t have eight weeks, so I will do it in two weeks.” Kirk says, “Have you always multiplied your repair estimates by a factor of four.” Scotty’s response is, “Of course. How do you think I keep my reputation as a miracle worker?”

One problem with estimates that are not based upon some quantitative method is not really knowing if estimate has been inflated or not. It just seems like the team is coming in under budget and cost; but in reality, the original estimate was just over inflated.

In the end, an estimate that has been inflated or one that is understated is not wanted. The inflated estimate causes resources to be underutilized, and the understated estimate causes a lot of stress and frustration among team members.

Tom DeMarco has an interesting definition of an estimate. He defines an estimate “as a prediction that is equally likely to be above or below the actual result.” Often I ask an estimator, “What is the probability of being 20% over budget and late?” Normally they have an answer. Then I ask, “What is the probability of being 20% under budget and early?” This generally causes confusion. Generally, there is no chance being under budget or early. What is being said is that if one thing goes wrong, or if anything unexpected comes up, then the schedule and/or budget will not be met.

Ultimately, everyone wants estimates with the highest possibility or probability of being correct. If an estimate has an equal amount of possibility to be early as late, then this is the highest probability. Imagine a bell curve for a moment. At the peak of the bell curve (the mean value) the most likely outcome. This should be the estimate. If, on the other hand, an estimate has no probability of being early, then it has just about zero percent possibility of actually happening and about 100% probability of being late. In other words, the estimate is to the far left side of the bell curve. A good estimate should have an equal probability of being early or late.

When estimates are derived based upon past historical performance (historical data), there should also be a derived margin of error. The margin of error allows confidence intervals (upper and lower boundaries) to be calculated. The width of the confidence interval measures project risk.

I was working at Sprint for Bob who is a retired Marine Corps colonel. I completed an estimate, and when I presented it to Bob, he looked at and said, “I don’t believe this. Go back and rework the numbers.” I went back to my desk and re-checked the numbers, and I considered reducing the estimate. I went back to Bob’s office and said, “I am pretty sure these number are right.” Bob barked back at me, “Pretty sure?” Feeling a bit insecure, I left his office again with my tail between my legs. I sat thinking for a few minutes at my desk. I returned to his office. Again, he said, “Longstreet, I told you not to come back until you re-worked those numbers.” I stopped him and said, “With all due respect, sir, I have spent a lot of time on this. I have checked and I have doubled checked and I am positive this is right.” He looked up, smiled, and said, “Good.” He paused and said, “If you are not willing to stand up to your boss with your estimate, then why should I be willing to stand up to my boss with your estimate.” By the way, Bob’s boss was the chief financial officer.

When an estimate is based upon some quantitative process, it is easier to stand behind the estimate. When the estimate is based upon a guess, there is more likelihood to cave when pressure is applied. The reason for this is simply a lack of confidence in the estimating process. The only thing to change about an estimate is the inputs used to generate an estimate. If the estimate is too high, then functionality needs to be reduced.