Planned Value vs Earned Value vs Actual Cost

What is planned value (PV)?

planned value vs earned value vs actual cost is a key topic in modern project management and teamwork. Planned value is the authorised budget for the work that the schedule says should be complete by a specific date. It is the cumulative, time-phased version of the cost baseline, which is why its curve is an S rather than a straight line.

Two properties matter. First, PV is a property of the plan, not of reality — it does not change because the team is slow, and it should not change because an invoice arrived early. Second, PV is cumulative: at the end of the project, PV equals the budget at completion (BAC). Mid-project, PV is always a fraction of BAC, and that fraction is the schedule’s claim about where you should be.

Older documentation calls PV the Budgeted Cost of Work Scheduled (BCWS). Same number, different acronym, and PMP study material still uses both.

On a $600,000 project with a linear six-month spend curve, PV at the end of month 3 is $300,000. With a realistic curve — slow mobilisation, fast middle, slow close-out — the same project might have PV of $210,000 at month 3 and $470,000 at month 4.5. That difference is why an unphased budget makes early status reports useless.

What is earned value (EV)?

Earned value is the budgeted value of the work actually completed by the status date. It converts physical progress into money using planned rates, so that a delivered module and a delivered wall can be compared on one scale.

The definition has a trap in it. If a work package was budgeted at $40,000 and is finished, its EV is $40,000 — even if it cost $52,000 and even if it took twice as long. EV measures accomplishment against the budget, not effort and not spend.

Partial completion is where measurement quality lives or dies:

The 50/50 rule is popular because it is objective, and it has a known cost: EV can be overstated or understated by an average of about 25% of each work package’s baseline, depending on whether the work is nearer its start or its end. Aggregated across many packages the errors partly cancel, but nobody can say by how much.

What is actual cost (AC)?

Actual cost is the realised cost of the work performed up to the data date: labour, materials, subcontractors, equipment, and allocated overhead. It has no upper limit and no relationship to the budget.

The practical difficulty is timing rather than definition. Three versions of AC coexist in most organisations:

• Committed cost — purchase orders and contracts signed but not invoiced. Useful for forecasting, dangerous for EVM ratios.
• Incurred cost — work delivered and owed, whether or not an invoice exists.
• Invoiced or paid cost — what finance can see. Usually the latest and the least useful for performance measurement.

If you record AC on payment dates, a project can look efficient in the month a large invoice is delayed and catastrophic in the month it lands. Match cost to the period in which the work happened, and use accruals for the gap. Failing that, be explicit that AC is on an invoiced basis, and never compare it with a precisely measured EV without saying so.

How do the three numbers relate?

All three are expressed in the same currency, which is what makes the comparisons possible. But only PV and EV are measured at budgeted rates. AC is measured at real rates, and that single difference is the source of every cost insight EVM produces.

From those three, four numbers follow. Schedule variance (SV = EV − PV) tells you how far ahead or behind in money terms. Cost variance (CV = EV − AC) tells you the budget surplus or deficit for the work done. The schedule performance index (SPI = EV ÷ PV) and cost performance index (CPI = EV ÷ AC) turn the same differences into ratios so projects of different sizes can be compared.

Note the asymmetry in the definitions. EV can never exceed the budgeted value of the work in scope; AC can exceed anything. That is why a large negative CV is a stronger warning than a large negative SV of the same size.

Worked example: a six-month platform migration

A company is migrating 40 internal applications to new infrastructure. The approved budget is $600,000 over six months, and the baseline is phased evenly. At the end of month 3:

The arithmetic:

• SV = EV − PV = 270,000 − 300,000 = −$30,000. The project is behind, with $30,000 of scheduled value not yet earned.
• CV = EV − AC = 270,000 − 324,000 = −$54,000. Spending is $54,000 above the budgeted value of the work done.
• SPI = 270,000 ÷ 300,000 = 0.90. Work is being completed at 90% of the planned rate.
• CPI = 270,000 ÷ 324,000 = 0.83. Every dollar spent has bought 83 cents of budgeted value.
• EAC = BAC ÷ CPI = 600,000 ÷ 0.83 = $720,000. If current efficiency continues, the final cost is 20% above budget.
• VAC = BAC − EAC = −$120,000. A projected overrun.
• TCPI = (BAC − EV) ÷ (BAC − AC) = 330,000 ÷ 276,000 = 1.20. The remaining work must run 20% more efficiently than plan to finish within budget.

Read the shape of it: 45% of the value is earned, 54% of the budget is spent, and the two indexes point in the same unhappy direction. The interesting question is not whether the project is in trouble, but whether the cause is cost, schedule, or a measurement artefact.

Second example: when PV itself is wrong

A renovation project has a non-linear baseline. Demolition and structural work consume 55% of the budget in the first third of the schedule, so PV rises steeply and then flattens.

