“$7k under budget” was wrong: earned value on a real system rollout, month by month
At the end of August, Ledger had spent $363k against $370k planned. A budget report would call that good news. Earned value showed the project behind schedule and over cost, pinned the cause to one control account, and forecast the final cost within 1%.
At the end of August, the Ledger program had spent $363,000 against a planned spend to date of $370,000. A simple budget-versus-actual report would say “$7k under budget, all good.” It would be wrong, and dangerously so, because it ignores how much work the $363,000 bought.
Earned value management fixes that by adding a third measure: the budgeted value of the work actually completed. It's examined heavily on the PMP, where it's usually taught as formula drills. Here it is on a real-looking project, with every number traceable.
The three measures
| Measure | Question it answers | Ledger, end of August |
|---|---|---|
| PV: planned value | How much work should be done by now? | $370k |
| EV: earned value | How much work is actually done, at its budgeted value? | $352k |
| AC: actual cost | What did the work done cost? | $363k |
| BAC: budget at completion | The total budget for the work (excluding management reserve) | $600k |
The numbers came from three places. PV came from the performance measurement baseline. AC came from Coupa invoices, accruals for work done but not yet invoiced, and internal hours at a standard rate. EV was calculated per work package using the earned value rules written into the cost management plan, and reviewed with each control account owner.
Variances and indices
| Formula | Ledger, end of August | Meaning |
|---|---|---|
| CV = EV − AC | 352 − 363 = −$11k | Over budget for the work done |
| SV = EV − PV | 352 − 370 = −$18k | Behind schedule: less work done than planned |
| CPI = EV ÷ AC | 0.97 | $0.97 of work for every $1 spent |
| SPI = EV ÷ PV | 0.95 | Progressing at 95% of the planned rate |
So the project was not under budget. It was slightly over cost and behind schedule. The useful question is where.
Where: one control account explains half the problem
| Control account | PV | EV | AC | SPI | CPI | Note |
|---|---|---|---|---|---|---|
| 1 Program management | 48 | 48 | 50 | 1.00 | 0.96 | Level of effort; PM overtime during the SSO issue |
| 2 Requirements & design | 80 | 80 | 79 | 1.00 | 1.01 | Complete |
| 3 Configuration | 115 | 108 | 110 | 0.94 | 0.98 | Sprint 4 demo accepted 2 Sep |
| 4 Integrations | 75 | 66 | 75 | 0.88 | 0.88 | SSO/SCIM interface at 50%; workaround cost |
| 5 Data migration | 27 | 25 | 26 | 0.93 | 0.96 | Trial load re-run |
| 6 Testing | 14 | 14 | 13 | 1.00 | 1.08 | SIT preparation |
| 7 Deployment & enablement | 11 | 11 | 10 | 1.00 | 1.10 | Training videos |
| Total | 370 | 352 | 363 | 0.95 | 0.97 |
Above threshold (±10% triggers a steering committee item): integrations, CV −13.6%, SPI 0.88. Cause: the vendor's SSO connector failed testing (issue I-04). Change request CR-02 approved 26 August.
The breakdown changes the conversation. The project isn't uniformly slipping. One control account explains half the cost variance and half the schedule variance, and it has a known cause and an approved response. Without the breakdown, a steering committee might have demanded across-the-board savings from teams that were on plan.
Forecasting: four honest ways to say where you'll finish
The estimate at completion (EAC) depends on what you believe about the remaining work. Here are the four standard methods on Ledger's August numbers:
| Method | Assumes | Ledger EAC |
|---|---|---|
| BAC ÷ CPI | Future work runs at today's cost efficiency | $619k |
| AC + (BAC − EV) | The variance was a one-off; the rest goes to plan | $611k |
| AC + (BAC − EV) ÷ (CPI × SPI) | Schedule pressure will also cost money | $632k |
| AC + bottom-up ETC | The original estimate is no longer valid; re-estimate | $625k |
Priya, the program manager, reported the bottom-up $625k as the official EAC and showed the formula methods as a range ($619k–$632k). Her reasoning was explicit. The integrations overrun was partly a one-off (the vendor's defect), so the second method was too optimistic, because some workaround costs would continue. The third was too pessimistic, because go-live was being protected by fast-tracking rather than overtime. The steering committee saw one number with a credible range around it.
The to-complete performance index asks the reverse question. To finish on the original $600k, the remaining work would have to run almost 5% more efficiently than planned: (600 − 352) ÷ (600 − 363) = 1.046, when the project had so far run 3% less efficiently. A warning, not an impossibility.
Changing the baseline, without hiding anything
On 27 August the cost baseline was revised to reflect three approved changes: CR-02 (+$18k of partner hours for the SSO delay), CR-03 (+$26k for VAT capture in six countries) and a saving returned to contingency (−$15k of free migration tooling). The new BAC was $629k. Because the money came from contingency, the overall cost baseline stayed at $695k; contingency fell from $95k to $66k. Two rules made this legitimate:
- Only approved changes change the baseline. The −$11k August variance stayed in the record and in the forecasts.
- Re-baseline the future, not the past. Planned value to date stayed as it was; the change budgets were spread over September and October.
The whole year
| Month-end | BAC | PV | EV | AC | CPI | SPI | EAC (method) | Contingency |
|---|---|---|---|---|---|---|---|---|
| Jun | 600 | 120 | 118 | 117 | 1.01 | 0.98 | 600 (plan) | 95 |
| Jul | 600 | 240 | 236 | 238 | 0.99 | 0.98 | 606 (BAC ÷ CPI) | 95 |
| Aug | 600 → 629 | 370 | 352 | 363 | 0.97 | 0.95 | 625 (bottom-up) | 66 |
| Sep | 629 | 512 | 497 | 507 | 0.98 | 0.97 | 642 (BAC ÷ CPI) | 66 → 62 |
| Oct | 633 | 579 | 572 | 583 | 0.98 | 0.99 | 645 (bottom-up) | 62 |
| Nov | 633 | 618 | 612 | 624 | 0.98 | 0.99 | 645 (bottom-up) | 62 |
| Dec (final) | 633 | 633 | 633 | 645 | 0.98 | 1.00 | Actual 645 | — |
Outcome: final cost $645k, $12k (1.9%) over the final BAC and $50k under the $695k cost baseline. Management reserve untouched.
That's what a well-run project's cost story looks like. A problem appeared; the indices showed exactly where; approved changes moved money from contingency to the work; and from September onward every monthly EAC was within 1% of the final actual cost.
Why SPI lies at the end
Look at the SPI column: it finishes at 1.00. That isn't because Ledger finished on time. At completion EV equals BAC and PV equals BAC, so SPI is always 1.00 whether the project finished on time or six months late. In the last third of a project, money-based SPI stops meaning much.
Earned schedule fixes this by measuring schedule performance in time. At the end of August (seven months in), EV was $352k. PV had reached $240k at six months and $370k at seven. Interpolating, the earned schedule was 6 + (352 − 240) ÷ (370 − 240) = 6.86 months, or about three working days behind. The money-based SPI of 0.95 exaggerated the delay because August was the heaviest month of planned spend. Three days matched the critical-path analysis exactly. That's the deeper lesson: the critical path, not SPI, should drive schedule decisions.
Earned value on a fixed-price agile engagement
Harbor, a customer migration sold at a fixed price, used a simple AgileEVM at each iteration review to answer the delivery manager's real question: will we keep our margin? After its change order, Harbor's cost budget was $283.6k (2,430 hours). With 59.5% of the backlog weight done against 62.5% planned and $164.6k spent, CPI was 1.025 and SPI 0.95. The forecast cost of $276.7k against revenue of $516k put the margin near 46%, slightly above target.
The PM noted a trap. Had he used the textbook “iterations elapsed” as planned percent complete (6 of 11), SPI would have shown 1.09, apparently ahead, because the plan was deliberately back-loaded with large, simple migration waves. Planned percent complete should follow the plan's shape, not the calendar.
When not to use EVM
EVM needs a stable baseline, an objective way to measure completed work, and timely actual costs. It adds little for product teams funded by capacity (there is no project budget to earn against; flow and outcomes matter more), for ongoing operations (service levels are the measure), or for very small projects where the overhead outweighs the insight.
Try it
A project has BAC $200k. At month 4: PV $90k, EV $80k, AC $100k. Compute CV, SV, CPI, SPI, EAC (typical), ETC, VAC and TCPI. Answers: CV −$20k; SV −$10k; CPI 0.80; SPI 0.89; EAC $250k; ETC $150k; VAC −$50k; TCPI 1.20. The project would need to perform 50% better than it has to finish on budget. Report the forecast honestly and recommend a decision.
How students practice this
In week 13, students compute earned value by control account from a raw cost ledger in Python and SQL, forecast with all four EAC methods, compute earned schedule, and publish a CPI/SPI dashboard on Tableau Public. Then they write the monthly report an executive will actually read.
Adapted from Projects, For Real, chapters 20, 36 and 37. The projects, people, vendors and numbers are the book's fictional case studies, set against GitLab's publicly documented practices. Gantt Guild is not affiliated with GitLab Inc.
