Earned Value Analysis

Cost technique · See it on the map

Runnable here

Comparing planned, completed, and spent work at one point in time to judge cost and schedule performance.

When to use it

Any time you have a baselined cost and schedule and need a defensible answer to 'are we in trouble' that isn't just a gut feeling. It earns its keep most on projects long enough, and with enough spend, that a manager can't just eyeball progress against the budget.

When to avoid it

Don't run it against a baseline nobody actually approved, or against progress percentages nobody actually measured — a fabricated percent complete produces a CPI that looks precise and means nothing. And a single EAC formula (see below) is the wrong call on a project whose cost performance is actively recovering or deteriorating, not holding steady.

Steps

1. Establish BAC: the approved, aggregated cost baseline.
2. For the as-of date, get PV — how much of the baseline should have accrued by now — from the baseline's planned windows.
3. Get EV — percent complete per task, times that task's planned cost, summed — from the latest progress reports at or before the as-of date.
4. Get AC — the money actually incurred at or before the as-of date.
5. Compute CPI = EV / AC and SPI = EV / PV. Both are undefined (not zero) before there is spend or planned accrual to divide by.
6. Read CPI and SPI together before reaching for a single-number verdict: a CPI below 1.0 means less value earned per dollar spent than planned; an SPI below 1.0 means less value earned per dollar of baseline that should have accrued by now.
7. If you need a forecast, compute EAC from CPI and treat it as one scenario, not a fact — see the caveat below.

What it produces

• A single as-of snapshot: BAC, PV, EV, AC, CPI, SPI, EAC, ETC, VAC.
• A cost-performance read (via CPI) and a schedule-performance read (via SPI) that can be tracked over successive as-of dates to see a trend, not just a point.

Common pitfalls

• Reading SPI as literal schedule days late or early — it's a value ratio, not a calendar figure, and can mislead badly near a project's end when there's little baseline left to under- or over-run.
• Treating a CPI of exactly 1.0 as 'fine' without checking whether it's an average masking a task that's badly over cost offset by one that's badly under-scoped.
• This product computes EAC one way — ``BAC / CPI`` — which assumes the cost performance seen so far will continue for the rest of the project. That's the assumption most likely to be wrong on a project recovering from a bad patch or sliding into one; read the resulting EAC as 'if nothing changes', not as the number you'll actually land on.
• Chasing CPI back to exactly 1.0 by re-baselining away real overruns instead of reporting them — a CPI that only ever improves because the baseline keeps moving isn't performance, it's bookkeeping.

Worked example

A community-center renovation has a BAC of $850,000. At the six-month as-of date, the baseline says $410,000 should have accrued (PV). Progress reports put earned value (EV) at $348,500, against $410,000 actually spent (AC) so far. CPI = 348,500 / 410,000 = 0.85 — the project is getting 85 cents of planned work for every dollar spent. SPI = 348,500 / 410,000 = 0.85 too, coincidentally the same figure here, meaning progress is also running behind the baseline's pace. The resulting EAC (BAC / CPI = 850,000 / 0.85 ≈ $1,000,000) says the job will cost roughly $150,000 more than planned if the last six months' cost performance holds — the project manager reports that as a conditional forecast, not a promise, and starts investigating which trade's overruns are driving the 0.85.

Source

• PMBOK-6 §7.4.2.2

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.