Earned Value at Week Six and Three Recovery Options
MetroBank's CRM rollout has a 10-week baseline and a budget of PHP 5,000,000. Work is tracked weekly by earned value. At the end of week 6 the project manager reports: planned value PHP 3,000,000, earned value PHP 2,400,000, actual cost PHP 3,200,000. Of five modules, the customer module and the reporting module are behind; the reporting module alone accounts for PHP 800,000 of planned value and is not on the critical path. A contractor handling data migration quit in week 5. The PHP 600,000 spent on a one-off middleware licence was booked to the project in week 4. The steering committee meets in three days and must choose one of three options. X: add two testers at PHP 300,000 to compress testing by about 0.6 weeks. Y: defer the reporting module to phase 2, freeing PHP 800,000 of remaining budget and about 1.2 weeks. Z: accept the forecast delay and pay a penalty of PHP 1,000,000 per week (pro-rated daily) for delivery beyond week 11.
1. Calculate SV, CV, SPI, CPI, EAC, ETC, VAC and the forecast duration, then explain which of these figures is distorted and how you would present the corrected view to the committee.
Read the worked answer
Straight calculations.
- SV = EV - PV = 2,400,000 - 3,000,000 = -600,000 (behind schedule)
- CV = EV - AC = 2,400,000 - 3,200,000 = -800,000 (over budget)
- SPI = EV / PV = 2,400,000 / 3,000,000 = 0.80
- CPI = EV / AC = 2,400,000 / 3,200,000 = 0.75
- EAC = BAC / CPI = 5,000,000 / 0.75 = 6,666,667
- ETC = EAC - AC = 6,666,667 - 3,200,000 = 3,466,667
- VAC = BAC - EAC = -1,666,667
- Forecast duration = 10 / 0.80 = 12.5 weeks
The distortion. The 600,000 middleware licence is a one-off capital item, not a recurring delivery cost. Including it in AC makes CPI look like a burn-rate problem when part of the overrun is a bookkeeping event. Excluding it: adjusted AC = 2,600,000, CPI = 2,400,000 / 2,600,000 = 0.923, EAC = 5,000,000 / 0.923 = 5,417,000, so the underlying cost overrun is closer to 417,000 than 1,666,667. The committee should see both figures side by side, labelled "including one-off licence" and "recurring only", rather than a single alarming number that would drive them to over-correct.
Second check before the meeting. Confirm that EV is credited only on completed milestones. If the reporting module has been given partial credit for work that is not demonstrable, EV is overstated and every index above is optimistic. The schedule signal (SPI 0.80, two modules behind, a contractor lost) is consistent and should be treated as real; the cost signal is the one carrying the accounting noise.
2. Evaluate options X, Y and Z against the forecast, and recommend one with the reasoning a steering committee can act on.
Read the worked answer
Baseline position. Forecast completion is week 12.5. The penalty applies beyond week 11, so the do-nothing forecast carries about 1.5 weeks x 1,000,000 = 1,500,000 in penalty, which is not in the EAC above and must be added to the business case.
Option X. Costs 300,000 and recovers 0.6 weeks, giving 11.9 weeks - still 0.9 weeks past week 11, so about 900,000 penalty. Total exposure roughly 1,200,000. Adding testers to a late project compresses only testing, and testing is not where the lost 0.8 SPI came from; there is also the classic risk of compressing verification and shipping defects. Weak value.
Option Y. Removes 800,000 of remaining work and 1.2 weeks, giving about 11.3 weeks - 0.3 weeks past week 11, roughly 300,000 penalty. Cost avoidance 800,000 plus penalty avoided 1,200,000 against the do-nothing case. It also removes the module that is currently behind, which is the source of the schedule variance; reporting is not on the critical path, so the dependency risk to phase 2 is low.
Option Z. No recovery cost but 1,500,000 penalty and full scope delivered late; the overrun lands on the customer relationship as well as the budget.
Recommendation: Y, with two conditions. First, confirm the reporting module is not a contractual deliverable for this phase - deferral is a scope change and needs the customer's written agreement or it becomes a dispute, not a saving. Second, use the freed capacity for the customer module and migration, which are the actual critical-path problems, and do not simply release it. Take the 300,000 residual penalty rather than spending 300,000 on testers to reduce it by 600,000.
The committee should also ask why the contractor departure and the migration slip were not escalated at week 5; a two-week reporting lag is itself a management finding.
3. The project manager proposes to re-baseline the plan to 12.5 weeks and 5.4 million so that future reports "look healthy". Assess this proposal.
Read the worked answer
What is legitimate about it. Re-baselining is a normal, controlled response when the original baseline is no longer a realistic yardstick - for example, after an approved scope change or a documented, unavoidable event. If the sponsor and customer formally approve the deferral of reporting and accept the revised dates, a new baseline prevents the team from being measured against a plan nobody believes in, and gives the next SPI/CPI a meaningful reference point.
What is not. Re-baselining to make variance disappear is not a management technique, it is destruction of the only signal the steering committee has. Three things go wrong. First, the organisation loses the historical record of estimate quality, which is exactly what it needs to improve future estimates - the 0.80 SPI and the lost contractor are the lesson. Second, it rewards late escalation: the schedule slipped in week 5 and surfaced in week 6, and a clean new baseline teaches the team that slipping quietly is costless. Third, the 5.4 million figure embeds an assumption (that the licence is the only distortion) that has not been audited.
What to do instead. Keep the original baseline intact and add a second, formally approved baseline with a stated reason, effective date and approvals. Report both: "against original baseline" for trend and estimate-accuracy history, "against current baseline" for day-to-day control. Freeze the old baseline as a record, log the change in the change-control register, and require that any future re-baseline be tied to an approved scope or schedule decision - not to the reporting calendar.
Finally, capture why the estimate was wrong: a single named contractor with no backup for a critical migration activity is an estimating and staffing failure, not bad luck, and it should show up as a risk-register action for the next project.