# The Uncertainty of Scheduling the Future

PM Milestone Project Management Templates

Get Instant Access

Recognize the uncertainty principle at work (see Chapter 14). The planned schedule is just the team's best guess of the future. It does have some allowance for uncertainty management with time reserves built into it, just as management builds cost reserves into their business plans. But you and the team are not psychic and cannot predict the future with accuracy (if management or your customer can, then you and your project team can remove the uncertainty buffers and contingencies from your schedule, and management and the customer can absorb any overruns!). If they are better than most at predicting future events, then they should probably retire and just trade in the stock and commodity markets.

Remember that the output of the project is a deliverable (what the customer cares about) by a certain date, with a certain percentage probability of meeting the date. When you and the project team jointly construct the WBS, estimate the activity durations, and build the schedule, you will add enough contingency buffers to comprehend reasonable uncertainty, and give you about a 95 percent confidence level in the predicted end date. This 95 percent probability distribution is shown graphically in Figure 15-3.

Figure 15-3. Uncertainty of the Project End Date Estimate

Figure 15-3. Uncertainty of the Project End Date Estimate

### The Psychology of Estimating

Chapters 10 and 11 describe an excellent set of software estimation methods and tools for helping us to create activity effort estimates. But in the end, judgment is applied and a "final number" must be put into the plan. Let's look for a moment at how the average software engineer thinks through this judgment. When presented with an activity estimation problem, the estimator's thought process before announcing their estimate goes something like this:

"Based on my COCOMO analysis, the effort estimate is about three weeks for this component." "But there are a lot of uncertainties yet to be uncovered, so I'll double the effort estimate to cover them." "And I won't be able to focus on just this activity because I'm contributing to two other projects." "So I'll report my effort estimate for this activity on this project as 10 weeks."

This process is illustrated in Figure 15-4. What's happening here is that the estimator is padding the estimate to account for the uncertainty in the situation. They don't want to be held accountable for the three-week estimate (with only a 50 percent chance of achieving that). Instead, they want about a 99 percent chance of meeting expectations, so they end up following an old rule-of-thumb estimating trick called "double it and add some." Essentially, about two thirds of the total time allotted for the activity is just contingency buffer. The effect is that the estimator gets to manage the use of the buffer to their benefit (to keep them from looking bad by being late with their part).

Figure 15-4. Another View of the Uncertainty Distribution

Figure 15-4. Another View of the Uncertainty Distribution

Once scheduled this way, people tend to exhibit what Eliyahu Goldratt called the "student syndrome," where they procrastinate on their planned activities in order to finish up the ones they were already committed to, on this or another project, because they had nearer-term ill deadlines to worry about.1â€”1 They use up the uncertainty they planned into each activity at the beginning, leaving the bulk of the real work to be started at about the two-thirds point in the available activity time. This is OK if their initial COCOMO (or SLIM) estimate was right. But if not, they go into crash mode to finish the activity by the date they committed to. Goldratt named this phenomenon after the way students tend to put off doing their term paper until the night before it is due.

Unfortunately, if done for every activity in the WBS and translated to the project schedule, this causes all the uncertainty of the project schedule to be managed by the individuals on the team, rather than by the project team as a whole. And, if they all have student syndrome, then there is nothing but outward pressure on the project's finish date. This helps explain why most software development projects run late and few finish early.

A better way to manage the uncertainty is to try to extract the initial raw estimates and put those durations into the project plan, recognizing that each one will only have a 50 percent probability of completion. These are aggressive estimates. Move the uncertainty portions of the activities into explicit phase, or project, buffers so the project team can manage the uncertainty of all the activities as the project is executed and tracked (see Chapter 25. "Project Tracking and Control"). Figure 15-5 illustrates how the durations for individual activities are reduced, and the uncertainty time is moved to a project-level contingency buffer where it can be more effectively managed.

Figure 15-5. Move Activity Uncertainty to Project-Level Contingency Buffers

Figure 15-5. Move Activity Uncertainty to Project-Level Contingency Buffers

Since the calculated estimates have only a 50 percent chance of meeting their effort estimate, some will finish late and their estimated finish dates will slip out. Any slippage should be subtracted from the phase or project's contingency buffer. However, some others will finish early because of the 50 percent estimate. The time gained from those should be added to the phase or project's buffer. This means that on average, buffer consumption should be close to averaging out. In any case, the whole project team can watch the buffer consumption as it expands and contracts during project execution, and take appropriate action to keep the real 95 percent confidence-level project due date protected from the vagaries of uncertainty. We'll look into this more in Chapter 25 when we discuss project tracking and control.

^ previous

Free Open Study >

* previous