10.3 Measuring Progress, Earned Value & Sustainability Performance Reporting
Key Takeaways
- In PRINCE2 7, progress is measured strictly by completed, quality-verified products rather than elapsed hours, expended funds, or subjective 'percent complete' estimates.
- Earned Value Management (EVM) provides objective, mathematical performance indicators (CPI, SPI, EAC) that integrate cost, schedule, and delivered scope to provide predictive feed-forward forecasting.
- In agile and hybrid delivery environments, progress is tracked visually using burn-down charts, burn-up charts, cumulative flow diagrams, velocity, and WIP limits, which map directly into PRINCE2 Checkpoint and Highlight Reports.
- PRINCE2 7 mandates Sustainability Performance Reporting as a standard governance discipline, requiring quantitative tracking of carbon emissions, energy efficiency, circular materials, and waste diversion against baseline targets and tolerances.
- Operational progress is captured continuously inside the project log: the daily log holds informal actions, the lessons log holds empirical insights, the quality register records each quality activity as pass or fail, and the product register carries each product's status and current version.
Measuring Progress, Earned Value & Sustainability Performance Reporting in PRINCE2 7
Practitioner Core Mandate: Accurate progress tracking is the bedrock of project control. If progress reporting is based on subjective opinions, self-reported 'percent complete' guesses, or raw financial expenditures, project governance collapses into illusion. PRINCE2 7 enforces an objective, multi-dimensional measurement regime: progress is verified through quality-approved products, quantified using Earned Value Management (EVM), visualized via agile flow metrics, and audited against binding sustainability baselines. Practitioners must know how to calculate and interpret predictive metrics, track environmental run-rates, and maintain the definitive management logs that underpin auditability.
1. Progress Measurement Techniques: Products vs. Activities
The fundamental premise of the PRINCE2 Progress practice is: focus on products, not activities.
The "Percent Complete" Fallacy
In traditional, un-governed project environments, managers frequently ask team members: 'What percentage complete is your task?' This practice introduces fatal governance distortions known as the 90% Syndrome:
- The 90% Syndrome: A software developer or civil engineer reports that a deliverable is '90% complete' after two weeks of effort. The deliverable then remains stuck at '90% complete' for the next two months because the final 10% involves complex debugging, edge-case testing, interface integration, and documentation.
- Subjectivity and Optimism Bias: Self-reported percentages reflect human optimism rather than verified physical output.
- No Quality Linkage: A product that is 95% constructed but fails its core safety or performance criteria is functionally 0% complete—it cannot be used, handed over, or monetized.
THE DECEPTIVE "PERCENT COMPLETE" TRAP
PROGRESS (%)
100% ├─────────────────────────────────────────────── (Never quite finishes!)
90% ├───────────►════════════════════════════════════ (Stuck for months)
│ ▲
50% │ / Rapid initial progress
│ / based on subjective optimism
0% └───────┴───────────────────────────────────────► TIME
PRINCE2's Objective Progress Principles
To eliminate the percent-complete trap, PRINCE2 enforces three objective measurement rules:
- Binary Completion (0 / 100 Rule): A product is either complete (100%) or incomplete (0%). A deliverable cannot be recorded as completed in progress reports until it has been formally reviewed, tested, and signed off as meeting its quality specifications in the Quality Register.
- Granular Work Packages: If a deliverable is large and multi-faceted, it must be decomposed into smaller constituent products (using the Product Breakdown Structure), each with its own Product Description and discrete quality sign-off gate.
- Milestone Slip Charts: Project Managers track key deliverable milestone dates over successive reporting cycles. If forecast milestone dates drift consistently to the right across successive Highlight Reports, systemic delivery slippage is occurring, regardless of how optimistic team reports appear.
2. Earned Value Management (EVM) in PRINCE2
To bridge the gap between financial accounting (how much money was spent) and schedule tracking (how much calendar time elapsed), PRINCE2 utilizes Earned Value Management (EVM).
EVM is an objective project performance measurement technique that integrates scope, schedule, and cost baselines. It prevents the common illusion where a project appears 'under budget' simply because work is running severely behind schedule.
EARNED VALUE MANAGEMENT BASICS
METRIC VALUE
│ Budget at Completion (BAC)
│ ┌───────────
│ Actual Cost (AC)│
│ ▲ │
│ / ▼
│ Planned Value (PV) Cost Overrun
│ ▲ / (AC > EV)
│ / /
│ / / Earned Value (EV)
│ / / (Work actually accomplished)
│ / /
│ / / Schedule Delay (EV < PV)
│ / /
└──────────────────────┴──────────┴────────────────────────► TIME
Current
Date (Now)
Core EVM Metrics and Definitions
| EVM Metric | Alternative Acronym | Definition & Core Question | Formula |
|---|---|---|---|
| Planned Value (PV) | BCWS | What did we plan to accomplish by today? The baselined budgeted cost of work scheduled to be completed up to the reporting date. | Baselines from Stage Plan Schedule |
| Earned Value (EV) | BCWP | What have we actually accomplished? The budgeted value of work completed and verified up to the reporting date. | $\sum (\text{Approved Deliverable Baseline Budgets})$ |
| Actual Cost (AC) | ACWP | What did it actually cost to do that work? The total incurred cost of completing the work performed up to the reporting date. | Incurred expenditure from accounting records |
| Budget at Completion (BAC) | Total Baseline | Total agreed budget for the entire stage or project. | Baselined Stage Budget |
EVM Variances and Performance Indices
From these foundational metrics, the Project Manager calculates variances and predictive performance indices:
┌─────────────────────────────────────────────────────────────────────────────┐
│ EVM VARIANCES & PERFORMANCE INDICES │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. COST VARIANCE (CV) │
│ Formula: CV = EV - AC │
│ • Positive (> 0): UNDER BUDGET (Favorable) │
│ • Zero (= 0): EXACTLY ON BUDGET │
│ • Negative (< 0): OVER BUDGET (Unfavorable) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. SCHEDULE VARIANCE (SV) │
│ Formula: SV = EV - PV │
│ • Positive (> 0): AHEAD OF SCHEDULE (Favorable) │
│ • Zero (= 0): ON SCHEDULE │
│ • Negative (< 0): BEHIND SCHEDULE (Unfavorable) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. COST PERFORMANCE INDEX (CPI) │
│ Formula: CPI = EV / AC │
│ • CPI > 1.0: Cost efficient (earning more than $1 of value per $1 spent) │
│ • CPI = 1.0: Exactly on budget rate │
│ • CPI < 1.0: Cost inefficient (cost overrun run-rate) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. SCHEDULE PERFORMANCE INDEX (SPI) │
│ Formula: SPI = EV / PV │
│ • SPI > 1.0: Delivering scope faster than scheduled │
│ • SPI = 1.0: Delivering scope exactly at planned speed │
│ • SPI < 1.0: Delivering scope slower than scheduled │
├─────────────────────────────────────────────────────────────────────────────┤
│ 5. ESTIMATE AT COMPLETION (EAC) │
│ Formula: EAC = BAC / CPI │
│ • Projects total final stage cost based on historical cost efficiency. │
│ • Feed-forward trigger: If EAC > Stage Budget + Tolerance ──► EXCEPTION! │
└─────────────────────────────────────────────────────────────────────────────┘
Practical EVM Calculation Example
A software development stage has a total Budget at Completion (BAC) of $200,000. At the mid-stage checkpoint:
- Planned Value (PV): $100,000 (we scheduled 50% of the deliverables to be done).
- Earned Value (EV): $80,000 (quality testing has verified only 40% of deliverables).
- Actual Cost (AC): $100,000 (the team spent $100,000 to deliver that 40%).
Calculations:
- $CV = EV - AC = $80,000 - $100,000 = -$20,000$ (Over budget by $20k)
- $SV = EV - PV = $80,000 - $100,000 = -$20,000$ (Behind schedule by $20k)
- $CPI = EV / AC = 80,000 / 100,000 = 0.80$ (We receive only 80 cents of value for every dollar spent)
- $SPI = EV / PV = 80,000 / 100,000 = 0.80$ (We are progressing at 80% of planned velocity)
- $EAC = BAC / CPI = $200,000 / 0.80 = $250,000$
Governance Evaluation: If the agreed stage cost tolerance is +$25,000 (maximum allowable cost ceiling of $225,000), the forecast final expenditure ($EAC = $250,000$) will breach tolerance by $25,000. The Project Manager cannot hope things improve; the PM must raise an immediate Exception Report to the Project Board.
3. Tracking Progress in Agile and Hybrid Delivery Environments
When a PRINCE2 project utilizes agile delivery frameworks (such as Scrum, Kanban, or Lean), progress reporting is tailored to leverage visual, empirical data.
┌─────────────────────────────────────────────────────────────────────────────┐
│ AGILE PROGRESS TRACKING TECHNIQUES │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. BURN-DOWN CHARTS │
│ • Visualizes remaining work (story points or hours) versus time. │
│ • Trajectory slopes downward toward zero at the end of the sprint or stage. │
│ • Detects whether the team will complete the committed timebox backlog. │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. BURN-UP CHARTS │
│ • Displays two distinct lines over time: Total Scope Line and Completed │
│ Work Line. │
│ • Vital governance diagnostic: Clearly separates delays caused by slow │
│ delivery from delays caused by SCOPE EXPANSION (uncontrolled backlog add) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. CUMULATIVE FLOW DIAGRAMS (CFD) │
│ • Tracks work items across workflow stages (To Do, In Progress, Test, Done).│
│ • Visualizes work in progress (WIP), lead time, cycle time, and bottlenecks.│
│ • A widening 'In Progress' band indicates severe delivery bottlenecks. │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. VELOCITY │
│ • The empirical measure of how many story points an agile team delivers, │
│ tests, and accepts per iteration. │
│ • Used by the PM to calculate realistic completion forecasts for stages. │
├─────────────────────────────────────────────────────────────────────────────┤
│ 5. WORK IN PROGRESS (WIP) LIMITS │
│ • Explicit caps on how many tasks can be in active development at once. │
│ • Enforces 'Stop Starting, Start Finishing', reducing multitasking waste. │
└─────────────────────────────────────────────────────────────────────────────┘
Mapping Agile Metrics into PRINCE2 Governance
In a hybrid PRINCE2 project, agile metrics are not kept secret within the development room; they feed directly into formal PRINCE2 management products:
- Team Level to Project Manager (Checkpoint Report): The Team Manager uses sprint burn-down charts, velocity metrics, and CFD flow data to populate the regular Checkpoint Report submitted to the Project Manager.
- Project Manager to Project Board (Highlight Report): The Project Manager aggregates release burn-up charts and velocity trends into the Highlight Report, translating technical agile metrics into executive business impacts (e.g., 'Release 2 will complete on schedule with 100% of Must Haves and 80% of Should Haves').
4. Sustainability Performance Reporting in PRINCE2 7
PRINCE2 7 elevates environmental and social sustainability to a core project performance target. Progress reporting must provide verifiable, audited transparency on sustainability metrics against agreed baselines and tolerances.
Core Sustainability Metrics for Progress Tracking
Depending on the project environment (e.g., construction, manufacturing, digital IT, organizational change), sustainability performance is tracked across four quantifiable dimensions:
┌─────────────────────────────────────────────────────────────────────────────┐
│ QUANTIFIABLE SUSTAINABILITY PROGRESS METRICS │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. CARBON FOOTPRINT (EMBODIED & OPERATIONAL) │
│ • Metric: Metric tons of carbon dioxide equivalent (tCO2e). │
│ • Tracking: Incurred emissions from freight transport, heavy machinery, │
│ concrete fabrication, business travel, and data center compute power. │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. ENERGY PERFORMANCE & EFFICIENCY │
│ • Metric: Kilowatt-hours (kWh) consumed, renewable energy percentage, │
│ or Energy Star / LEED / BREEAM efficiency ratings. │
│ • Tracking: Energy consumption during delivery and projected asset rating. │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. RESOURCE CIRCULARITY & SUSTAINABLE SOURCING │
│ • Metric: Percentage of recycled, reclaimed, or certified sustainable │
│ materials (e.g., FSC certified timber, 30% recycled aggregate). │
│ • Tracking: Audited procurement receipts against Product Descriptions. │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. WASTE DIVERSION RATE │
│ • Metric: Percentage of construction, manufacturing, or packaging waste │
│ diverted from landfill to reuse or recycling facilities. │
│ • Tracking: Certified waste disposal receipts and scrap recycling logs. │
└─────────────────────────────────────────────────────────────────────────────┘
Integrating Sustainability into Progress Management Products
- Highlight Report: The Project Manager includes a dedicated Sustainability section in every Highlight Report, comparing actual carbon/energy run-rates against the Stage Plan baseline and reporting remaining sustainability tolerances.
- End Stage Report: During Managing a Stage Boundary, the PM produces an audited sustainability assessment for the stage, verifying that completed deliverables comply with the environmental standards baselined in their Product Descriptions.
- End Project Report: At project closeout, the PM compiles a cumulative sustainability performance record, documenting total project emissions, circular materials utilized, and handing over operational energy baselines to the operational facility management team.
5. Capturing Progress in Core PRINCE2 Registers and Logs
Progress data must be recorded in authoritative, auditable repositories. PRINCE2 defines three primary operational management products that capture progress across different governance dimensions:
┌─────────────────────────────────────────────────────────────────────────────┐
│ THE THREE CORE PROGRESS LOGS & REGISTERS IN PRINCE2 │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. DAILY LOG │
│ • Custodian: Project Manager │
│ • Purpose: Informal day-to-day diary for operational observations, minor │
│ problems, tactical notes, informal commitments, and reminders. │
│ • Exam Rule: Used before registers are set up (in Starting Up a Project) │
│ and throughout the project for matters below formal register thresholds. │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. LESSONS LOG │
│ • Custodian: Project Manager (supported by Project Support) │
│ • Purpose: Repository for empirical insights, learning points, estimation │
│ accuracies, and process refinements from past and current stages. │
│ • Exam Rule: Seeded in SU/IP from external projects; actively updated at │
│ stage boundaries; feeds the final Lessons Report at project closure. │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. QUALITY REGISTER │
│ • Custodian: Project Support (or Project Manager) │
│ • Purpose: Definitive inventory of all planned and executed quality events │
│ (reviews, tests, inspections), reviewers, target dates, and results. │
│ • Exam Rule: THE SINGLE SOURCE OF TRUTH FOR PRODUCT COMPLETION. A product │
│ is NEVER complete until signed off as approved in the Quality Register. │
└─────────────────────────────────────────────────────────────────────────────┘
Comparative Register Matrix
| Register / Log | Primary Purpose | Who Maintains It? | Key Entries / Contents | When is it Created & Closed? |
|---|---|---|---|---|
| Daily Log | Track informal operational items, minor queries, daily tasks, and notes. | Project Manager | Informal problems, weather delays, meeting notes, tactical action reminders. | Created in Starting Up a Project (SU); closed at Project Closure (CP). |
| Lessons Log | Capture reusable project management insights, mistakes, and successes. | Project Manager / Project Support | Lesson description, trigger event, root cause, recommendation for future projects. | Created in Starting Up a Project (SU); closed at Project Closure (CP). |
| Quality Register | Record quality activity schedule, test results, and formal product sign-offs. | Project Support (or Project Manager) | Product ID, quality method, producer, reviewers, planned date, actual date, result (Pass/Fail), sign-off. | Created in Initiating a Project (IP); closed at Project Closure (CP). |
6. Practical Scenario Evaluations
Scenario A: The "90% Complete" Deliverable Illusion
On a commercial mobile banking application project, the development team reports at the weekly progress meeting that the automated transaction-clearing microservice is '95% complete.' The Project Manager accepts this figure and records the microservice as 95% complete in the monthly Highlight Report sent to the Project Board. Two weeks later, integration testing reveals that the microservice fails under high concurrent loads and lacks encryption compliance. Rework takes six additional weeks, causing a severe stage delay.
Practitioner Evaluation:
- Governance Flaw: Bypassing product-based progress measurement and the Quality Register.
- Impact: Accepting subjective percentage estimates deceived the Project Board. The microservice was functionally incomplete because it failed to meet its baselined quality specifications.
- Correct PRINCE2 Action: In PRINCE2, deliverables operate under binary completion rules. A product cannot be credited with progress in Highlight Reports until it passes its formal quality test and is signed off as approved in the Quality Register. The PM should have reported the deliverable as 'In Development' with zero approved value until verified.
Scenario B: EVM Divergence Warning (Behind Schedule but Looking Under Budget)
A civil construction stage building an access bridge has a Budget at Completion (BAC) of $1,000,000 and an agreed cost tolerance of ±$50,000. At month 4 of the 8-month stage, accounting records show actual expenditure (AC) of $350,000 against a planned budget (PV) of $500,000. The Project Manager reports to the board: 'We are in outstanding financial shape; we have spent $150,000 less than planned.' However, an independent audit reveals that physical bridge pier construction has stalled; verified Earned Value (EV) is only $250,000.
Practitioner Evaluation:
- Governance Flaw: Confusing cash expenditure with progress delivery.
- Impact: The stage is not in 'outstanding financial shape'—it is in catastrophic distress:
- $CV = EV - AC = $250,000 - $350,000 = -$100,000$ (Over budget by $100k for work performed)
- $SV = EV - PV = $250,000 - $500,000 = -$250,000$ (Massively behind schedule)
- $CPI = EV / AC = $250,000 / $350,000 = 0.714$
- $EAC = BAC / CPI = $1,000,000 / 0.714 = $1,400,000$
- Correct PRINCE2 Action: Projected stage completion cost is $1,400,000, which exceeds the stage cost ceiling ($1,050,000) by $350,000. The PM must immediately cease reporting false financial savings and submit an urgent Exception Report to the Project Board.
Scenario C: Agile Scope Creep Exposed by a Burn-Up Chart
A hybrid project team is delivering a cloud CRM system. After four 2-week sprints, the sprint burn-down charts show that the team has failed to reach zero remaining points in every sprint. The lead developer blames the team's low coding velocity. However, the Project Manager analyzes the release Burn-Up Chart and discovers that the team's velocity has remained rock-solid at 40 story points per sprint. The real culprit is the Total Scope line: user representatives have silently added 65 new story points of features directly into the sprint backlogs without raising Requests for Change.
Practitioner Evaluation:
- Governance Flaw: Uncontrolled scope creep masquerading as poor team performance.
- Impact: Sprint burn-down charts only show remaining work; they cannot differentiate between slow coding and expanding scope. Burn-up charts display both scope and completed work, exposing unauthorized backlog churn.
- Correct PRINCE2 Action: The PM must freeze the backlog. The newly requested features represent a breach of Work Package scope tolerance. The PM must instruct the Product Owner to enforce agile scope trading (swapping new features for lower-priority stories of equal point value) or submit formal Requests for Change to the Change Authority under the Issues practice.
7. Practitioner Exam Pitfalls & Governance Traps
- Trap 1: Reporting Deliverables as Completed Without Quality Register Sign-Off: A deliverable is never complete based on developer assertions. The definitive test for completion in PRINCE2 is formal quality approval recorded in the Quality Register.
- Trap 2: Treating Money Spent as Work Delivered: Expending 70% of the stage budget does not mean 70% of the work has been accomplished. Always look for Earned Value ($EV$), not just Actual Cost ($AC$).
- Trap 3: Believing CPI and SPI Under 1.0 Represent Good Performance: Both $CPI$ and $SPI$ must equal or exceed $1.0$ for favorable performance. An index below $1.0$ indicates cost overruns ($CPI < 1.0$) or schedule delays ($SPI < 1.0$).
- Trap 4: Overlooking Sustainability Reporting in Highlight Reports: In PRINCE2 7, progress reporting is incomplete if it omits sustainability metrics. The Project Manager must track carbon, energy, and material metrics against baselined tolerances.
- Trap 5: Confusing the Daily Log with the Quality Register: Minor operational notes and daily action reminders go into the Daily Log. Deliverable quality testing dates, inspection results, and sign-offs must be formally documented in the Quality Register.
A civil engineering contractor is executing Stage 3 of a highway interchange project with a baselined Stage Budget (Budget at Completion - BAC) of $2,000,000 and an agreed cost tolerance of ±$100,000 (maximum cost ceiling of $2,100,000). At the mid-point of the stage, the Project Manager reviews the Earned Value Management metrics: Planned Value (PV) = $1,000,000; Earned Value (EV) = $800,000; Actual Cost (AC) = $1,000,000. Assuming current cost efficiency trends continue for the remainder of the stage, what is the projected Estimate at Completion (EAC) and what governance action must the Project Manager take?
On a commercial software development project delivered using Scrum within a PRINCE2 governance environment, the hybrid delivery team has completed four 2-week sprints. The Project Manager observes that while the sprint burn-down charts have consistently shown unfinished user stories at sprint ends, team velocity has remained stable at 45 story points per sprint. Upon inspecting the release Burn-Up Chart, the Project Manager discovers that the Total Scope line has increased by 70 story points across the last three sprints due to marketing stakeholders adding features directly to the product backlog. How should the Project Manager intervene under PRINCE2 7?
During the construction of an eco-friendly corporate headquarters, structural testing of the main atrium timber beams confirms that they satisfy all load-bearing, fire safety, and aesthetic criteria baselined in their Product Description. The structural engineer signs off the inspection as 'Pass' in the Quality Register. However, the environmental sustainability officer discovers that the timber supplier shipped non-certified timber harvested from an unverified overseas source, resulting in transport emissions that will push the stage's carbon footprint 25% above the baseline. The agreed stage sustainability tolerance allows a maximum increase of +5%. How must this situation be handled under PRINCE2 7 progress and quality controls?