Estimate at Completion: What Question Are You Really Answering?
An estimate at completion looks like arithmetic and is really a judgement. Every version of it takes what has been spent so far and adds a prediction about the rest, and the prediction rests on an assumption about whether the recent past is a guide to the near future. Change that assumption and the same project produces forecasts that differ by a substantial margin, all of them defensible.
Section 2.4 of the PMBOK® Guide Eighth Edition treats forecasting as part of managing a project's financial performance, and the useful discipline is to say which question you are answering before quoting a number.
Three assumptions, three answers
The rest will go to plan. Take what has been spent and add the remaining work at its original estimate. This assumes the variance so far was caused by something that has finished: a one-off remediation, a supplier issue now settled, a mistake in an early package. It is the most optimistic basis and it is correct surprisingly often, provided somebody can name the thing that has stopped.
The rest will go the way the last few months went. Take what has been spent and adjust the remaining work by the efficiency seen so far. This assumes the cause is structural: an estimating optimism that applied everywhere, a team less productive than assumed, a rate that was wrong. Where nobody can name a specific one-off cause, this is usually the honest basis, and it is the one most resisted, because it produces the largest number.
The rest will be re-estimated properly. Take what has been spent and rebuild the estimate for the remaining work from the current understanding of it. This is the most accurate and the most expensive, and it is what should happen at major inflections: after a significant design change, at the end of a phase, when the first real productivity data arrives.
Choosing the assumption
Name the cause of the variance. Not the category, but the actual thing: the ground conditions in the eastern half, the third-party interface, the two people who left in March, the fact that every estimate in the original submission was built by the same optimistic engineer. A forecast produced without a named cause is a calculation performed on ignorance.
Ask whether the cause is still present. That single question chooses between the first two bases. A supplier problem resolved by changing supplier has gone. An estimating optimism that ran through the whole original submission has not, and will continue to express itself in every remaining package.
A platform programme that kept assuming it was over
A broadcaster's platform team was rebuilding its content delivery stack, an eighteen-month programme with a substantial capital budget. By month seven it was about eleven per cent over the spend profile.
Each month the forecast went to the steering group on the first basis: the remaining work at plan. Each month there was a reason for the overspend, and each reason was genuine. A contractor had been brought in to cover a vacancy. Additional environment hire had been needed for a test window. The office had run out of space, so a block of desks had been hired, and a portable air conditioning unit had been brought in because the hired block had no ventilation.
None of those was a one-off, which is what nobody said out loud. The vacancy was never filled and the contractor stayed for the duration. The environment hire recurred every test cycle. The desks and the air conditioner, taken for six weeks, were still there eleven months later with the duct taped into a propped window.
Rebuilt on the second basis, in month nine, at the insistence of a new finance business partner, the forecast rose by about four hundred thousand pounds and was accurate to within three per cent at closure. The programme was not in worse shape than it had been the month before. It had simply stopped assuming, every month, that the thing which had happened for seven consecutive months was about to stop.
The steering group's reaction was the interesting part. They were not angry about the number; they were angry that eight previous forecasts had implied something nobody believed. Two of them said they had assumed the reported figure was optimistic and had been privately adding to it, which is what happens to the credibility of every forecast from a project that never revises upwards.
Reporting a forecast honestly
State the basis with the number. One line: this forecast assumes the remaining work runs at the efficiency of the last three months, or this forecast assumes the rate issue in the first package does not recur. The line costs nothing and it converts an unarguable number into something a governance group can challenge intelligently.
Revise it when the assumption fails. A forecast made on the basis that a cause has gone should be corrected the moment the cause reappears, and not at the next quarterly review. Forecasts that only ever move at reporting boundaries teach everybody that the number is a reporting artefact.
For a PMP® candidate, what matters is that a forecast embeds an assumption about whether past variance will continue, so a scenario asking which forecast to use is asking what caused the variance and whether it persists. A response that selects a formula without establishing the cause has chosen an assumption by accident. Situations where several forecasts are defensible and only one matches the evidence are the kind a structured PMP exam preparation course sets out.
Look at your current forecast and write down, in one sentence, what it assumes about the remaining work. Then show that sentence to somebody doing the work and ask whether they believe it. Their answer will be quick, and it is the cheapest forecast review available.
Interested in going further?
A forecast that never moves upward stops being believed, and the credibility is harder to recover than the money. Omega's PMP® Exam Preparation works through forecasting as a judgement about causes rather than a choice of formula.
Forecasting and financial performance are covered in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A123: The PMBOK 8 Finance Performance Domain: What It Really Covers
A127: CPI and SPI Explained Without Formula Memorisation
A128: Do You Still Need to Memorise EVM Formulas for PMP?
A125: Budget vs Cost Baseline vs Funding
A126: Contingency Reserve vs Management Reserve
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
