The Six Earned Value Techniques
Earned value — BCWP, or Budgeted Cost of Work Performed — is only as reliable as the technique used to measure it. The technique determines how and when budget is “earned.” A poor technique choice creates noise in the data that cascades through CPI, SPI, variance analysis, and the EAC. Choosing correctly at the work package level is one of the CAM’s most impactful decisions.
| Technique | How EV Is Earned | Objectivity | Ideal Duration |
|---|---|---|---|
| 0/100 | No EV until complete. 100% of budget earned upon completion. | High — binary | ≤1 reporting period |
| 50/50 | 50% of budget earned when work starts; remaining 50% earned at completion. | High — binary at two points | ≤2 reporting periods |
| Milestone Weighted | Pre-defined milestones earn pre-assigned budget values upon completion. | High — if milestones are tangible | Any duration |
| Percent Complete | CAM estimates percent of work completed each period. Budget earned proportionally. | Low — subjective | Any duration |
| Units Complete | Budget earned per unit completed, based on a fixed budget-per-unit rate. | High — countable | Any duration |
| Level of Effort (LOE) | EV automatically equals PV each period. No schedule variance possible. | N/A — no measurement | Any duration |
Worked Examples
Abstract descriptions are not enough. Here are concrete examples showing how each technique works in practice.
Example 1: 0/100 — Deliver a Test Procedure
Work package budget: $5,000. Duration: 3 weeks within one reporting period. The deliverable is a completed test procedure document. No EV is earned until the document is delivered and accepted. In the period the document is completed, $5,000 of BCWP is earned. If the work slips to the next period, $0 is earned in the planned period, creating an immediate and visible schedule variance of –$5,000.
Example 2: Milestone Weighted — Software Module Development
Work package budget: $50,000 over 4 months. Five milestones are defined:
| Milestone | Weight | Budget Value | Verification |
|---|---|---|---|
| Requirements baselined | 10% | $5,000 | Approved requirements document |
| Design review complete | 20% | $10,000 | Signed design review minutes |
| Code complete | 30% | $15,000 | Code committed and peer reviewed |
| Unit testing complete | 25% | $12,500 | All unit tests passing |
| Integration verified | 15% | $7,500 | Integration test report signed |
At the end of month 2, if requirements are baselined and design review is complete, BCWP = $5,000 + $10,000 = $15,000. There is no partial credit for “almost finishing” a milestone. This is the power of milestone weighting: it eliminates partial-credit subjectivity.
Example 3: Units Complete — Harness Assembly
Work package budget: $120,000 for 60 harness assemblies. Budget per unit: $2,000. In month 1, 12 assemblies are completed. BCWP = 12 × $2,000 = $24,000. If BCWS for month 1 was $30,000 (15 planned units), the schedule variance is –$6,000. This technique is perfectly objective — you count completed units.
Example 4: Level of Effort — Program Management Support
Work package budget: $10,000/month for 12 months. Each month, BCWP = BCWS = $10,000 regardless of what happens. The schedule variance is always zero. The cost variance is driven entirely by actual costs. If the PM support team actually costs $12,000 in a month, CV = $10,000 – $12,000 = –$2,000. LOE detects cost problems but is blind to schedule problems.
The 90% Complete Trap
The percent complete technique is the most dangerous in the CAM’s toolkit. It is also the most commonly used, because it seems flexible and easy. The trap works like this:
Month 1–3: Steady Progress
The CAM reports 20%, 40%, 65% complete. The work is progressing and the numbers feel right. Cost and schedule variances look reasonable. No one questions the data.
Month 4: The 90% Plateau
The CAM reports 90% complete. Most of the “work” is done — the design is finished, the code is written, the hardware is built. But integration, testing, debugging, and rework remain. The CAM feels 90% is honest because 90% of the tasks are checked off.
Month 5–8: Stuck at 90–95%
The remaining “10%” takes four more months and costs as much as the first 90%. Each month the CAM inches up: 92%, 94%, 95%. Actuals are piling up but BCWP barely moves. The cost variance explodes. By the time the work completes, the WP is 40% over budget — but the problem was invisible until month 5.
💡 How to Avoid the Trap
Three defenses against the 90% trap: (1) Use milestone weighted instead of percent complete whenever possible. (2) If you must use percent complete, define objective criteria for each 10% or 25% increment in advance and write them down. (3) Apply the “weighted milestone overlay” — define 3–5 milestones within the work package that constrain the percent complete claim. If the milestone is not achieved, the percent complete cannot exceed the milestone’s ceiling regardless of the CAM’s subjective assessment.
Technique Selection Decision Framework
Use this decision framework when assigning EV techniques to work packages. Start at the top and take the first technique that applies.
| Question | If Yes | If No |
|---|---|---|
| Is the work package ≤1 reporting period? | Use 0/100 | Continue ↓ |
| Is the work package ≤2 reporting periods with one deliverable? | Use 50/50 | Continue ↓ |
| Is the work repetitive with identical countable outputs? | Use Units Complete | Continue ↓ |
| Can you define 3+ objectively verifiable milestones? | Use Milestone Weighted | Continue ↓ |
| Is there measurable output but no milestones? | Use Percent Complete (with constraints) | Continue ↓ |
| Is the work truly support with no measurable deliverable? | Use LOE | Reconsider scope definition |
LOE: Necessary but Dangerous
Level of effort is the only technique where schedule variance is always zero by definition. This makes it the easiest technique for the CAM — and the most dangerous for the program. LOE hides schedule problems. A control account with 50% LOE will show a blended SPI much closer to 1.0 than its discrete work alone would show, masking delays in the real work.
| LOE Percentage | Impact on CA Metrics | Action |
|---|---|---|
| 0–10% | Minimal impact on SPI. Discrete work drives performance metrics. | Acceptable for most control accounts. |
| 10–20% | Moderate dilution of SPI. Discrete schedule issues partially masked. | Review each LOE WP. Can any be converted to discrete? |
| 20–40% | Significant SPI distortion. Hard to distinguish real progress from LOE effect. | Separate LOE and discrete metrics in reporting. Challenge LOE scope. |
| 40%+ | SPI is unreliable. Schedule problems invisible in blended data. | Restructure the control account. Most LOE at this level should be discrete. |
🎯 The Bottom Line
Earned value is only as good as the technique used to measure it. Always choose the most objective technique the work allows. Guard against the 90% complete trap by using milestones instead of subjective percent complete. Minimize LOE to preserve the integrity of your schedule performance data. The technique you choose at planning time determines the quality of every metric you will report for the life of that work package. Next: Variance Analysis — how to analyze and explain the performance data these techniques produce.
Stop reading, start modeling
Model your process flow, run simulations, optimize staffing with TOC math, and test your knowledge with 107 interactive checks — all in one platform.