The flaw that makes so many tools optimistic
Many tracking tools keep only one amount per line: the current forecast. As long as nothing changes in the contract, the variance against the budget stays visible. But when an amendment is signed, the budget is recomputed from the current forecast, and the overrun accumulated so far disappears into the new budget. The project restarts with green indices, though it has caught up on nothing.
This flaw does not show on screen. It shows in end-of-project reviews, when no one can explain the final variance any more.
A budgeted amount, a re-estimated amount
- The budgeted amount is the one set by the baseline revision, inflation included, for the year in which the line will be consumed. It changes only when a contract amendment produces a new baseline revision.
- The re-estimated amount is the one that every periodic review updates.
The baseline budget is the sum of the budgeted amounts, excluding provision lines. The estimate to complete, the spending still to be committed to finish the project, is read from the re-estimated amounts. It is not one more object: it is the same estimate lines, in the main structure of the current revision, read through their other amount.
Fictional example: an amendment on a work package that is overrunning
The “Software development” work package has a budget of €120,000. At the fourth review, it is re-estimated at €150,000. The client then signs a contract amendment that adds a feature, costed at €40,000.
| Baseline budget | Forecast | Variance | |
|---|---|---|---|
| Before the amendment | €120,000 | €150,000 | −€30,000 |
| Feature added by the amendment | +€40,000 | +€40,000 | |
| After, with a single amount per line | €190,000 | €190,000 | €0 |
| After, in Waterfall | €160,000 | €190,000 | −€30,000 |
With a single amount, the €30,000 overrun is wiped out by the amendment. In Waterfall, the amendment moves only the budget of the lines it designates: the overrun stays visible.
The estimate to complete, task by task
What a line weighs in the estimate to complete depends on the state of its task:
- a not started task is worth what the baseline planned, adjusted for inflation if it has slipped in time, unless the project manager has re-estimated it;
- a started task is worth what the project manager re-estimates;
- a completed task is worth zero. In fact, entering a zero estimate to complete is what completes it, and what makes it earn its value.
The project manager declares that a task has started from a Kanban board. By default, the estimate-to-complete grid shows only started tasks, so as not to bury the review under hundreds of unchanged lines. But a project does not always run as planned, and the grid also lets you re-estimate a task before it starts, or add work that had not been planned. Two reference points accompany the re-estimate: the baseline, what was promised, and the previous review, what was estimated last time.
Unanticipated work does not touch the budget
A task or a line added after the baseline carries a budgeted amount of zero. It weighs on the estimate to complete, never on the baseline budget. It therefore raises the estimate at completion and worsens the cost performance index, which is exactly what it should do: unplanned work is an overrun, not a new budget. The same applies to a risk that has occurred, whose tasks enter the project with a budgeted amount of zero.
The amendment, the only event that moves the baseline
A contract amendment is prepared as a differential: tasks added, others lengthened or delayed, others no longer needed, with the estimate lines that go with them. Several differentials can coexist during a negotiation, and each one is merged or abandoned independently.
At contract award, the differential is merged into the main structure, and the resulting revision becomes the new baseline. The merge follows three rules:
- it changes only the budgeted amounts of the lines the differential designates, and keeps the re-estimated amounts of all lines;
- a task that has already started is never removed: its estimate to complete is set to zero, which completes it and freezes its earned value on what has been done;
- it presents a report before being applied (lines added, modified and removed, tasks that will be completed) and is applied in a single operation, or not at all.
The baseline budget and the contractual milestones then move, and this is the only event that allows it. On the cumulative cost curve, the move appears as a dated step: it is not an anomaly, it is the contract event.
The periodic review, at the organisation’s pace
A review is a new costing, not a mere read-through. The estimate to complete is often collected from work package owners in Excel: Waterfall exports the current estimate to complete, the file circulates, then it is imported back. Each line finds its match by its identifier, only the re-estimated quantities are changed, and a line forgotten in a tab simply keeps its value. These exchanges are described in detail under MS Project, Excel and ERP exchanges.
At organisation level, the “control health” view of the portfolio flags projects whose latest review is older than the maximum interval set in the reference data. The indicators are only as good as the reviews that feed them.