Ads
  

The Uncertainty of Scheduling the Future

The Uncertainty of Scheduling the Future

Recognize the uncertainty principle at work (see "Considering Dependencies"). 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 1.

Uncertainty of the Project End Date Estimate

Letting you and your team get squeezed down to a 5 percent confidence level doesn't really gain much for you, management, or the customer. Business is full of risks and rewards, so it is good practice when announcing expected completion dates to also mention the probability of achievement. For instance, say "Our analysis of the work required indicates the project can be completed as described (the scope) with 19,500 hours of effort by 15 full-time-equivalents (the cost) by November 15th (the schedule) with an 85 percent probability." Software development project management is mostly about managing expectations using industry-accepted approaches and technology. So, try not to get into the game of padding and cutting. Don't invalidate your estimation methods by reducing your estimates. They are not negotiable; they are estimates. Instead, rely on your team's best technical judgment for the activities, and insert contingency buffers into the schedule in enough places to absorb the uncertainty of estimation (normally at the end of major phases). If management or the customer says the finish date is too late for them, then ask what date is acceptable and treat that as a project constraint. Now your planning should manipulate the resources required, and perhaps look for additional soft dependencies to overlap more activities and try to achieve a high-confidence-level schedule for the customer's desired finish date. If you cut features (reduce scope) then you can remove their portion from the estimates in the calculations. All of this means that you really should be targeting to finish all the planned work well before the due date.

The Psychology of Estimating

"Software Size and Reuse Estimating" and "Estimating Duration and Cost" 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 shown in Figure 2. 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." Basically, 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).

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 deadlines to worry about. 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 "Project Tracking and Control"). Figure 3 shows 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.

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 "Project Tracking and Control" when we discuss project tracking and control.


Tags

deliverable, wbs, software estimation, software development project
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus