What Is Earned Schedule? ES for Construction 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="#how-earned-schedule-is-derived">How Earned Schedule Is Derived</a></li><li><a href="#the-formulas">The Formulas</a></li><li><a href="#why-spi-breaks-down-and-es-doesnt">Why SPI Breaks Down (And ES Doesn't)</a></li><li><a href="#worked-example-30m-water-treatment-programme">Worked Example: £30M Water Treatment Programme</a></li><li><a href="#when-to-use-earned-schedule">When to Use Earned Schedule</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>Earned schedule (ES) is a time-based extension to <a href="/en/earned-value/definitions/earned-value-management">earned value management</a> that measures programme performance in units of time rather than cost. Developed by Walt Lipke in 2003, it fixes a fundamental flaw in traditional EVM: the <a href="/en/earned-value/definitions/schedule-performance-index">Schedule Performance Index</a> (SPI) becomes unreliable in the second half of a project because it always converges to 1.0 at completion, even on projects that finished catastrophically late. Earned schedule solves this by asking a different question: at what point in the baseline programme did we plan to have completed the amount of work we've actually done?</p><p>That's the core idea. If you're at month 12 and you've completed £18M of work, but the baseline says you should have reached £18M by month 10.3, then your earned schedule is 10.3 months. You're 1.7 months behind. No ambiguity. No convergence problem. Just a straight answer to "how far behind are we?"</p><p>For the full EVM framework and how ES fits within it, see the <a href="/en/earned-value">earned value management guide</a>.</p><h2 id="how-earned-schedule-is-derived">How Earned Schedule Is Derived</h2><p>ES isn't a separate data collection exercise. It uses the same <a href="/en/earned-value/definitions/planned-value">Planned Value</a> and <a href="/en/earned-value/definitions/earned-value">Earned Value</a> data you're already capturing. The derivation is geometric, you find the point on the PV curve where cumulative PV equals your current cumulative EV.</p><pre class="ge-ascii-diagram ge-anim"> EARNED SCHEDULE – S-CURVE DERIVATION ========================================= £M | 30| __.---PV (Planned) | _.--'' 25| _.--' | _.--' 20| _.--' | - - - - - - - -x--' - - - - - - EV at month 12 = £18M 18|. . /. | / . 15| / . | / . 10| / ___--'---- EV (Actual progress) | / _--'' 5| /--' | / 0|_/______________________________________________ Time 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ↑ ↑ ES=10.3 AT=12 | | |&lt;-- <a href="/en/earned-value/definitions/schedule-variance-time">SV(t)</a> = -1.7 months --&gt;| ES = the time at which PV = current EV = 10 + (18M - PV at month 10) / (PV at month 11 - PV at month 10) = 10 + (18M - 17.2M) / (19.8M - 17.2M) = 10 + 0.8M / 2.6M = 10.3 months SV(t) = ES - AT = 10.3 - 12 = -1.7 months (behind schedule) <a href="/en/earned-value/definitions/schedule-performance-index-time">SPI(t)</a> = ES / AT = 10.3 / 12 = 0.86 (86% schedule efficiency) </pre><p>The interpolation is linear between the two baseline periods that bracket your current EV. It's not perfectly accurate, the PV curve isn't truly linear between monthly points, but in practice, the approximation is more than sufficient for project controls decisions.</p><h2 id="the-formulas">The Formulas</h2><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Metric</th><th>Formula</th><th>What It Tells You</th></tr></thead><tbody><tr><td>ES</td><td>C + (EV - PV_C) / (PV_{C+1} - PV_C)</td><td>How many months of baseline progress you've achieved</td></tr><tr><td>SV(t)</td><td>ES - AT</td><td><a href="/en/earned-value/definitions/schedule-variance">Schedule variance</a> in time units (months)</td></tr><tr><td>SPI(t)</td><td>ES / AT</td><td>Schedule efficiency (< 1.0 = behind)</td></tr><tr><td>IEAC(t)</td><td>PD / SPI(t)</td><td>Independent estimate of total project duration</td></tr></tbody></table></div><p>Where:</p><ul><li><strong>C</strong> = the last complete period where cumulative PV <= cumulative EV</li><li><strong>AT</strong> = Actual Time (current period number)</li><li><strong>PD</strong> = Planned Duration (baseline programme length)</li></ul><h2 id="why-spi-breaks-down-and-es-doesnt">Why SPI Breaks Down (And ES Doesn't)</h2><p>This is the reason earned schedule exists. Traditional <a href="/en/earned-value/definitions/schedule-performance-index">SPI</a> (SPI = EV / PV) has a mathematical flaw: at the end of a project, cumulative EV and cumulative PV both converge to <a href="/en/earned-value/definitions/budget-at-completion">BAC</a>. So SPI converges to 1.0 regardless of how late the project finishes.</p><p>I've watched this happen in real time. A £40M rail project was running at SPI 0.78 at the halfway point. Genuinely behind. By month 14 of 18, SPI had crept back up to 0.91. Not because the project was recovering, but because the maths was converging. The project finished 5 months late. SPI at completion? 1.0. Completely useless as an indicator.</p><p>SPI(t) from earned schedule doesn't have this problem. If you finish 5 months late on an 18-month programme, SPI(t) = 18/23 = 0.78 at completion. It stays honest.</p><pre class="ge-ascii-diagram ge-anim"> SPI vs SPI(t) – THE CONVERGENCE PROBLEM ========================================== Index 1.1| | 1.0|─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─* SPI converges | ___---'' to 1.0 even though 0.9| ___--'' project finishes | ___--'' 5 months late! 0.8|─ ─ ─ ─ ─ ─ ─*─--'' ─ ─ ─ ─ ─ ─ ─ ─ ─* SPI(t) stays at | _-' \ 0.78 – honest 0.7| _-' \___ to the end | _-' ----____ 0.6|__--' -----_____ | 0.5|_____________________________________________ 0 2 4 6 8 10 12 14 16 18 20 22 ↑ ↑ Planned Actual Finish Finish ── SPI (traditional) ── SPI(t) (earned schedule) </pre><h2 id="worked-example-30m-water-treatment-programme">Worked Example: £30M Water Treatment Programme</h2><span class="ge-worked-label">Worked Example</span><div class="ge-callout ge-anim"><p><strong>Scenario:</strong> You're managing earned value on a £30M water treatment programme under NEC4 Option C. The baseline programme is 20 months (April 2025 to November 2026). You're now at month 12 (March 2026) and need to assess schedule performance.</p><p><strong>Baseline PV (cumulative, from cost-loaded Accepted Programme):</strong></p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Month</th><th>8</th><th>9</th><th>10</th><th>11</th><th>12</th><th>13</th><th>14</th></tr></thead><tbody><tr><td>PV (£M)</td><td>10.8</td><td>13.2</td><td>15.5</td><td>17.9</td><td>20.4</td><td>22.6</td><td>24.8</td></tr></tbody></table></div><p><strong>Actual EV at month 12:</strong> £16.8M</p><p><strong>Step 1: Find C</strong> £16.8M falls between PV at month 10 (£15.5M) and month 11 (£17.9M). So C = 10.</p><p><strong>Step 2: Interpolate</strong> ES = 10 + (16.8 - 15.5) / (17.9 - 15.5) = 10 + 1.3 / 2.4 = 10.54 months</p><p><strong>Step 3: Calculate time-based metrics</strong></p><ul><li>SV(t) = 10.54 - 12 = <strong>-1.46 months</strong> (nearly 6.5 weeks behind)</li><li>SPI(t) = 10.54 / 12 = <strong>0.878</strong> (87.8% schedule efficiency)</li><li>IEAC(t) = 20 / 0.878 = <strong>22.8 months</strong> (projected 2.8 months late)</li></ul><p><strong>Compare with traditional SPI:</strong></p><ul><li>SPI = EV / PV = 16.8 / 20.4 = 0.824</li></ul><p>Both tell a similar story at month 12. But here's the critical difference: as this project approaches completion, SPI will drift toward 1.0 even if the delays worsen. SPI(t) won't. If the project director asks you in month 18 whether you'll finish on time, SPI(t) will give an honest answer. SPI will lie.</p><p><strong>What you do with this:</strong> An SPI(t) of 0.878 and a projected 2.8-month overrun is serious on a water treatment programme with a regulatory commissioning deadline. This triggers an <a href="/en/earned-value/definitions/early-warning">early warning</a> under clause 16.1. This matter could delay Completion. The risk reduction meeting should examine root causes (design delays? Resource shortages? Interface issues?) and evaluate acceleration options. The IEAC(t) of 22.8 months gives you a quantified basis for that conversation.</p></div><h2 id="when-to-use-earned-schedule">When to Use Earned Schedule</h2><p>ES is most valuable in the second half of a project and on programmes longer than 12 months. On a 6-month fit-out, traditional SPI is probably fine, the convergence issue doesn't have time to become material. On an 18-month infrastructure programme, ES is essential from month 10 onwards.</p><p>I'd recommend tracking both SPI and SPI(t) from the start, even if they tell the same story early on. Having the parallel data makes it obvious when they start to diverge, and that divergence itself is a useful <a href="/en/earned-value/definitions/early-warning">early warning signal</a>.</p><p>For construction specifically, ES also solves a communication problem. Telling a project director "SPI is 0.87" requires them to understand what SPI means. Telling them "we're 1.5 months behind based on earned schedule analysis" is instantly comprehensible. Time is a language everyone speaks.</p><h2 id="common-mistakes">Common Mistakes</h2><ol><li><strong>Only switching to ES when SPI stops working</strong>: By the time you notice SPI converging, you've lost months of ES trend data. Track both from day one. The overhead is negligible because ES uses the same underlying PV and EV data.</li></ol><ol><li><strong>Applying ES to LOE work packages</strong>: Level of Effort packages (site management, supervision, etc.) earn value linearly over time by definition. Their SPI is always approximately 1.0 and their ES is always approximately equal to AT. Including them in programme-level ES calculations dilutes the signal. Filter them out.</li></ol><ol><li><strong>Ignoring the interpolation assumption</strong>: ES assumes linear PV growth between reporting periods. If your baseline has a massive ramp-up in a single period (say a £3M concrete pour concentrated in the last week of month 8), the linear interpolation can be misleading. For critical decisions, sanity-check ES against the detailed programme logic.</li></ol><ol><li><strong>Confusing SV(t) with float</strong>: SV(t) tells you how far behind the baseline you are in time. It doesn't tell you whether you've consumed float on the critical path. A project with SV(t) of -2 months might still finish on time if the baseline had 3 months of float. Always read ES alongside the programme's critical path analysis.</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>What's the difference between SPI and SPI(t)?</h3><p><a href="/en/earned-value/definitions/schedule-performance-index">SPI</a> (EV/PV) measures schedule performance in cost terms. SPI(t) from earned schedule (ES/AT) measures it in time terms. Early in a project, they produce similar results. In the second half, SPI converges toward 1.0 regardless of actual delay, while SPI(t) remains accurate. For projects longer than 12 months, SPI(t) is the more reliable indicator from the midpoint onwards.</p><h3>Can I use earned schedule on NEC4 contracts?</h3><p>Absolutely. ES uses the same PV and EV data as standard <a href="/en/earned-value/definitions/earned-value-management">EVM</a>. On NEC4 Option C, your PV comes from the cost-loaded <a href="/en/nec4/programme-management">Accepted Programme</a> and your EV from progress measurement against <a href="/en/earned-value/definitions/actual-cost">Defined Cost</a>. There's nothing contract-specific about ES. It's a calculation method, not a contractual requirement.</p><h3>Is earned schedule widely used in UK construction?</h3><p>Honestly? Not as widely as it should be. It's more established in defence and aerospace, where Lipke's original research gained traction. In UK construction, most commercial teams still rely on traditional SPI and only discover its limitations when a project runs late and the numbers don't add up. The Government's Infrastructure and Projects Authority (IPA) has been pushing for better schedule performance metrics, and ES is gaining ground on major frameworks. If you're on any Network Rail or Highways England programme over £50M, I'd argue it's negligent not to track it.</p><h3>How often should I calculate earned schedule?</h3><p>At the same frequency as your standard <a href="/en/earned-value/report-template">EVM reporting</a>, typically monthly on UK construction projects, aligned with the payment cycle. Some teams calculate ES fortnightly on fast-track programmes, but monthly is sufficient for most infrastructure work. The key is consistency: sporadic ES calculations destroy trend analysis.</p></article></div>