Baseline Change in Earned Value Management Explained

<div class="ge-article-wrapper"><nav class="ge-toc" aria-label="Table of contents"><p class="ge-toc-label">In this article</p><ul class="ge-toc-list"><li><a href="#the-core-concept">The Core Concept</a></li><li><a href="#original-baseline-vs-revised-baseline">Original Baseline vs Revised Baseline</a></li><li><a href="#replanning-vs-reprogramming">Replanning vs Reprogramming</a></li><li><a href="#worked-example-ce-triggering-a-baseline-change-on-nec4-option-c">Worked Example: CE Triggering a Baseline Change on NEC4 Option C</a></li><li><a href="#when-baseline-changes-are-legitimate">When Baseline Changes Are Legitimate</a></li><li><a href="#when-theyre-hiding-problems">When They're Hiding Problems</a></li><li><a href="#common-mistakes">Common Mistakes</a></li><li><a href="#frequently-asked-questions">Frequently Asked Questions</a></li></ul></nav><article class="ge-article-body"><p>A baseline change is a formal modification to the Performance Measurement Baseline (PMB), the approved, time-phased budget plan against which project performance is measured. When the baseline changes, <a href="/en/earned-value/definitions/budget-at-completion">BAC</a> changes. The <a href="/en/earned-value/definitions/planned-value">PV</a> curve shifts. And every <a href="/en/earned-value">earned value</a> metric recalculates against a new reference point.</p><p>Baseline changes are necessary. Scope changes. Compensation events on NEC4. Client instructions that add genuine new work. These are all legitimate reasons to adjust the baseline. The problem is distinguishing legitimate adjustments from the ones that are quietly hiding a cost overrun. I've seen both, and the second type is far more common than anyone in project controls wants to admit.</p><p>This term is part of the <a href="/en/earned-value/definitions">earned value definitions glossary</a>. For how baseline changes affect forecasting metrics, see <a href="/en/earned-value/eac-etc-tcpi">EAC, ETC, and TCPI</a>.</p><h2 id="the-core-concept">The Core Concept</h2><p>The PMB is your plan expressed in money and time. It's the answer to “how much should we have spent by now?” Every time you calculate <a href="/en/earned-value/definitions/schedule-performance-index">SPI</a> or <a href="/en/earned-value/definitions/cost-performance-index">CPI</a>, you're comparing actual performance against the baseline. Change the baseline and you change what “on track” means.</p><p>That's powerful. And dangerous.</p><p><strong>Legitimate baseline change:</strong> The client instructs additional scope worth £400K. BAC increases. PV extends. The baseline now reflects the new reality.</p><p><strong>Illegitimate baseline change:</strong> The project is £400K over budget, so someone re-baselines to absorb the overrun. BAC increases. The overrun disappears from the metrics. Nothing actually improved.</p><p>Same mechanism. Completely different intent. The difference is whether the budget increase comes with corresponding new scope.</p><h2 id="original-baseline-vs-revised-baseline">Original Baseline vs Revised Baseline</h2><p>Here's what a baseline change looks like on the PV curve. The original baseline (solid line) shows the plan before the change. The revised baseline (dashed line) shows the plan after. The gap between them is the scope change.</p><pre class="ge-ascii-diagram ge-anim"> £ (cumulative) │ │ ╱── Revised BAC (£16.4M) │ ╱╱╱ │ ╱╱╱ ╱── Original BAC (£15.0M) │ ╱╱╱ ╱╱╱ │ ╱╱╱ ╱╱╱ │ ╱╱╱ ╱╱╱ │ ╱╱╱ ╱╱╱ Revised PV (dashed) │ ╱╱╱ ╱╱╱ includes new scope │ ╱╱╱ ╱╱╱ │ ╱╱╱ ╱╱╱ │ ╱╱╱ ╱╱╱ │ ╱╱╱──╱╱╱ CE approved at month 5 │ ╱╱╱╱╱╱╱ adds £1.4M to baseline │ ╱╱╱╱╱ ├──────────────────────────────────────────── Time M1 M3 M5 M7 M9 M11 M13 M15 Before month 5: both baselines identical After month 5: revised baseline higher by £1.4M Variances measured against REVISED baseline going forward Historical performance measured against ORIGINAL baseline ┌──────────────────────────────────────────────┐ │ VARIANCE RESET AT CHANGE POINT │ │ │ │ Pre-change SV: measured vs original PV │ │ Post-change SV: measured vs revised PV │ │ │ │ No retrospective adjustment. │ │ The change creates a clean break. │ └──────────────────────────────────────────────┘ </pre><p>Notice that the baseline change doesn't erase historical variances. If you were £200K behind schedule before the CE was approved, you're still £200K behind schedule, the revised baseline just means the go-forward measurement uses the new plan. History isn't rewritten. That's a principle, not a suggestion.</p><h2 id="replanning-vs-reprogramming">Replanning vs Reprogramming</h2><p>These two terms sound similar. They're fundamentally different. Confusing them is one of the most costly mistakes in earned value management.</p><p><strong>Replanning</strong> happens within the existing Contract Budget Base (CBB). You're moving budget between work packages or adjusting the time-phasing, but the total doesn't change. BAC stays the same. You're just re-arranging the furniture.</p><p><strong>Reprogramming</strong> happens when the total budget needs to change, when BAC must increase (or, rarely, decrease) because the scope or conditions have fundamentally shifted. On NEC4, this is typically triggered by compensation events.</p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Aspect</th><th>Replanning</th><th>Reprogramming</th></tr></thead><tbody><tr><td>BAC changes?</td><td>No</td><td>Yes</td></tr><tr><td>Total budget changes?</td><td>No, moves between packages</td><td>Yes, new budget authorised</td></tr><tr><td>NEC4 trigger</td><td>Contractor re-sequences own work</td><td>Compensation event implemented</td></tr><tr><td>Approval level</td><td>Project controls manager</td><td>Project Manager (NEC4) or client</td></tr><tr><td>Variance impact</td><td>Redistributes variances between packages</td><td>Resets go-forward baseline</td></tr><tr><td>Audit risk</td><td>Low (if documented)</td><td>High if used to hide overruns</td></tr><tr><td>Example</td><td>Moving £300K from earthworks to structures because the sequence changed</td><td>Adding £520K for unforeseen contamination (CE)</td></tr></tbody></table></div><p>The critical test: did new scope arrive, or are you just reshuffling? If no new scope, it's a replan. If there's genuinely new work that the original baseline didn't contemplate, it's a reprogram and BAC should change.</p><h2 id="worked-example-ce-triggering-a-baseline-change-on-nec4-option-c">Worked Example: CE Triggering a Baseline Change on NEC4 Option C</h2><span class="ge-worked-label">Worked Example</span><div class="ge-callout ge-anim"><p><strong>Scenario:</strong> BAM Nuttall is delivering a £22M NEC4 Option C railway bridge replacement in South Wales. The original baseline has BAC of £22M with a 14-month programme.</p><p>At month 6 (August 2025), a compensation event is notified: the existing bridge foundations are in significantly worse condition than the site investigation indicated. The PM accepts the notification. The Contractor submits a quotation.</p><p><strong>CE quotation (accepted and implemented):</strong></p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Item</th><th>Cost</th></tr></thead><tbody><tr><td>Additional demolition of defective foundations</td><td>£280,000</td></tr><tr><td>Redesigned foundation system (mini-piles)</td><td>£410,000</td></tr><tr><td>Extended prelims (6 weeks delay)</td><td>£195,000</td></tr><tr><td>Subcontractor standing time</td><td>£115,000</td></tr><tr><td><strong>Total CE value</strong></td><td><strong>£1,000,000</strong></td></tr></tbody></table></div><p><strong>Baseline change:</strong></p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Metric</th><th>Before CE</th><th>After CE</th></tr></thead><tbody><tr><td>BAC</td><td>£22,000,000</td><td>£23,000,000</td></tr><tr><td>Planned completion</td><td>Month 14</td><td>Month 15.5 (6-week extension)</td></tr><tr><td>PV at month 6</td><td>£9,400,000</td><td>£9,400,000 (unchanged, CE is future work)</td></tr><tr><td>PV at month 10</td><td>£16,200,000</td><td>£15,800,000 (revised, new activities shift later work)</td></tr></tbody></table></div><p><strong>EVM impact at month 8 (two months after CE):</strong></p><p>Without baseline change (using original BAC £22M):</p><ul><li>EV = £22M x 38% = £8,360,000</li><li>AC = £9,100,000</li><li>CPI = 0.919, looks like a significant overrun</li></ul><p>With baseline change (using revised BAC £23M):</p><ul><li>EV = £23M x 38% = £8,740,000</li><li>AC = £9,100,000</li><li>CPI = 0.960, manageable variance, mostly from the CE disruption</li></ul><p>The difference, 0.919 vs 0.960, completely changes the narrative at the monthly progress meeting. Without the baseline change, the commercial team is defending a cost overrun. With it, they're explaining a variance that's partly transitional (the CE activities are just ramping up).</p><p><strong>Key point:</strong> The baseline change doesn't make the cost disappear. It correctly attributes it to new scope rather than poor performance.</p></div><h2 id="when-baseline-changes-are-legitimate">When Baseline Changes Are Legitimate</h2><p>There are exactly five legitimate reasons to change an EVM baseline:</p><ol><li><strong>Compensation events (NEC4) or variations (JCT/bespoke).</strong> Client-instructed or client-risk scope changes that increase (or decrease) the target. BAC adjusts. PV extends.</li><li><strong>Formal re-scoping.</strong> The client removes a package from the works. BAC decreases. Rare, but it happens.</li><li><strong>Contract re-negotiation.</strong> Major scope or programme changes agreed between parties outside the normal CE mechanism. Usually involves a supplemental agreement.</li><li><strong>Transfer of management reserve to PMB.</strong> Budget held centrally is formally allocated to a specific work package. BAC for the package increases; the total programme budget doesn't.</li><li><strong>Correction of baseline errors.</strong> The original baseline had a mathematical error, a duplicated activity, or a missing package. Correcting it is legitimate, but document the error and the fix.</li></ol><p>Everything else? Not a baseline change. It's a replan.</p><h2 id="when-theyre-hiding-problems">When They're Hiding Problems</h2><p>I've been on projects where the baseline was changed four times in twelve months with no corresponding scope changes. Each time, the CPI magically returned to 0.98. Each time, the forecast overrun evaporated. And each time, the actual spend kept climbing.</p><p>Red flags:</p><ul><li><strong>Frequent baseline changes without compensation events.</strong> If BAC keeps growing but no new scope arrives, someone's re-baselining away cost overruns.</li><li><strong>CPI consistently resetting to ~1.0 after each change.</strong> Real baseline changes don't produce perfect CPI. If every change results in CPI returning to 0.97-1.02, the numbers are being managed.</li><li><strong>No audit trail.</strong> Legitimate baseline changes have a paper trail, a CE notification, a PM assessment, a contract instruction. If there's no source document, the change isn't legitimate.</li><li><strong>Budget moving from future packages to current packages.</strong> “We moved £400K from Phase 3 to Phase 2 because Phase 2 needs it.” That's using future budget to cover a current overrun. The total hasn't changed, but Phase 3 is now underfunded and you've deferred the problem.</li></ul><p>The honest thing to do with a cost overrun is report it. A CPI of 0.88 is uncomfortable but actionable. A CPI of 0.98 that's been fabricated through re-baselining is comfortable and fatal, because nobody takes corrective action on a metric that says everything's fine.</p><h2 id="common-mistakes">Common Mistakes</h2><ol><li><strong>Not updating BAC after implementing CEs.</strong> The most common mistake on NEC4 projects. A compensation event changes the Prices. That's a baseline change. If BAC stays at the original figure, your CPI is understated and your forecast is wrong. I covered this in the <a href="/en/earned-value/definitions/budget-at-completion">BAC definition</a>, it's worth repeating because I see it on every second project.</li><li><strong>Retrospectively adjusting historical performance.</strong> The baseline change applies going forward. Don't restate last month's CPI using the new baseline. Performance before the change was measured against the baseline that was current at the time. Historical integrity matters.</li><li><strong>Confusing replanning with reprogramming.</strong> Moving budget between packages isn't a BAC change. It's internal redistribution. If you bump BAC every time you replan, you're inflating the target without new scope.</li><li><strong>Changing the baseline without updating the programme.</strong> On NEC4, the <a href="/en/earned-value/definitions/accepted-programme">Accepted Programme</a> and the EVM baseline should move together. A CE that adds £500K to BAC also adds activities to the programme. If you change one and not the other, PV and BAC are out of sync.</li><li><strong>Too many baselines.</strong> Some projects end up with “original baseline”, “revised baseline v2”, “revised baseline v3 (for internal use)”, and “the one the PM accepted.” That's chaos. You should have one current baseline at any time. Maintain a log of changes, but the active PMB is singular.</li></ol><div class="ge-product-note ge-anim"><p><strong>How Gather helps.</strong> Gather's AI reads your site diaries daily and maps progress against your cost-loaded programme, giving you accurate earned value data without manual spreadsheet updates. <a href="https://gatherinsights.com/contact">Book a demo</a> to see it working on a live NEC4 project.</p></div><h2 id="frequently-asked-questions">Frequently Asked Questions</h2><h3>How often should baselines change?</h3><p>Only when there's a legitimate trigger, a compensation event, a formal scope change, or a contract re-negotiation. There's no schedule for baseline changes. On a well-administered NEC4 Option C contract, you might see 3 to 8 baseline changes per year depending on the volume of CEs. If you're changing it monthly, something's wrong.</p><h3>What's the difference between a baseline change and a forecast change?</h3><p>A baseline change modifies the plan (BAC, PV). A forecast change modifies the prediction (<a href="/en/earned-value/definitions/estimate-at-completion">EAC</a>, <a href="/en/earned-value/definitions/estimate-to-complete">ETC</a>). The forecast changes every month based on performance. The baseline changes only when scope changes. Forecasts are expected to move. Baselines should be stable.</p><h3>Does a baseline change reset all variances?</h3><p>No. Historical <a href="/en/earned-value/cost-schedule-variance">CV</a> and SV remain as they were. The change affects go-forward measurement. From the change point onward, PV reflects the new baseline. Past performance is measured against the baseline that was current at the time. Cumulative metrics (CPI, SPI) will naturally shift as new data is measured against the new baseline, but there's no reset button.</p><h3>Can the Project Manager reject a baseline change on NEC4?</h3><p>The PM doesn't approve “baseline changes” as an EVM concept. That's a project controls mechanism. What the PM does is accept (or not accept) the Contractor's programme and assess compensation events. If a CE quotation is accepted and implemented, BAC changes as a consequence. The PM controls the trigger (the CE), not the EVM response to it.</p></article></div>