What Is an Over Target Schedule (OTS) in EVM?

<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="#ots-vs-extension-of-time-theyre-not-the-same-thing">OTS vs Extension of Time: They're Not the Same Thing</a></li><li><a href="#when-ots-becomes-necessary">When OTS Becomes Necessary</a></li><li><a href="#worked-example-ots-on-a-24-month-programme">Worked Example: OTS on a 24-Month Programme</a></li><li><a href="#the-relationship-between-ots-and-otb">The Relationship Between OTS and OTB</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>An Over Target Schedule (OTS) is a revised schedule baseline established when the original completion date is acknowledged as unachievable. It's the time equivalent of an <a href="/en/earned-value/definitions/over-target-baseline">Over Target Baseline (OTB)</a>, except instead of resetting cost metrics, you're resetting schedule metrics. The old programme dates are moved out, the <a href="/en/earned-value/definitions/schedule-performance-index">SPI</a> resets toward 1.00, and the project starts measuring schedule performance against a revised, more realistic programme. Like OTB, it's a last resort. Unlike OTB, it's less well understood, and often confused with contractual extensions of time. </p><p>This term is part of the <a href="/en/earned-value/definitions">earned value definitions glossary</a>. For the cost-side equivalent, see <a href="/en/earned-value/definitions/over-target-baseline">Over Target Baseline (OTB)</a>. For the schedule metrics that trigger the OTS discussion, see <a href="/en/earned-value/cpi-spi">CPI and SPI</a>. </p><h2 id="ots-vs-extension-of-time-theyre-not-the-same-thing">OTS vs Extension of Time: They're Not the Same Thing</h2><p>This is the most important distinction and the one that trips up nearly every commercial team I've worked with. </p><p><strong>Extension of Time (EOT)</strong> is a contractual mechanism. On NEC4, it adjusts the Completion Date through a compensation event under clause 63.5. It changes your contractual entitlement. It affects delay damages. It's a legal position. </p><p><strong>Over Target Schedule</strong> is a management tool. It adjusts the internal EVM schedule baseline so the metrics produce useful data. It has zero contractual effect. The client doesn't need to know about it. </p><p>You can have an EOT without an OTS (you got a contractual extension but your EVM schedule was already reflecting that delay). You can have an OTS without an EOT (the delay is your fault, no contractual entitlement, but you still need realistic schedule metrics). And you can have both simultaneously. </p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Aspect</th><th>Extension of Time (EOT)</th><th>Over Target Schedule (OTS)</th></tr></thead><tbody><tr><td><strong>Nature</strong></td><td>Contractual</td><td>Management / governance</td></tr><tr><td><strong>Authority</strong></td><td>Project Manager (NEC4 clause 63.5)</td><td>Project director / controls lead</td></tr><tr><td><strong>Effect</strong></td><td>Moves the Completion Date</td><td>Resets SPI and schedule metrics</td></tr><tr><td><strong>Delay damages</strong></td><td>Yes, removes LD exposure</td><td>No, LDs still calculated against contractual date</td></tr><tr><td><strong>Client visibility</strong></td><td>Always</td><td>Only on client-mandated EVM</td></tr><tr><td><strong>Trigger</strong></td><td>Compensation event, clause 60.1</td><td>Persistent SPI below threshold</td></tr></tbody></table></div><h2 id="when-ots-becomes-necessary">When OTS Becomes Necessary</h2><p>The trigger pattern looks like this: </p><pre class="ge-ascii-diagram ge-anim"> SPI(t) TREND – The OTS Trigger Point ====================================== SPI(t) 1.10│ │ ● 1.05│ ● │ ● 1.00│────────●──────────────────────── Target (on programme) │ ● 0.95│ ● │ ● ● 0.90│ ● ● │ ● 0.85│ ● │ ● ● 0.80│ ● ← SPI(t) = 0.78 │ 5 months below 0.85 0.75│ TCPI(t) = 1.38 │ ← OTS discussion now 0.70│ └──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬── M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 Original programme: 24 months At month 12: SPI(t) = 0.78 Months of earned schedule: 12 x 0.78 = 9.4 months Implied completion: 24 / 0.78 = 30.8 months Overrun: ~7 months After OTS (revised to 30-month programme): New SPI(t) baseline recalculated Schedule metrics become useful again for managing remaining work </pre><p>The indicators that an OTS discussion is overdue: </p><ul><li><strong>SPI(t) below 0.85 for 3+ consecutive reporting periods</strong>: Like CPI, SPI rarely recovers once it drops this far</li><li><strong>Schedule TCPI above 1.25</strong>: Meaning you'd need to work 25% faster than planned for the remaining duration. On construction, that basically means double-shifting, which brings its own cost problems</li><li><strong>Critical path delay exceeding 15% of remaining duration</strong>: At that point, the programme logic is broken</li><li><strong>Earned Schedule showing completion 20%+ beyond the baseline</strong>: The maths is telling you the programme is fiction</li></ul><h2 id="worked-example-ots-on-a-24-month-programme">Worked Example: OTS on a 24-Month Programme</h2><span class="ge-worked-label">Worked Example</span><div class="ge-callout ge-anim"><p><strong>Scenario:</strong> A £45M NEC4 Option C rail depot refurbishment, planned duration 24 months. At month 12, the project is significantly behind programme due to asbestos discoveries in the existing building and delayed possession handovers.</p><br><p><strong>Month 12 schedule metrics:</strong></p><br><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Metric</th><th>Value</th></tr></thead><tbody><tr><td>Original programme duration</td><td>24 months</td></tr><tr><td>SPI(t) at month 12</td><td>0.78</td></tr><tr><td>Earned Schedule (ES)</td><td>12 x 0.78 = 9.4 months of work earned</td></tr><tr><td>Schedule variance (time)</td><td>9.4 - 12 = -2.6 months behind</td></tr><tr><td>Projected completion (SPI method)</td><td>24 / 0.78 = 30.8 months</td></tr><tr><td>Schedule TCPI</td><td>Remaining work / remaining time = essentially unachievable at original pace</td></tr></tbody></table></div><br><p><strong>Contractual position:</strong></p><p>Two compensation events have been implemented:</p><p>- CE-003 (asbestos removal): +14 weeks to Completion Date</p><p>- CE-008 (late possession): +4 weeks to Completion Date</p><p>- New contractual Completion Date: original + 18 weeks = <strong>28.5 months</strong></p><br><p><strong>But there's a gap.</strong> The contractual Completion Date is 28.5 months. The SPI-based projection is 30.8 months. That 2.3-month gap is contractor delay. Not covered by any EOT. The contractor is exposed to delay damages on those 2.3 months.</p><br><p><strong>The OTS decision:</strong></p><br><p>The project director decides to implement an OTS to give the team a realistic schedule baseline to manage against. The options:</p><br><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Option</th><th>New Baseline</th><th>Rationale</th></tr></thead><tbody><tr><td>A: Reset to contractual date</td><td>28.5 months</td><td>Aligns with EOT but still shows contractor delay as negative SPI</td></tr><tr><td>B: Reset to realistic projection</td><td>30 months</td><td>Honest assessment, but acknowledges contractor LD exposure</td></tr><tr><td>C: Reset to recovery programme</td><td>29 months</td><td>Includes acceleration measures (weekend working, additional crews)</td></tr></tbody></table></div><br><p><strong>Decision: Option C, 29-month recovery programme.</strong></p><br><p>The team agrees a realistic but challenging target. The 29-month programme assumes:</p><p>- Weekend working on structural steel for 8 weeks (additional cost: £180K)</p><p>- Second M&amp;E crew mobilised for containment zones (additional cost: £240K)</p><p>- Re-sequenced fit-out to start in completed zones while asbestos work continues in others</p><br><p><strong>Post-OTS metrics (month 12):</strong></p><br><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Metric</th><th>Pre-OTS</th><th>Post-OTS</th></tr></thead><tbody><tr><td>Programme duration</td><td>24 months</td><td>29 months</td></tr><tr><td>SPI(t)</td><td>0.78</td><td>recalculated against new baseline</td></tr><tr><td>Projected completion</td><td>30.8 months</td><td>29 months (if team hits new targets)</td></tr><tr><td>LD exposure</td><td>6.8 months x LD rate</td><td>0.5 months x LD rate (best case)</td></tr></tbody></table></div><br><p><strong>Important:</strong> The contractual Completion Date remains 28.5 months. The OTS doesn't change that. The contractor is still exposed to delay damages for any completion beyond 28.5 months. The OTS just means the EVM system now measures schedule performance against a realistic internal target rather than a fiction.</p></div><h2 id="the-relationship-between-ots-and-otb">The Relationship Between OTS and OTB</h2><p>OTS and OTB are cousins. They often travel together because projects that are behind schedule are usually over budget too, acceleration costs money, extended preliminaries cost money, and disrupted productivity costs money. </p><p>But they're separate decisions. You can implement one without the other: </p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Scenario</th><th>OTB?</th><th>OTS?</th></tr></thead><tbody><tr><td>Project is over budget but on programme (e.g., material price escalation)</td><td>Yes</td><td>No</td></tr><tr><td>Project is behind programme but on budget (e.g., weather delays absorbed by float)</td><td>No</td><td>Yes</td></tr><tr><td>Project is both over budget and behind programme (the usual case)</td><td>Yes</td><td>Yes</td></tr><tr><td>Project is on budget and on programme</td><td>No</td><td>No</td></tr></tbody></table></div><p>When you implement both, do them simultaneously. Resetting cost metrics in month 12 and schedule metrics in month 15 creates a confusing baseline that nobody can interpret cleanly. </p><h2 id="common-mistakes">Common Mistakes</h2><ol><li><strong>Confusing OTS with EOT</strong>: This is the big one. I've seen commercial managers argue in project reviews that "we've done an OTS so the delay damages don't apply." Wrong. OTS is internal governance. EOT is contractual. They operate in completely different domains. If you need protection from delay damages, you need an EOT through the contract mechanism, not an internal schedule reset.</li><li><strong>Setting the OTS too optimistically</strong>, The whole point of OTS is to restore realism. If the honest projection is 31 months and you set the OTS at 28 months to look better, you'll breach the new baseline within two reporting periods and be right back where you started. Set the OTS to a realistic but challenging target, not a fantasy.</li><li><strong>Not re-sequencing the programme</strong>: OTS isn't just pushing the end date out. It should involve re-logic of the remaining programme. Which activities can run in parallel? What predecessor constraints can be relaxed? Which subcontractors need to accelerate? Simply adding months to the end date without re-planning the logic is a date change, not a genuine OTS.</li><li><strong>Ignoring the cost impact</strong>: Schedule recovery almost always costs money. Additional shifts, weekend working, extra supervision, acceleration premiums. If you implement an OTS without updating the <a href="/en/earned-value/definitions/estimate-at-completion">EAC</a>, you've fixed the schedule baseline but broken the cost forecast. The two must be coordinated.</li><li><strong>No lessons learned on why the programme failed</strong>: Before resetting, answer the question: why did the original programme fail? Was it over-optimistic at tender? Were the possession dates unrealistic? Did the team fail to manage the critical path? Without understanding the cause, the new programme will suffer the same fate.</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>Does OTS require client approval on NEC4?</h3><p>Not for internal contractor EVM. The OTS is a management tool and doesn't appear in the contract. However, on NEC4 contracts with Works Information that mandates EVM reporting to the Project Manager, you'd typically inform the PM that the internal management schedule has been revised. On client-side EVM (where the client runs their own earned value system), OTS would require client programme team approval. </p><h3>Can you do OTS without OTB?</h3><p>Yes. If the project is behind schedule but still within budget, perhaps because the programme had enough float to absorb some delays without impacting costs significantly, or because cost savings elsewhere offset the extended prelims, then OTS alone is appropriate. In practice though, schedule delay usually brings cost overrun. It's worth checking whether <a href="/en/earned-value/definitions/over-target-baseline">OTB</a> is also needed. </p><h3>How does OTS affect the SPI calculation?</h3><p>SPI = <a href="/en/earned-value/definitions/earned-value">EV</a> / <a href="/en/earned-value/definitions/planned-value">PV</a>. After OTS, the PV curve is redistributed across the new, longer programme duration. The PV at any given month is lower than it was under the original baseline (because the same total budget is spread over more months). This means the SPI improves. Not because you've done more work, but because the baseline expectation at each measurement point is lower. That's the entire purpose: giving you a baseline you can realistically manage against. </p><h3>What's the difference between OTS and schedule re-baselining?</h3><p>Same distinction as OTB vs general re-baselining. You can re-baseline a schedule without going "over target", for example, re-sequencing activities while keeping the same completion date. That's a baseline change. OTS specifically means the completion date has moved beyond the original target because the original was unachievable. Every OTS is a re-baseline, but not every re-baseline is an OTS. </p></article></div>