At the end of week 8, the project manager reports PV of $148,000, EV of $120,000, and AC of $131,000. CPI is 0.92 and SPI is 0.81, which reads as a moderately sick project.

Then someone notices the baseline was never re-phased after a two-week permit delay. The correct PV at week 8 is $112,000. Recalculated, SPI becomes 120,000 ÷ 112,000 = 1.07, and the project is ahead of a realistic plan while slightly over cost.

Nothing about the site changed. Only the plan did. This is the most common way a status report misleads: the EV and AC are defensible, and PV is a stale fiction.

Third example: the front-loading trap

A software project shows CPI of 0.61 in month 1 and 0.98 by month 4, with no change in behaviour. Month 1 included licence purchases for the full year, cloud setup, and three contractors’ onboarding fees — $180,000 of cost against $110,000 of earned value.

This is not a cost problem. It is a timing artefact, and reporting it as a trend teaches the sponsor to ignore the metric. Two fixes work: accrue annual licences across the period they serve, or state clearly that early CPI is not yet meaningful. EVM data becomes reasonably predictive only once a project is roughly 25% complete, which for this project means month 2 at the earliest.

Which of the three numbers is usually wrong?

EV is the most frequently distorted, AC is the most frequently late, and PV is the most frequently stale. Knowing which one to audit first saves an argument.

The last row is worth a rule: if more than a fifth of your in-progress packages report the same round percentage, the measurement method is the problem, not the project.

Why do teams abandon EVM, and when should they not use it?

EVM has a real overhead, and the criticism is not unfair. In a PMI survey of practitioners, 52% of those who had used EVM in the previous five years estimated its overhead at more than 5% of total project cost, and 33% put it above 10%. Sixty-three percent agreed with the statement that EVM is practical only for large projects.

The listed reasons for skipping it were consistent: projects too small (29%), no access to a good solution (29%), too expensive in time or money (13%), and too complicated (13%).

That does not mean small projects should skip the concepts. It means they should apply them proportionally:

• Use PV, EV, and AC at phase or milestone level rather than at work-package level.
• Report monthly, or per milestone, rather than weekly.
• Skip the full forecast suite and track CPI, SPI, and one EAC method.
• Keep the baseline in the same system as the tasks, so measuring EV does not become a reconciliation project.

The other honest limitation is that EVM measures cost and schedule only. It says nothing about quality, stakeholder satisfaction, or risk exposure. A project can post a beautiful CPI while shipping something nobody wants, and a negative CV is not proof that the deliverable is bad.

How do you keep the three numbers clean on a small team?

You need one owner, one cut-off date, and one place where budget, progress, and cost live together. Everything else is detail.

The usual failure is tooling fragmentation: budget in finance, schedule in a Gantt chart, time in a separate tracker, and progress in a stand-up. The monthly report becomes a manual reconciliation, and the reconciliation is where the errors enter.

Doitify is our product, so treat this as a description rather than a review: tasks, sub-tasks, owners, and progress sit in the same workspace as reports, which shortens the path from “what is done” to “what it earned”. It is not an EVM engine and does not claim to replace one on a capital project. For a team of 20 that needs a monthly CPI it can defend, having PV, EV, and AC sourced from one system removes most of the argument.

Three habits do the rest:

1. Fix the cut-off. State the data date on every report and refuse to mix a mid-month EV with an end-of-month invoice run.
2. Write one line of cause. “CPI 0.83 because two contractors started early and the billing module needed 180 hours of rework.” That sentence is worth more than the spreadsheet.
3. Check one level down. Look at the three largest variance contributors before believing the project total.

Common mistakes to avoid

• Treating spend as progress. If EV equals AC by definition, CPI is always 1.00 and the metric is decorative.
• Leaving the baseline unphased. A flat PV line produces meaningless SPI in the first and last thirds of a project.
• Mixing scope. EV for one release compared with AC for two produces a ratio that means nothing.
• Using committed cost as AC. Purchase orders are not costs incurred.
• Reporting to two decimal places without the data date. Precision implies accuracy you may not have.
• Re-baselining to improve the number. Legitimate after an approved scope change; dishonest otherwise.

Conclusion

Planned value, earned value, and actual cost are three simple measurements that become powerful only when kept separate and compared deliberately. PV tells you where the plan says you should be. EV tells you what you have actually achieved, valued at planned rates. AC tells you what it cost to get there.

Get those three right on the same date and scope, and every useful metric — variance, index, forecast — falls out of them. Get them wrong, and no amount of decimal places will save the report. Start with the data date, then the baseline, then the progress rule. In that order, the arithmetic takes care of itself.

If this post on planned value vs earned value vs actual cost was helpful, you might also enjoy Project Management Software for Event Planning: 2026 Guide and Best Project Management Software for Remote Teams in 2026.