Reestimation use case:

The situation: A project had an initial estimate relating scope (size), a probability curve of duration, a resource plan by role, leading to an estimate of total effort (and, indirectly through resource rates, cost), and a projected level of quality, in addition to other parameters that described the project. In addition, a "level of confidence" was chosen to plan against--what probability should duration, effort, quality, and size be estimated at for on-going management of the project.

We are now partway through that project, so some of the estimated work has been done. A project plan is in place consistent with the estimate (in particular regarding schedule and effort) to complete the expected scope.

ASSUMPTION: There's an expectation that the estimate and the project plan stay somewhat in synch--they may not track exactly, but if the project plan and the estimate are unrelated, why do we have both? The purpose of the estimate was to plan the project, right?

The trigger for reestimation: Either periodically throughout the course of the project (e.g. every week or every month), at particular defined milestones, or because some particular event triggers the need, a reestimate or "forecast to completion" is calculated.

Main Flow:

The estimation tool gathers key metrics about the actual work completed: effort expended so far (and, as usual the computed labor cost based on roles/rates), size/scope completed (which may be in a different "unit" from the parameter used in the original estimate) up to this point, measure of the quality (defects found/fixed) so far, schedule milestones reached.

The estimation tool uses the original assumptions about expected size, quality level, and team size. (Note: since the unit of size may have changed, for example, from "user epics categorized by complexity" to "lines of code put under change management", the estimation tool must translate the size metric to compare actual to planned).

The estimation tool derives a new expected completion date and expected effort. Note the difference from the original estimate is that the estimate to completion is based partly on the Scenario assumptions and updated assumptions about the rest of the project, and partly on actuals.

The estimate to completion is at a particular level of confidence (typically 50%) but can also be compared to a high-assurance plan at a higher level of confidence.

Happy result: The new expected completion date and effort are "close enough" to the current project plan, and the project can continue as normal.

Alternate Flow 1: The new expected completion date (or effort?) is out of the tolerable range, and the project plan needs to be changed:

The project manager and estimator engage in "what if" analysis, seeing what changes need to be made to get the project into tolerable range (classic example: schedule is too long):

• a) The new estimates can be accepted. The project manager adjusts the duration of the project plan.
• b) The estimator can change the expected size ("shed scope"), and rerun the projection until the schedule is brought into acceptable bounds (which certainly may be longer than original, but not as much as the first reestimate showed)
• c) The estimator can change the expected team composition ("add resources"). The estimation tool must encapsulate the non-linear effect of changing resources ("mythical man-month") on duration.
• d) The estimator can change the expected quality level (example: "We were originally trying to be the first on the market and at the same time be the "high quality provider" but since we're running late, first to the market is more important")
• e) The project team can address a bottleneck through changes in methods or technology, and see in future measurements whether that was effective in getting back on plan.

The estimation tool reruns the project based on the actuals plus the new parameters about the project .

When the "what if" analysis produces a result that the project stakeholders accept, the new estimate is used for project rebaselining.

The stakeholders accept a new set of parameters and estimate.

Alternate Flow 2: There are changes required to the project. For example, stakeholders may have increased the scope, or resources may be lost.

These changes themselves may have triggered the reestimate, rather than the "periodic health check".

The flow is essentially the same, though, as the "out of bounds flow"...the estimator changes the parameters, and new projection, based on actuals plus the new parameters is run.

Either the result is acceptable or the "what-if" analysis is done and tradeoff negotiation done.

The new completion date and effort, plus the changes to the parameters must be incorporated in the project plan.