How we should focus the discussion: Look for "what information does the estimation tool get from PPM and what does it provide to PPM for use by the portfolio manager" Secondary (since the estimation tool providing the api is not the focus of initial implementation): What does PPM need from estimation tool on demand about the re-estimate (i.e. what can PPM GET from estimation), and what does PPM send (PUT, POST) to the estimation tool. Sounds the same, but "who asks" and who uses the information is different.

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. 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 TO DISCUSS: 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 re-estimation: 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 re-estimate 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.

QUESTION: Are there also some "actuals" gathered related to schedule/duration, such as "how many of the expected iterations have actually been completed", or "when did we actually reach some planned milestones", so that an actual value can be compared to an estimated value, or is it just "how many months have passed since we began", and that's used to determine the expected value of the effort, size, and quality metrics based on the estimate at the chosen level of confidence?

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 project is based partly on the Scenario assumptions, and partly on actuals.

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

Question: Is the new "expected completion date" only at the chosen level of confidence, or do you get a new risk curve? This is related to the "cone of uncertainty"--the project manager wants to see the uncertainty reduced, i.e. the risk curve has a sharper slope in the middle of the "S". It's a useful result if the "nominal" duration is longer, but the risk is reduced.

(these questions, plus the issue of "assumptions + actuals" affect how the XML format of a re-estimate differs from that of an original estimate)

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 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.

Question: How does the re-estimate get implemented in the project plan? What resources about the estimate or about the project plan need to be exchanged through OSLC to make use of the re-estimate to adjust the project plan?

Alternate Flow 2: 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.

Question: Is this just like doing the initial estimate, or does the fact that there are some actuals affect the estimate? Do we get a risk curve for just the rest of the project?

Alternate Flow 3: 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: 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. ("Narrow the cone of uncertainty")

See MetricsReEstimateReviseProjectPlan

See MetricsReEstimateReviseRiskCurve