.png)
Twitter
Facebook
RSS
Linkedin
Prerequisites
Before the discussion can go any further, the obvious needs stating—to make an estimate we need to understanding what is being estimated. If we lack the experience to create a detailed work breakdown structure, our estimates will be useless. This is true whether you are planning to go grocery shopping or building a house on Mars. The former each of us has done hundreds of times. The tasks need to be broken down into their constituent subtasks, each subtask estimated, and those estimates added together to make a complete timeline and budget. Regardless of the level of planning, repeated execution of the same project will yield different performance results. Grocery lists change, stores run out of stock, traffic backs up, or checkout lines are too long; whatever the reason, the time and cost of any two trips are never the same. To give a good estimate there needs to be a complete understanding of what will influence the project.
If how or what is being built is unclear, do an experiment to see the type of problems that could be encountered. Build a prototype, try something similar, or build a subcomponent. This can help with honing estimates by providing experiential data. It does not obviate the need for estimates; it helps create them. This is the basis for NASA's Cone of Uncertainty principle and a reason that the Agile methodology works—explore so you can predict.
Odds of Completion
For people accustomed to critical chain, this section may be a little remedial. Good estimates will be beat 50% of the time, the rest of the time you will be late. If you are always beating your estimates, you are doing so at the cost of the project's timeline and budget. To understand this better, refer to image at teh top of the article. This is a plot of actual values accrued during workshops where attendees are given the assignment of flipping a quarter and record the results twenty times. By looking at this distribution, a good estimate for this task is about 107 seconds. With this estimate, half the time it will take you less time to do the task and the rest of the time you will be late. However, if you want to be right 80% of the time, you would use an estimate of 170 seconds. Although you will rarely get in trouble for being late on the task, a project made up of these tasks is going to be quite costly. Assume the units were hours, not seconds, and the project required this task reiterated fifteen times. You would have swollen a nominally yearlong project with seven months of pad. With nineteen months to do a twelve-month project, there are too many other factors to create problems. Student Syndrome (procrastinating until the last minute), Parkinson's Law (work swelling to fill available time), the Garage Syndrome (scope swelling to fill available technology), and a sixty percent longer project opens the project to a plethora special cause variations (business fluctuations, management turnover, economic changes, and so forth). In the end, you will most likely fail at the project because it has increased risk.
Tools: Three-Point to Monte Carlo
 |
| Figure 2. PERT Distribution |
The method of doing estimates does not remove this problem. Instead, they have the effect of luring people into treating the estimate as a quote. Three-point estimates (for instance PERT) take a best, nominal, and worst case estimate and perform a weighted average to try to arrive at a value that simulates the midpoint of the estimation distribution. Figure 2 is an example of such a distribution. With a little imagination, you can see its similarity to the normal distribution in Figure 1. The problem is that it is generated from only three values provided by people trying to imagine all the possible problems, and their odds of occurrence. In a three-point estimation process, answers can be biased simply by asking the questions in a more positive or negative manner.
Monte Carlo, on the other hand, looks at schedules and the potential variations for each task and derives the most likely completion time. It generates a distribution much like that in Figure 1. However, instead of using empirical data from prior projects, it takes distributions for each task, the combinations of how those tasks fit into a schedule, the effects of the variation on the critical path, and determines the most likely time to the complete the project. If the project was run fifty or a hundred times, half would finish in less time, the rest would be late. If it were not for this fact, born in statistics, the estimate would be wrong.
Poor Estimates Result in a Lack of Urgency
In reality, humans make estimates and we rarely have sophisticated tools to help us see all the risk. Therefore, we need to choose a value that has slightly better chances than 50:50 of being met—maybe 60:40. This accounts for our natural optimism and the reality that some of the strangest events get in the way of completing assignments. Choosing an estimate the gives us an eighty or ninety percent chance of success creates a lackadaisical approach and we struggle, often failing, to complete the task on time.
Corporate culture has conditioned people to provide estimates that can be met ninety percent of the time. Managers and individuals use the pad to achieve other goals, none of which are focused on getting the project done faster or at less cost. The only solution is to educate people on providing real estimates.
.png "Filling Exectution Gaps cover")
.png "Buy RPP on our site")
