One Forecast, Two Very Different Variances
At the end of month 4 of a 12-month ERP rollout, the project manager reports budget at completion of $1,200,000, planned value of $400,000, earned value of $340,000, and actual cost of $410,000. Two events explain the numbers. First, a three-week delay in the finance-module data migration was caused by the client's data owner being unavailable; that owner has now been assigned to the project full-time and the migration is complete. Second, three of the five interfaces delivered so far required rework because the vendor's API documentation was wrong. The vendor has not yet corrected the documentation, and the same team is scheduled to build the remaining six interfaces. The sponsor asks whether the project is over budget. The finance director wants a single number for the forecast.
1. Calculate the cost and schedule performance indices and a forecast, and explain what each number does and does not tell you.
Read the worked answer
Calculations
- CPI = EV / AC = 340,000 / 410,000 = 0.83
- SPI = EV / PV = 340,000 / 400,000 = 0.85
- EAC (CPI-based) = BAC / CPI = 1,200,000 / 0.83 = ≈ $1,447,000
- ETC = EAC − AC = 1,447,000 − 410,000 = ≈ $1,037,000
- VAC = BAC − EAC = 1,200,000 − 1,447,000 = ≈ −$247,000
What this says: roughly 15% behind plan on schedule, 17% behind on cost efficiency, and - if the current cost efficiency persists - a finish around $250,000 over budget.
What it does not say: whether either variance will persist. That is the question the indices cannot answer for you, and it is the question that actually determines the forecast.
- The schedule variance is atypical, with a known, identified, already-corrected cause. SPI is a poor predictor here; it will improve on its own.
- The cost variance looks typical, with a systemic cause: wrong vendor documentation plus six interfaces still to be built by the same team. Nothing about that cause has changed.
A single index applied to both variances would mislead in one direction or the other.
2. Should the project manager present the CPI-based EAC to the finance director as the answer?
Read the worked answer
Not as a bare number. Present it as the starting point, then refine it to a range with stated assumptions.
Why the raw EAC is directionally right but numerically weak: CPI-based forecasting assumes the remaining work will be performed at the same cost efficiency as the work to date. Here, part of the historical inefficiency came from rework on five interfaces - three of which are done and will not be rebuilt. The remaining six interfaces may or may not hit the same defect rate, depending on whether the documentation is fixed first.
A better forecast:
- EAC = AC + bottom-up ETC for the remaining work, with rework explicitly costed per interface. If the team expects a similar hit rate on six interfaces that is a much larger number than on five; if the vendor corrects the documentation first, it may be nearer zero.
- Present a range - for example, a low case assuming documentation is corrected and a high case assuming it is not - with the assumption that drives each end.
Why the range matters: a finance director who is handed $1,447,000 as a fact will plan against a number that may be wrong in either direction. A finance director who is handed a range plus the one condition that determines where in the range the project lands can act on it - including acting on the vendor. That is a forecast, not a guess with a decimal point.
3. What should the project manager do about the vendor documentation and the remaining six interfaces?
Read the worked answer
The cost variance has an addressable root cause, and the project manager should address it rather than forecast around it.
- Make the vendor correct the documentation - formally, through the contract, with a date. Every remaining interface built against wrong documentation repeats the rework. This is a procurement and contract administration action, not a technical one, and it belongs in the issue log with an owner.
- Add a verification gate before each remaining interface build: confirm the specification against the actual API behaviour with a thin integration test. Cheap up front, expensive if skipped.
- Do not recover the overrun by cutting testing. The variance was caused by defects; removing the controls that catch defects converts a cost variance into a production incident.
- Re-baseline only with sponsor approval. If the sponsor accepts the revised forecast, re-baseline and manage against the new number; if not, keep reporting against the original baseline with the forecast attached. Do not quietly move the target.
- Communicate monthly in EVM terms - PV, EV, AC, CPI, SPI, EAC, ETC - with a two-line explanation of the drivers, so the finance director can see the trend rather than one snapshot.
The judgement: distinguish a variance you can still influence from one you can only report. The documentation problem is still influenceable today and will not be in eight weeks.