Earned value (EVM) by example: CPI, SPI and EAC

You’re halfway through the project and the report says 55% of the budget has been spent. Is that good news or bad news? It depends on how much work is actually done, and that figure isn’t in the report. Comparing what you spent with what you budgeted doesn’t tell you whether you’re behind schedule, overspending or both at once.

Earned value (EVM, Earned Value Management) solves that with three numbers and a handful of formulas. You can run it in a spreadsheet; the hard part isn’t the math, it’s measuring progress honestly.

The three base numbers

Acronym	Name	What it answers
PV	Planned value	How much work, in Bs, should be done by this date according to the baseline?
EV	Earned value	How much work, in budgeted Bs, is actually done?
AC	Actual cost	How much was actually spent to do that work?

And one more: BAC (budget at completion), the total approved budget.

The key is EV: it isn’t what you spent, it’s the budget of the work that’s finished. If a Bs 100,000 work package is 40% complete, its EV is Bs 40,000, no matter what it cost to get there.

The formulas

Variances (in Bs):

• Cost variance: CV = EV − AC (negative = overrun)
• Schedule variance: SV = EV − PV (negative = behind)

Indices (dimensionless):

• Cost performance index: CPI = EV / AC
• Schedule performance index: SPI = EV / PV

Forecasts:

• Estimate at completion: EAC = BAC / CPI (if current cost performance continues)
• Estimate to complete: ETC = EAC − AC
• Variance at completion: VAC = BAC − EAC
• To-complete performance index: TCPI = (BAC − EV) / (BAC − AC)

Example: a project halfway through

Suppose a 10-month project with a budget (BAC) of Bs 400,000, split into four deliverables. At the end of month 5, this is where things stand:

Deliverable	Budget	PV month 5	% complete	EV	AC
Design	60,000	60,000	100%	60,000	70,000
Civil works	200,000	100,000	40%	80,000	100,000
Installations	100,000	40,000	40%	40,000	50,000
Equipment	40,000	0	0%	0	0
Total	400,000	200,000		180,000	220,000

From that:

1. CV = 180,000 − 220,000 = −Bs 40,000. You spent 40,000 more than what you did is worth.
2. SV = 180,000 − 200,000 = −Bs 20,000. You did 20,000 less work than planned.
3. CPI = 180,000 / 220,000 = 0.82. For every boliviano spent, you get 82 cents of work.
4. SPI = 180,000 / 200,000 = 0.90. You’re progressing at 90% of the planned pace.
5. EAC = 400,000 / 0.818 ≈ Bs 488,900. If nothing changes, that’s what the project will cost.
6. ETC = 488,900 − 220,000 ≈ Bs 268,900. What’s left to spend.
7. VAC = 400,000 − 488,900 ≈ −Bs 88,900. The expected overrun at the end.
8. TCPI = (400,000 − 180,000) / (400,000 − 220,000) = 220,000 / 180,000 = 1.22. To finish within the original budget, the remaining work would have to perform 22% better than planned.

Go back to the opening report: 55% of the budget has been spent (220,000 / 400,000), but only 45% of the work is done (180,000 / 400,000). That gap is the problem, and only EV shows it.

How to read the indices

Index	Greater than 1	Equal to 1	Less than 1
CPI	Spending less than planned	On budget	Overrun
SPI	Ahead	On schedule	Behind

Some guidelines for interpreting them:

• Look at the trend, not a single month. A CPI that goes from 0.95 to 0.90 to 0.82 in three months is an alarm, even if each month “doesn’t seem like much”.
• Find where the deviation is. In the example, every work package has a CPI between 0.80 and 0.86: the overrun is across the board, not in one deliverable. That points to rates, productivity or scope that were poorly estimated.
• EAC has more than one version. BAC / CPI assumes performance stays the same. If the deviation was a one-off (a surprise that won’t repeat), use EAC = AC + (BAC − EV) = 220,000 + 220,000 = Bs 440,000. If both cost and schedule are under pressure, EAC = AC + (BAC − EV) / (CPI × SPI) ≈ Bs 518,800. Presenting the range (440,000 to 518,800) is more honest than a single number.
• SPI doesn’t replace the critical path. An SPI of 0.90 says you’re behind on average, but not whether the delay is on tasks that move the end date. For that you need the critical path. Also, SPI tends toward 1 at the end of any project (because at completion EV = PV = BAC), so in the last third it loses usefulness.

The baseline: no baseline, no EVM

PV comes from the baseline: the approved, frozen schedule and budget. If the baseline moves every time something slips, SPI always comes out at 1 and the method is useless.

1. Approve the baseline before execution (scope, schedule and budget by deliverable).
2. Spread the budget over time; that cumulative curve is the PV S-curve.
3. Change the baseline only with an approved scope change, documented, and keep the previous version.
4. Measure on fixed dates (end of week or month), always the same way.

How to measure progress without making it up

EV is only as good as the % complete. Common rules:

• 0/100: the task is worth 0 until it’s finished. Good for short tasks.
• 50/50: 50% when it starts, 50% when it finishes. For tasks spanning two or three periods.
• Weighted milestones: each verifiable milestone is worth a fixed percentage.
• Physical units: meters, pieces, approved drawings over the total.

Avoid the owner’s “eyeballed %”: it tends to sit at 90% for weeks.

Common mistakes

• Using % spent as % complete. Then EV = AC and CPI always equals 1.
• Incomplete AC. If hours or supplier invoices are recorded weeks late, CPI looks better than it is. Actual cost must land in the same period as the work.
• Comparing AC directly with PV. That mixes cost and schedule; always go through EV.
• Re-baselining every month.
• Different tax criteria between budget and actual cost (with and without VAT, for example). Use the same criterion across the whole project and agree on it with accounting.
• Reporting only indices. A steering committee understands “Bs 268,900 still to spend and we’d finish at Bs 488,900” better than “CPI 0.82”.

Taking it to a system

With one project and a well-built spreadsheet, EVM works. With several projects and a team logging hours, a system like MKA can freeze the baseline and recalculate CPI and SPI, with their S-curve, from hours logged per task and actual progress (see projects).