TSPI: To-Complete 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="#the-diagram">The Diagram</a></li><li><a href="#why-tspi-matters">Why TSPI Matters</a></li><li><a href="#worked-example-26m-hospital-extension">Worked Example: £26M Hospital Extension</a></li><li><a href="#tspi-vs-tcpi">TSPI vs TCPI</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>The To-Complete Schedule Performance Index (TSPI) tells you the schedule efficiency you need to achieve on the remaining work to finish on time. Think of it as the schedule equivalent of <a href="/en/earned-value/definitions/to-complete-performance-index">TCPI</a>. TCPI asks "how hard do you need to work to hit budget?" TSPI asks "how fast do you need to work to hit the completion date?" When TSPI says 1.58, it's telling you something simple: you can't recover this programme. Stop planning recovery workshops and start planning the conversation with the client.</p><p>TSPI is part of the <a href="/en/earned-value/definitions">earned value definitions glossary</a>. For the full schedule performance framework, see the <a href="/en/earned-value/cpi-spi">CPI and SPI formula page</a>.</p><h2 id="the-formula">The Formula</h2><div class="ge-formula-box ge-anim"><span class="ge-formula-label">Formula</span><code>TSPI = (PD - ES) / (PD - AT)</code></div><p>Where:</p><ul><li><strong>PD</strong> = Planned Duration (total baseline programme duration)</li><li><strong>ES</strong> = Earned Schedule (the point in time on the baseline where your current earned value would have been achieved)</li><li><strong>AT</strong> = Actual Time elapsed</li></ul><p>In plain English: the remaining planned work (in time) divided by the remaining available time. If there's more work left than time to do it in, TSPI exceeds 1.0.</p><h2 id="the-diagram">The Diagram</h2><pre class="ge-ascii-diagram ge-anim">TSPI: Remaining Work vs Remaining Time ======================================== Baseline Programme (PD = 24 months): |═══════════════════════════════════| 0 12 24 Start Planned Finish At Month 18 (AT = 18), Earned Schedule = 14.5: |████████████████████░░░░░░░░░░░░░░| 0 14.5 18 24 Start ES AT PD Remaining scheduled work: PD - ES = 24 - 14.5 = 9.5 months of work Remaining calendar time: PD - AT = 24 - 18 = 6.0 months available TSPI = 9.5 / 6.0 = 1.583 ┌─────────────────────────────────────────────┐ │ TSPI Feasibility Scale │ │ │ │ 0.80 ──── Comfortable. Margin for error. │ │ 0.90 ──── Healthy. On track. │ │ 1.00 ──── Exact. No room for slippage. │ │ 1.10 ──── Tight. Acceleration likely. │ │ 1.20 ──── Very difficult. Major changes. │ │ 1.30 ──── Near impossible. │ │ 1.50+──── Recovery is fantasy. ← YOU ARE │ │ HERE │ └─────────────────────────────────────────────┘</pre><p>At 1.58, the team would need to deliver schedule progress 58% faster than they've been doing. On a project where SPI(t) has been sitting at 0.81 for four months, that's not happening.</p><h2 id="why-tspi-matters">Why TSPI Matters</h2><p>TSPI strips away the optimism. Every delayed project has a recovery programme. Every recovery programme shows the team finishing on time. But TSPI does the arithmetic that the recovery programme conveniently ignores.</p><p>I sat in a progress meeting last year where the contractor presented a recovery programme showing completion by the contractual date. Beautiful bar chart. Detailed resource histogram. Convincing narrative. Then someone asked: "What SPI(t) does this recovery programme require?" Answer: 1.45. The current SPI(t) was 0.82. That recovery programme needed a 77% improvement in schedule efficiency.</p><p>Nobody had done that calculation until that moment. The recovery programme was immediately sent back for revision with a more realistic completion date. TSPI would have flagged this in five seconds.</p><h2 id="worked-example-26m-hospital-extension">Worked Example: £26M Hospital Extension</h2><span class="ge-worked-label">Worked Example</span><div class="ge-callout ge-anim"><p><strong>Scenario:</strong> A £26M NEC4 Option A hospital extension. Planned duration is 24 months, starting March 2025. At the end of month 18 (August 2026), the project is behind programme.</p><p><strong>Progress data:</strong></p><ul><li>PD = 24 months</li><li>AT = 18 months</li><li><a href="/en/earned-value/definitions/earned-value">EV</a> = £15.6M (60% complete)</li><li>The baseline programme shows that £15.6M of <a href="/en/earned-value/definitions/planned-value">PV</a> was planned to be earned at month 14.5</li><li>Therefore ES = 14.5 months</li></ul><p><strong>TSPI</strong> = (24 - 14.5) / (24 - 18) = 9.5 / 6.0 = <strong>1.583</strong></p><p>The project needs to deliver schedule progress at 158% of historical rate for the remaining 6 months. Current SPI(t) = 14.5 / 18 = 0.806.</p><p><strong>What this means commercially:</strong></p><ul><li>Contractual completion: February 2027 (month 24)</li><li><a href="/en/earned-value/definitions/time-estimate-at-completion">TEAC</a>: 24 / 0.806 = 29.8 months = August 2027</li><li>Delay exposure: 5.8 months</li><li>LDs at £25,000/week: approximately £628,000</li></ul><p>The commercial manager presents three options:</p><ul><li><strong>Accept the delay:</strong> Forecast 5.8 months late, negotiate LD position</li><li><strong>Partial acceleration:</strong> Double weekend shifts, target TSPI of 1.20 (still very aggressive), reduce delay to approximately 2 months</li><li><strong>Full acceleration:</strong> Additional subcontractor gang plus overtime, cost estimate £480,000, target TSPI of 1.05 (achievable but tight)</li></ul><p>The LD exposure of £628K makes Option 3 worth exploring. But TSPI told the team that getting back to the original date without spending money was impossible. That clarity saved weeks of arguing about whether the programme could recover "naturally."</p></div><h2 id="tspi-vs-tcpi">TSPI vs TCPI</h2><p>These two metrics are twins. Same concept, different dimensions.</p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Metric</th><th>Question</th><th>Formula</th><th>Dimension</th></tr></thead><tbody><tr><td><a href="/en/earned-value/definitions/to-complete-performance-index">TCPI</a></td><td>How efficiently must I spend to hit budget?</td><td>(BAC - EV) / (BAC - AC)</td><td>Cost</td></tr><tr><td><strong>TSPI</strong></td><td>How efficiently must I progress to finish on time?</td><td>(PD - ES) / (PD - AT)</td><td>Time</td></tr></tbody></table></div><p>When both TCPI and TSPI exceed 1.20 simultaneously, the project is in serious trouble on both fronts. That's the point where the conversation shifts from recovery to re-baselining.</p><h2 id="common-mistakes">Common Mistakes</h2><ol><li><strong>Calculating TSPI with cost-based SPI.</strong> TSPI uses earned schedule (ES), not cost-based EV/PV ratios. Earned schedule translates your progress into time units. If you don't have earned schedule data, you can't calculate TSPI properly. It's worth the setup effort.</li><li><strong>Ignoring TSPI because "we've got a recovery programme."</strong> The recovery programme is an aspiration. TSPI is the reality check on that aspiration. If TSPI says 1.45 and the recovery programme implies the team can achieve it, ask for evidence. What has changed that will produce a 45% improvement?</li><li><strong>Not translating TSPI into money.</strong> A TSPI of 1.30 on its own is abstract. Translate it: "We need to deliver progress 30% faster. We can't. We're looking at X weeks of delay at £Y per week in LDs." That's the language the project board understands.</li><li><strong>Forgetting that TSPI changes over time.</strong> Early in a project, TSPI is often close to 1.0 even with minor delays because there's plenty of remaining time. As the project progresses, the denominator (PD - AT) shrinks and TSPI becomes increasingly sensitive. A small slip at month 20 of a 24-month project has a much bigger TSPI impact than the same slip at month 6.</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 TSPI value means the schedule is unrecoverable?</h3><p>There's no absolute threshold because it depends on the project and the remaining work. But in practice, TSPI above 1.30 is extremely difficult to achieve. Above 1.50 is effectively impossible without fundamental changes to scope, method, or resources. On one project I worked on, a TSPI of 1.35 was achievable because the remaining work was simpler than the early phases. Context matters, but default to scepticism above 1.20.</p><h3>Can TSPI be used alongside programme analysis?</h3><p>It should be. TSPI gives you the headline number. Programme analysis tells you which activities are driving the delay and where acceleration would be most effective. They're complementary tools. Use TSPI to trigger the conversation, then use the programme to find the solution.</p><h3>How often should TSPI be calculated?</h3><p>Monthly, aligned with your earned value reporting cycle. On projects approaching their completion date with schedule pressure, fortnightly is better. The closer you get to PD, the more volatile TSPI becomes.</p></article></div>