← Back to blog

EVM in modern portfolio management: practical guide

IntelliPPM6 min read

EVM done honestly in a modern PPM platform — what BAC, PV, EV, AC really mean, the most common ways implementations get the math wrong, and how variance decomposition turns EVM from theatre into a working executive surface.

Why EVM still matters

Earned Value Management has been declared dead at least once a decade since the 1960s. It is not dead. The reason is structural: EVM is the only widely-understood framework that connects three things at once — the baseline you committed to, the work you have actually completed, and the money you have actually spent — into a single set of numbers that an executive can read in under a minute.

The problem is not the framework. The problem is that most implementations get the math wrong in ways that look correct in a demo and quietly stop being useful at scale.

This post is the practical guide we would give a portfolio leader who wants to know whether their EVM dashboard is telling them the truth.

The four numbers

EVM rests on four numbers. Get these right and the rest follows.

  • BAC — Budget at Completion. The total approved cost of the

baseline scope. This is the sum of the baseline lines, full stop. If BAC drifts because the baseline drifted, you have lost the baseline; what you have is a forecast.

  • PV — Planned Value. The cost of the baseline scope that was

expected to be completed by period_end. This is not a straight-line proration of BAC across the project duration. It is the sum of the baseline costs of the work the baseline schedule said would be done by now.

  • EV — Earned Value. The cost of the baseline scope that

actually has been completed by period_end. This is not equal to AC. EV is a measurement of progress, valued at baseline cost.

  • AC — Actual Cost. The cost actually posted to the ledger

through period_end. This includes labour, vendor invoices, PO receipts, accruals, and any AI-suggested adjustments that have been approved.

From these four you derive everything else: CV (Cost Variance, EV − AC), SV (Schedule Variance, EV − PV), CPI (Cost Performance Index, EV / AC), SPI (Schedule Performance Index, EV / PV), and the forecasting math (EAC, ETC).

The four most common mistakes

Mistake 1 — EV pegged to AC

The single most common implementation error: the platform computes Earned Value as whatever has been spent. CV is therefore always zero. SV is meaningless because the proration of PV is similarly naive. The dashboard is green. The project is on fire.

The cause is almost always laziness in the percent-complete calculation. When the platform does not have a credible percent-complete signal — work item statuses, milestone weights, or a manual entry from the project manager — it falls back to AC. The result looks like EVM and is not.

The fix is to treat percent-complete as a first-class data input, not a derivation of spending. IntelliPPM does this by deriving percent-complete from the canonical work-item event stream — work items in done status contribute their baseline weight; work items in progress contribute partial weight by configurable rule.

Mistake 2 — PV straight-lined

The second most common error: PV is computed as BAC × (days_elapsed / total_days). This gives you a clean line on the dashboard. It also disconnects PV from the baseline schedule.

If the baseline said the expensive integration phase happens in Q4, PV should reflect that — Q1 PV should be low, Q4 PV should be high. A straight-line PV puts the same expected spending in Q1 as in Q4, which means SV cannot do its job.

The fix is to compute PV from the baseline schedule's cost-loading, period by period, against the actual period_end. IntelliPPM does this from the baseline events at the WBS-node level.

Mistake 3 — In-place ledger updates

The third error is structural. When the ledger allows in-place updates, EVM stops being reproducible. Last quarter's CV cannot be recomputed because last quarter's AC has been overwritten. Audit reconstruction is impossible. AI-originated adjustments are indistinguishable from human-originated ones.

The fix is append-only. Corrections are reversal postings plus new postings, linked. The original posting and the correction are both first-class facts in the event log. EVM at any historical period_end is reproducible by replaying the ledger to that point.

Mistake 4 — No variance decomposition

The fourth error is presentational. The dashboard shows a CV. It does not say why. The portfolio leader is left to investigate.

A working EVM implementation decomposes variance along the posting dimensions:

  • Rate variance — we paid more per hour than baseline assumed.
  • Volume variance — we needed more hours than baseline assumed.
  • Mix variance — we used a more expensive role mix than baseline

assumed.

  • FX variance — currencies moved between baseline and posting.
  • Scope-change variance — the underlying scope changed.

The decomposition makes the conversation actionable. "CV is −$230K" is a number. "CV is −$230K, of which $180K is rate variance driven by contractor day-rate movement in Q2" is a decision.

Forecasting, briefly

Once EVM is honest, forecasting becomes tractable. The three common methods all start from honest EVM:

  • Naive — EAC = AC + (BAC − EV). Assumes remaining work runs at

baseline cost. Cheap; useful only when CPI is near 1.

  • CPI-based — EAC = BAC / CPI. Assumes remaining work runs at

current cost performance. The default when the project has stable performance trends.

  • Weighted — incorporates SPI alongside CPI. Useful when schedule

is slipping and that slip will compound costs.

A modern PPM platform should also offer an AI-blended forecast that produces P10/P50/P90 ranges with drivers and confidence. The honest variant of this surfaces the drivers (rate, volume, mix, FX, scope-change) and lets the human accept, modify, or reject — never auto-applies for budget impact above a threshold.

What EVM is not

EVM is not a substitute for risk management, scope-change management, or stakeholder alignment. It will tell you that something is going wrong. It will not tell you what to do about it. The decomposition will tell you why; the response is still a human decision.

EVM is also not a real-time signal for week-to-week decisions on small projects. Its overhead pays back at portfolio scale and on projects with multi-quarter baselines. For a two-week sprint, the overhead is not worth it.

The summary

EVM done well is one of the highest-leverage executive surfaces in a PPM platform. EVM done poorly is one of the most dangerous — it generates confidence without accuracy. The difference between the two is a small list of structural decisions: percent-complete as first-class input, PV from the baseline schedule, append-only ledger, and variance decomposition.

When all four are right, EVM tells the truth.

Talk to founder

If you are deciding whether your current PPM tool's EVM implementation is honest, the contact form on the pricing page reaches the founder directly.