Re-estimation 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. A project plan is in place consistent with that estimate (in particular regarding schedule and effort) to complete the expected scope.

Question: As part of accepting the initial estimate, is there a decision about "probability of completion" to get an "expected duration" from the risk curve of probability of duration? In English, did someone say, "We want to use 50% as the likelihood of completion, tell me that duration." This relates to how the estimate drives the project plan.

We are now partway through that project, so some of the estimated work has been done.

The trigger: Either periodically throughout the course of the project, at particular defined milestones, or because some particular event triggers the need, a re-estimate to completion (forecast/other terminology?) should be calculated.

Note: What follows is an extract from the specifics of how several estimation suites are used today. There are some questions after the descriptions about this use.

Main Flow:

The estimation tool gathers key metrics about the actual work completed: effort expended so far, size/scope completed (which may be in a different "unit" from the parameter used in the original estimate), measure of the quality (defects found/fixed?) so far.

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 "use case flows categorized by novelty/difficulty" to "lines of code put under change management", the estimation tool must encapsulate the translation).

The estimation tool derives a new expected completion date and expected effort.

Question: Is the new "expected effort" typically broken down by key role, as the original estimate was?

Happy result: The new expected completion date and effort are within the bounds expected, and the project can continue as normal.

Alternate: The new expected completion (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 re-estimate 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")

The estimation tool reruns the project based on the actuals plus the new parameters about the project (important to note that actuals are involved here for question later).

When the "what if" analysis produces a result that the project stakeholders accept. The process for this can vary (main issue for our purposes: how is a possibility communicated to stakeholders and where is the approval workflow? Not in the estimation tool!). Stakeholders can be presented with multiple options to choose from.

The stakeholders accept a new set of parameters and estimate.

The new completion date and effort, plus the changes to the parameters must be incorporated in the project plan. (See later questions)

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

Question: Are these changes in the project management tool, and communicated through the interface to the estimation tool?

These changes themselves may have triggered the re-estimate, rather than the "periodic health check" (my term).

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. (See later questions)

Alternate: The project team thinks internal changes will get the project back on track (heart of the issue: the project plan isn't adjusted, for whatever reason, to the re-estimate)

This could be changes in methods, some changes in personnel that does not affect the effort estimate, reason to believe initial problems are behind them, or just wishful thinking.

The new estimate is "noted", but the project plan is NOT adjusted.

Re-estimates in the future can be done both on the original estimate (well, the one that yielded this result) and a negotiated new set of parameters, giving the team time to "prove" themselves.

Question: How do you document and track the "catchup plan" that's agreed to to get back on track? (might have hierarchy of catchup plans)

See MetricsReEstimateCatchUpPlan

Question: What about risky content or innovative design? "We have some really innovative technology that took a long time to work out, but now that we have, we will move much faster." Could this have been captured in the estimation tools as part of the project assumptions, and recognized in the actuals? It could show up by having a longer nominal schedule, but with reduced risk (lower variance on the probability curve).

Questions for this entire use case:

Question: How does the re-estimate get implemented in the project plan?

See MetricsReEstimateReviseProjectPlan

Question: Is it important that the re-estimate provide a revised "risk curve" so we not only have the new projected end date, but a new probability distribution? That has to take into account actuals ( you can't just do a new estimate of "what's left" as if it's a new project, right?) For OSLC, we don't need to completely settle "how" this is done, just whether it's needed and the appropriate data transferred.

See MetricsReEstimateReviseRiskCurve

Question: How can we distinguish in the actuals the difficulty/novelty of what's been done so far that may explain the stretch in the schedule ("risk first scheduling"). "Not all lines of code are the same". As mentioned, the expected result may be a longer schedule with reduced risk, and this is a good thing.

One important aspect of this: There may have been many stories that are the same level of complexity, but as some of them are fleshed out and fundamental architecture is in place, others will go faster: scope elements are NOT independent; code gets reused.