Earned Value Management: Measure What You Have Delivered, Not What You Have Spent

Most projects fail quietly. The schedule says green, the status report says on track, and then the final quarter arrives and everything is suddenly late and over budget. Earned Value Management – EVM – exists to make that kind of surprise impossible. It is not a forecasting method or a reporting format. It is a discipline: a precise way of measuring what you have actually delivered against what you planned to deliver, at every point in a project's life.

What Is Earned Value Management?

EVM is a project management technique that integrates three things that are usually tracked separately: scope, schedule, and cost. Developed by the US Department of Defense in the 1960s and formalised in ANSI/EIA-748, it has since become the gold standard for objective project health monitoring across industries – from construction and defence to software delivery and infrastructure.

The central idea is straightforward. Instead of asking “how much have we spent?” or “how many weeks have passed?”, EVM asks: how much value have we actually earned for the work completed? The gap between what you planned to earn and what you actually earned – expressed in budget terms – is the only honest measure of project health.

The Three Core Metrics

Everything in EVM flows from three numbers. Get these right and every other indicator follows automatically.

The EVM S-curve: PV shows the planned trajectory, EV shows what has been earned, and AC shows what was spent. The gaps between these three lines tell the entire project health story at a glance.

Performance Indicators and Forecasting

With PV, EV, and AC in hand, every important project health indicator is a simple calculation. The variances tell you where you are; the indices tell you how efficiently you are travelling; the forecasts tell you where you will end up if current performance continues.

How EVM Helps Your Project

EVM gives project managers and stakeholders capabilities they cannot get from a simple status update or a Gantt chart alone. The three benefits below are the ones that matter most in practice.

How to Use EVM in Traditional Project Management: A Step-by-Step Guide

EVM is most naturally applied to traditional, plan-driven projects with a defined scope, schedule, and budget. The seven steps below describe how to set it up from scratch and run it through the project lifecycle.

Step 1: Define Scope and Create a Work Breakdown Structure (WBS)

EVM begins with scope. You cannot measure what you have earned if you have not defined what there is to earn. Create a WBS that breaks the project into deliverable-oriented work packages – discrete pieces of work that can be independently planned, budgeted, and tracked. Each work package becomes a unit of measurement in your EVM system.

Step 2: Assign a Budget to Each Work Package (Set Your BAC)

Assign a cost or hour value to each work package. This is the Budget at Completion (BAC) for that package. The sum of all work package budgets is the project BAC – the total authorised budget. Every piece of earned value will later be calculated as a percentage of a work package's BAC, so accuracy at this step directly determines the quality of your EVM output.

Step 3: Create a Time-Phased Baseline (Your PV Curve)

Spread each work package's budget across the calendar according to your project schedule. The cumulative result, plotted over time, is the PV S-curve – your Performance Measurement Baseline (PMB). This is the most important planning artefact in an EVM system because it defines what “on track” looks like at every date in the project. Set this baseline formally and do not adjust it without a documented scope change.

Step 4: Measure Earned Value at Each Reporting Period

At each reporting date, determine what percentage of each work package has been completed. Multiply that percentage by the work package BAC to get the Earned Value for that package. Sum across all packages to get the project-level EV. There are several recognised methods for measuring the completion percentage:

Step 5: Record Actual Costs

Capture all costs incurred for work performed to date – labour, materials, subcontracts, and overheads – mapped to the work packages in your WBS. Your financial system is the source of truth. The quality of your EVM output is directly tied to the accuracy and timeliness of cost recording; stale or incomplete actuals produce misleading indicators.

Step 6: Calculate Variances, Indices, and Forecasts

With PV, EV, and AC established, all the indicators from the table above follow directly. Microsoft Project and Primavera P6 both calculate these automatically once progress data is entered and a baseline has been set. The discipline is to calculate them consistently at every reporting period and to document any management decisions that deviate from the EAC formula – for example, if a recovery plan is implemented, the EAC should reflect it explicitly.

Step 7: Report, Review, and Act

EVM data is only valuable if it drives decisions. Establish a regular cadence – weekly for active delivery phases, monthly for planning phases – at which you review the indicators with the team and sponsors. A CPI below 0.9 should trigger a formal recovery plan. An SPI trending downward for three consecutive reporting periods should trigger a schedule review. The numbers are not the destination; the management response to them is.

EVM in Microsoft Project: with the baseline set and progress entered, MS Project calculates BCWP (EV), BCWS (PV), SV, CV, SPI, and CPI automatically for each work package and at the project summary level.

