SPI(t): Time-Based Schedule Performance Index 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-formula">The Formula</a></li><li><a href="#how-earned-schedule-works-the-key-concept">How Earned Schedule Works (The Key Concept)</a></li><li><a href="#why-spi-t-doesnt-converge">Why SPI(t) Doesn't Converge</a></li><li><a href="#worked-example-the-project-that-spi-said-was-fine">Worked Example: The Project That SPI Said Was Fine</a></li><li><a href="#spi-vs-spi-t-head-to-head-comparison">SPI vs SPI(t): Head-to-Head Comparison</a></li><li><a href="#when-to-use-spi-t-instead-of-spi">When to Use SPI(t) Instead of SPI</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>SPI(t) is the time-based version of the <a href="/en/earned-value/definitions/schedule-performance-index">Schedule Performance Index</a>, and it fixes the single biggest problem with traditional SPI. Where SPI converges to 1.0 at project end (even if the project finishes months late), SPI(t) stays honest. It measures schedule efficiency in time units using earned schedule methodology, and it doesn't flinch from telling you the truth when a project is behind.</p><p>The formula: <strong>SPI(t) = ES / AT</strong>. Earned Schedule divided by Actual Time. Simple arithmetic, but the difference from traditional SPI is significant, especially in the final third of a project where traditional SPI becomes actively misleading.</p><p>SPI(t) is part of the <a href="/en/earned-value/definitions">earned value definitions glossary</a>. For the cost efficiency counterpart, see <a href="/en/earned-value/definitions/cost-performance-index">CPI</a>.</p><h2 id="the-formula">The Formula</h2><div class="ge-formula-box ge-anim"><span class="ge-formula-label">Formula</span><code>SPI(t) = ES / AT</code></div><p>Where:</p><ul><li><strong>ES (Earned Schedule)</strong> = the point in time when the current EV should have been achieved according to the baseline plan</li><li><strong>AT (Actual Time)</strong> = the actual time elapsed since project start</li></ul><p>ES is found by projecting the current <a href="/en/earned-value/definitions/earned-value">EV</a> horizontally onto the <a href="/en/earned-value/definitions/planned-value">PV</a> curve and reading off the time value. In plain English: if you've earned £12M of value, and according to the plan you should have reached £12M at month 10, then ES = 10, even if you're actually at month 13.</p><h2 id="how-earned-schedule-works-the-key-concept">How Earned Schedule Works (The Key Concept)</h2><p>Earned schedule is an extension of <a href="/en/earned-value">earned value management</a> developed by Walt Lipke in 2003. The insight was elegant: instead of measuring schedule performance in cost units (which causes the convergence problem), measure it in time units by asking "when should we have reached this level of progress?"</p><pre class="ge-ascii-diagram ge-anim">Cumulative Value (£) | | .---*---*---* PV (Baseline) | .---*' | .---*' | .---*' | .---*' | .---*' ← Current EV = £12M |.---*' Project horizontally onto PV curve *' ↓ |....|....| +─────────────+───────────────+──────────── Time ES = 10 AT = 13 months months SPI(t) = ES / AT = 10 / 13 = 0.769 The project is at month 13 but has only achieved the progress expected at month 10. It's 3 months behind.</pre><p>That diagram is the whole concept. Traditional SPI would say EV/PV and give you a ratio in cost terms. SPI(t) says "you're at month 13 but your progress matches where month 10 should be." The second version is more intuitive and, crucially, doesn't converge to 1.0 at project end.</p><h2 id="why-spi-t-doesnt-converge">Why SPI(t) Doesn't Converge</h2><p>Traditional SPI converges because both EV and PV reach <a href="/en/earned-value/definitions/budget-at-completion">BAC</a> at completion. EV/PV = BAC/BAC = 1.0 regardless of delay.</p><p>SPI(t) doesn't have this problem. If a project finishes at month 28 instead of month 24, then at completion:</p><ul><li>AT = 28 months</li><li>ES = 24 months (the plan was 24 months of work, and all of it is done)</li><li>SPI(t) = 24/28 = 0.857</li></ul><p>That 0.857 correctly reflects a project that took 17% longer than planned. Honest to the end.</p><h2 id="worked-example-the-project-that-spi-said-was-fine">Worked Example: The Project That SPI Said Was Fine</h2><span class="ge-worked-label">Worked Example</span><div class="ge-callout ge-anim"><p><strong>Scenario:</strong> A £28M NEC4 Option C water treatment works upgrade. 24-month programme starting January 2024. At month 18 (June 2025), the team runs both SPI and SPI(t).</p><p><strong>Progress data at month 18:</strong></p><ul><li><strong>PV at month 18</strong> = £23.8M (the programme front-loaded commissioning preparation)</li><li><strong>EV</strong> = £21.4M</li><li><strong>AC</strong> = £24.1M</li><li><strong>BAC</strong> = £28M</li></ul><p><strong>Traditional SPI</strong> = £21.4M / £23.8M = <strong>0.899</strong></p><p>Not great, but the project is 75% complete and trending back toward 1.0 as the convergence effect kicks in. In last month's board meeting, the project director noted that "SPI is recovering. It was 0.87 two months ago." That's true, but it's the convergence talking, not actual recovery.</p><p><strong>Earned Schedule calculation:</strong> EV of £21.4M was planned to be reached at approximately month 15.4 (interpolating from the PV curve).</p><p><strong>ES</strong> = 15.4 months <strong>AT</strong> = 18 months</p><p><strong>SPI(t)</strong> = 15.4 / 18 = <strong>0.856</strong></p><p>Traditional SPI says 0.90. SPI(t) says 0.86. That's not a rounding difference. It's the difference between "we're recovering" and "we're 2.6 months behind with 6 months to go." At month 18, SPI(t) translates directly: the project has achieved 15.4 months' worth of progress in 18 months. The remaining 8.6 months of planned work, at current efficiency, will take 8.6 / 0.856 = 10.0 months. Forecast completion: month 28, not month 24.</p><p>That 4-month delay triggers extension of time considerations, LD exposure calculation (£55,000/week x 17.4 weeks = £957,000), and an honest conversation about recovery costs versus accepting the delay.</p></div><h2 id="spi-vs-spi-t-head-to-head-comparison">SPI vs SPI(t): Head-to-Head Comparison</h2><pre class="ge-ascii-diagram ge-anim">TRADITIONAL SPI vs SPI(t) OVER PROJECT LIFE Value | 1.1| | SPI 1.0|─ ─ ─.─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─── ← SPI converges to 1.0 | . '.-----''' 0.9| . '.--' | . '.--' 0.8|. '.-' ← The gap between the two | .''. Lines grows in the 0.7| .' '. Final third | ' '. 0.6| ' SPI(t) '. ← SPI(t) stays honest | '. 0.5| '.____ 0.857 (actual efficiency) | +────────────────────────────────────── Time M1 M6 M12 M18 M24 M28 ↑ ↑ Planned Actual Finish Finish SPI at month 24: ~0.97 (misleading – suggests near-recovery) SPI(t) at month 24: ~0.86 (honest – project is 4 months late)</pre><p>The divergence between SPI and SPI(t) begins around the 60-65% completion mark and widens dramatically in the final quarter. On a severely delayed project, SPI might show 0.95 while SPI(t) shows 0.75. That's not a minor discrepancy. One leads to complacency; the other triggers action.</p><h2 id="when-to-use-spi-t-instead-of-spi">When to Use SPI(t) Instead of SPI</h2><p><strong>First 60% of project:</strong> SPI and SPI(t) track closely. Either works. SPI is simpler to calculate.</p><p><strong>60-80% complete:</strong> SPI starts converging. SPI(t) becomes the more reliable indicator. Use both and note the gap.</p><p><strong>80-100% complete:</strong> SPI is unreliable. Use SPI(t) exclusively for schedule performance assessment. Traditional SPI at this stage is worse than useless. It's actively misleading.</p><p><strong>Post-completion reporting:</strong> Only SPI(t) gives you a meaningful final schedule efficiency metric. SPI will always be 1.0 at completion, which tells you nothing.</p><h2 id="common-mistakes">Common Mistakes</h2><p><strong>1. Calculating ES wrong.</strong> ES requires interpolation on the PV curve. You can't just pick the nearest month, you need to find the precise point where the cumulative PV equals the current EV. Linear interpolation between monthly PV values is accurate enough for most projects.</p><p><strong>2. Not having a reliable PV curve.</strong> SPI(t) depends on PV data being correct and time-distributed. If your cost-loaded programme is rough or the PV curve is stepped rather than smooth, ES interpolation becomes unreliable. The fix is a properly cost-loaded baseline with at least monthly resolution.</p><p><strong>3. Reporting SPI when you should report SPI(t).</strong> After about 65% complete, presenting traditional SPI to a project board is misleading. I've seen commercial managers present an "improving SPI" at month 20 of a 24-month project that was actually running 3 months late. The SPI was improving because of convergence, not recovery. SPI(t) would have shown the truth.</p><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>Is SPI(t) widely used in UK construction?</h3><p>Not yet. Most UK construction teams still use traditional SPI. Earned schedule methodology is well-established in defence and aerospace but hasn't fully penetrated the construction sector. That's changing as more commercial teams recognise the convergence problem, but SPI(t) is still a differentiator, if you're using it, you're ahead of most of your competitors.</p><h3>Can I use SPI(t) in NEC4 contract reporting?</h3><p>NEC4 doesn't prescribe specific earned value metrics. But SPI(t) is an excellent tool for programme management reporting under clause 31/32, especially when demonstrating to the Project Manager that the Accepted Programme shows a delay that isn't visible in traditional SPI. It adds objectivity to what might otherwise be a subjective programme discussion.</p><h3>How does SPI(t) relate to SV(t)?</h3><p><a href="/en/earned-value/definitions/schedule-variance-time">SV(t)</a> = ES - AT. It gives you the schedule variance in time units (e.g., -2.6 months). SPI(t) = ES / AT gives you the ratio (e.g., 0.856). Same data, different format. SV(t) is more intuitive for stakeholders ("we're 2.6 months behind"). SPI(t) is better for trending and comparison ("schedule efficiency is 85.6%").</p><h3>What software calculates SPI(t)?</h3><p>Most dedicated EVM tools (Deltek Cobra, EcoSys) can calculate earned schedule metrics. In practice, many UK construction teams calculate it in Excel using the PV and EV curves from their planning software. It's not difficult, the hard part is having reliable PV and EV data, not the arithmetic.</p></article></div>