A Worked Example

Consider a software development project with a total BAC of $200,000 and a planned duration of 10 months. At the end of month 5 the following data has been captured from the schedule and financial system:

Without EVM, a project manager might report “we are halfway through the project and halfway through the budget” – which sounds acceptable. With EVM the picture is clear: the project is behind schedule, over budget, and trending toward a 19% cost overrun. That is information a sponsor can act on in month 5. Without EVM it surfaces as a shock in month 9.

EVM in Agile: Bridging the Gap

EVM was designed for fixed-scope, plan-driven projects. Agile projects work differently: scope evolves, iteration-level planning is preferred over detailed upfront planning, and the definition of “done” shifts sprint by sprint. The two approaches appear to be in direct conflict – and in a naive implementation, they are.

But the underlying principle of EVM – measuring the value earned against the value planned – is entirely compatible with agile delivery. The difference is in how you define and measure the units. In a traditional project the unit is a work package in a WBS. In an agile project the unit can be a User Story, an Epic, or a Program Increment. The mathematics is identical; the inputs are different.

The key adaptation is this: instead of defining a detailed work breakdown at the start and measuring physical completion against it, agile EVM sets a planned scope for a time-box – a Sprint or a Program Increment – and measures how much of that scope was actually delivered by the end of the time-box. Delivered User Stories represent earned value. Planned but undelivered stories remain as unearned value. The S-curve still holds; only the granularity of the work packages has changed.

Epics in the Jira Product Owner backlog with percentage complete visible. Each Epic maps directly to a summary task row in Microsoft Project, giving programme leadership a clean 1,000-foot EVM view driven by real Jira delivery data.

EVM with Jira: The Program Increment Approach

The approach described here bridges the Scaled Agile Framework (SAFe) concept of a Program Increment (PI) with traditional EVM reporting in Microsoft Project – giving leadership a 1,000-foot view without disrupting how delivery teams work in Jira Scrum.

Layer 1: Define the Program Increment as Epics in Jira

At the start of each PI planning cycle – typically covering the next three months – the Product Owner or Release Train Engineer defines the high-level deliverables as Epics in Jira. Each Epic represents a meaningful, shippable outcome for the increment: a feature set, a capability, a platform uplift. These Epics are the agile equivalent of work packages in a traditional WBS. They define what “100% complete” looks like for each major commitment in the increment.

Layer 2: Load the Epic Names into Microsoft Project

Only the Epic names – not the full Jira hierarchy of User Stories and tasks – are entered into Microsoft Project as summary tasks. Each Epic becomes a single row in the MS Project schedule, with start and end dates aligned to the PI window. A budget value (hours or cost) is assigned to each Epic based on the team's capacity planning for that increment. This value becomes the BAC for that Epic's work package. The cumulative time-phased budget across all Epics forms the performance measurement baseline for the PI.

Layer 3: Teams Work in Jira Scrum and Add User Stories

Delivery teams operate entirely within Jira. As sprints progress they create and complete User Stories under each Epic. Jira's built-in Epic progress tracking automatically calculates the percentage of story points (or issue count) completed against the Epic – this figure appears in the Product Owner backlog view and on the Epic's own detail page. Teams do not need to know anything about EVM; they simply plan, build, and close stories. The percentage complete is an automatic by-product of their normal Jira workflow.

Layer 4: Transfer the Jira Percentage Complete to Microsoft Project

At a regular cadence – weekly or at each Sprint Review – the Epic completion percentage from Jira is recorded against the corresponding summary task in Microsoft Project. MS Project uses this percentage to calculate the Earned Value (BCWP) for each Epic automatically, once the EVM fields are enabled in the project view. The Planned Value (BCWS) is derived from the time-phased baseline set at PI kickoff. No manual estimation is required beyond reading the number out of the Jira backlog.

Layer 5: The 1,000-Foot View in Microsoft Project

With PV and EV calculated for each Epic, the project-level SPI, CPI, EAC, and VAC roll up automatically in Microsoft Project. Leadership sees a single schedule with one row per Epic – clean, uncluttered, and directly connected to real delivery data from Jira. The percentage complete driving the EVM numbers is the actual story delivery rate from the Jira backlog, not a manager's estimate. That is the critical distinction: the data flows from the team's work, not from someone's interpretation of it.

What the 1,000-Foot View Tells Programme Leadership

The power of this approach is that it gives programme-level visibility without requiring leadership to navigate Jira. At any point in the PI, a sponsor or programme manager can open MS Project and immediately answer the questions that matter most.