Schedule Variance in Time: SV(t) Formula 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="#why-sv-t-exists-the-convergence-problem">Why SV(t) Exists: The Convergence Problem</a></li><li><a href="#how-to-calculate-es-and-therefore-sv-t">How to Calculate ES (and Therefore SV(t))</a></li><li><a href="#worked-example-25m-rail-depot-at-month-12">Worked Example: £25M Rail Depot at Month 12</a></li><li><a href="#when-to-use-sv-t-vs-traditional-sv">When to Use SV(t) vs Traditional SV</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>SV(t) is schedule variance measured in time units, weeks, months, whatever your reporting period uses. Unlike traditional <a href="/en/earned-value/definitions/schedule-variance">Schedule Variance</a>, which gives you a pound figure that converges to zero at project completion, SV(t) tells you exactly how many months ahead or behind you are and keeps telling you the truth right to the end. It's part of the <a href="/en/earned-value/definitions/earned-schedule">Earned Schedule</a> extension developed by Walt Lipke in 2003, and it's the single most useful schedule metric in the EVM toolkit once your project passes the halfway mark.</p><p><strong>SV(t) = ES - AT</strong></p><p>Where ES = Earned Schedule and AT = Actual Time (current date).</p><p>This term is part of the <a href="/en/earned-value/definitions">earned value definitions glossary</a>. For the parent metric that drives SV(t), see <a href="/en/earned-value/definitions/earned-schedule">Earned Schedule</a>.</p><h2 id="the-formula">The Formula</h2><div class="ge-formula-box ge-anim"><span class="ge-formula-label">Formula</span><code>SV(t) = ES - AT</code></div><p>Where:</p><ul><li><strong>ES (Earned Schedule)</strong> = the point in the baseline programme when the current cumulative EV was planned to be achieved</li><li><strong>AT (Actual Time)</strong> = where you actually are on the calendar</li></ul><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>SV(t) Result</th><th>Meaning</th></tr></thead><tbody><tr><td>SV(t) > 0</td><td>Ahead of programme by that many time units</td></tr><tr><td>SV(t) = 0</td><td>Exactly on programme</td></tr><tr><td>SV(t) < 0</td><td>Behind programme by that many time units</td></tr></tbody></table></div><p>The beauty of SV(t) is its directness. SV(t) = -1.7 months means you're 1.7 months behind. No conversion from pounds. No mental gymnastics. Every planner and project manager understands time.</p><h2 id="why-sv-t-exists-the-convergence-problem">Why SV(t) Exists: The Convergence Problem</h2><p>Traditional SV (in pounds) has a fatal flaw. As the project completes, <a href="/en/earned-value/definitions/earned-value">EV</a> and <a href="/en/earned-value/definitions/planned-value">PV</a> both converge to <a href="/en/earned-value/definitions/budget-at-completion">BAC</a>, so SV converges to zero. A project that finishes 8 months late shows SV = 0 at completion. That's worse than useless. It's actively misleading.</p><p>SV(t) doesn't have this problem because it measures against the timeline, not the cost baseline.</p><pre class="ge-ascii-diagram ge-anim"> SV vs SV(t) – THE CONVERGENCE DIFFERENCE ============================================= A project that finishes 4 months late: Traditional SV (pounds) SV(t) (months) ───────────────────── ───────────────────── SV SV(t) (£) (months) | | 0 ┤─╪───────────────╪── ← lies 0 ┤─╪ | ╪ ╪ at end | ╪ -1 ┤ ╪ ╪ -1 ┤ ╪ | ╪ ╪ | ╪ -2 ┤ ╪ ╪ -2 ┤ ╪────── | ╪ ╪ | ╪ -3 ┤ ╪╪ -3 ┤ ╪ | | ╪ -4 ┤ -4 ┤──────────────── ← truth | | at end └──────────────── Time └──────────────── Time Start Finish Start Finish SV says "everything's fine" SV(t) says "4 months late" at the end. At the end. WHICH ONE DO YOU WANT IN YOUR BOARD REPORT?</pre><p>I've presented both metrics side by side in programme board meetings. The moment the project director sees SV trending towards zero while SV(t) stays stubbornly negative, the penny drops. They never go back to using SV alone.</p><h2 id="how-to-calculate-es-and-therefore-sv-t">How to Calculate ES (and Therefore SV(t))</h2><p>SV(t) is simple: ES minus AT. But calculating ES requires a bit more work. You need to find the point on the PV curve where cumulative PV equals your current EV, then interpolate.</p><pre class="ge-ascii-diagram ge-anim"> DERIVING ES – STEP BY STEP ============================================= Given: Current month (AT) = 12 Current EV = £18,000,000 Baseline PV curve: Month │ Cumulative PV ──────┼──────────────── 8 │ £14,200,000 9 │ £15,800,000 10 │ £17,200,000 ← EV (£18M) falls between 11 │ £19,800,000 ← these two baseline months 12 │ £22,000,000 13 │ £24,000,000 ES = 10 + (EV - PV at month 10) / (PV at month 11 - PV at month 10) = 10 + (£18.0M - £17.2M) / (£19.8M - £17.2M) = 10 + £0.8M / £2.6M = 10 + 0.31 = 10.31 months SV(t) = ES - AT = 10.31 - 12.00 = -1.69 months ≈ -1.7 months behind programme Translation: We're at month 12, but our progress matches what the baseline planned for month 10.3. We're 1.7 months late.</pre><p>The interpolation assumes PV grows linearly between monthly points. It doesn't, really, there are peaks and troughs, but the approximation is accurate enough for project controls. On weekly reporting cycles, the interpolation becomes even tighter.</p><h2 id="worked-example-25m-rail-depot-at-month-12">Worked Example: £25M Rail Depot at Month 12</h2><span class="ge-worked-label">Worked Example</span><div class="ge-callout ge-anim"><p><strong>Scenario:</strong> A £25M NEC4 Option C rail depot refurbishment in Derby. The project has a 20-month programme. At the end of month 12 (December 2025), the project controls team runs the earned schedule analysis.</p><p><strong>Baseline PV data (from Accepted Programme):</strong></p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Month</th><th>Cumulative PV</th></tr></thead><tbody><tr><td>8</td><td>£10,400,000</td></tr><tr><td>9</td><td>£11,800,000</td></tr><tr><td>10</td><td>£13,200,000</td></tr><tr><td>11</td><td>£14,800,000</td></tr><tr><td>12</td><td>£16,500,000</td></tr><tr><td>14</td><td>£19,600,000</td></tr><tr><td>16</td><td>£22,000,000</td></tr><tr><td>20</td><td>£25,000,000 (BAC)</td></tr></tbody></table></div><p><strong>Month 12 progress:</strong></p><ul><li>EV (measured by <a href="/en/earned-value/definitions/weighted-milestones">weighted milestones</a>) = £13,600,000</li><li>AT = 12 months</li></ul><p><strong>Step 1: Find where EV falls on the PV curve</strong></p><ul><li>PV at month 10 = £13,200,000</li><li>PV at month 11 = £14,800,000</li><li>EV = £13,600,000 falls between months 10 and 11</li></ul><p><strong>Step 2: Interpolate</strong></p><ul><li>ES = 10 + (£13,600,000 - £13,200,000) / (£14,800,000 - £13,200,000)</li><li>ES = 10 + £400,000 / £1,600,000</li><li>ES = 10 + 0.25</li><li>ES = <strong>10.25 months</strong></li></ul><p><strong>Step 3: Calculate SV(t)</strong></p><ul><li>SV(t) = 10.25 - 12.00 = <strong>-1.75 months</strong></li></ul><p><strong>Comparison with traditional SV:</strong></p><ul><li>SV = EV - PV = £13,600,000 - £16,500,000 = -£2,900,000</li><li><a href="/en/earned-value/definitions/schedule-variance-percentage">SV%</a> = -17.6%</li></ul><p>The traditional SV says -£2.9M. Useful for cost-minded people. But the project director and planner want to know: how far behind in time? Answer: 1.75 months. That's roughly 7 weeks. With 8 months of programme remaining, is recovery possible? Only if the root cause is addressed and the remaining works can absorb a 22% acceleration.</p><p><strong>Time forecast:</strong></p><ul><li>SPI(t) = ES / AT = 10.25 / 12 = 0.854</li><li><a href="/en/earned-value/definitions/time-estimate-at-completion">EAC(t)</a> = planned duration / SPI(t) = 20 / 0.854 = <strong>23.4 months</strong></li><li>Predicted overrun: 3.4 months beyond the original 20-month programme</li></ul></div><h2 id="when-to-use-sv-t-vs-traditional-sv">When to Use SV(t) vs Traditional SV</h2><p>Both have their place. Don't throw SV away, just know when each one is more useful.</p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Metric</th><th>Best Used For</th><th>Limitation</th></tr></thead><tbody><tr><td><strong>SV (£)</strong></td><td>Early-stage reporting (0-50% complete). Cost-focused stakeholders.</td><td>Converges to zero at completion</td></tr><tr><td><strong>SV%</strong></td><td>Cross-project comparison in programme dashboards</td><td>Same convergence problem as SV</td></tr><tr><td><strong>SV(t)</strong></td><td>Mid to late-stage reporting. Time-focused stakeholders. Forecasting completion date</td><td>Requires interpolation from PV curve. Slightly more complex to calculate</td></tr></tbody></table></div><p>I use SV in the first half and SV(t) from month 6 onwards on most projects. On shorter contracts (under 8 months), I use SV(t) from day one because convergence kicks in quickly.</p><h2 id="common-mistakes">Common Mistakes</h2><ol><li><strong>Only using SV(t) when the project is late.</strong> SV(t) works in both directions. A positive SV(t) tells you how far ahead you are in time. This is valuable for resource planning, if you're 3 weeks ahead, you might be able to release plant or labour to another project early.</li><li><strong>Confusing SV(t) with critical path float.</strong> SV(t) measures overall programme performance against the baseline. It doesn't tell you about the critical path specifically. A project can have SV(t) = +2 weeks (ahead overall) while the critical path has zero float. Always cross-check SV(t) against the critical path analysis.</li><li><strong>Using SV(t) without checking the PV baseline quality.</strong> SV(t) is only as good as the PV curve it's derived from. If your <a href="/en/earned-value/definitions/planned-value">Planned Value</a> baseline was poorly cost-loaded or the programme wasn't realistic to start with, SV(t) will give you a precise answer to the wrong question.</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>Is SV(t) an official part of the ANSI 748 standard?</h3><p>No. Earned Schedule was developed by Walt Lipke in 2003 as an extension to traditional EVM. It isn't part of the EIA-748 standard, which is where the original SV formula lives. But it's widely adopted in practice. The UK Ministry of Defence and Network Rail both use earned schedule metrics in their project reporting. It's become a de facto standard even without formal accreditation.</p><h3>Can SV(t) be calculated at control account level?</h3><p>Yes, and it should be. Each <a href="/en/earned-value/definitions/control-account">control account</a> has its own PV curve. The <a href="/en/earned-value/definitions/control-account-manager">CAM</a> can derive ES and SV(t) for their specific package. This is where it gets really useful, knowing the M&amp;E package is 2.3 months behind while structural is 0.5 months ahead gives the project director actionable intelligence for resource allocation.</p><h3>How does SV(t) handle programme re-baselines?</h3><p>When the baseline changes, say, after an accepted <a href="/en/earned-value/definitions/compensation-event">compensation event</a> adjusts the Accepted Programme, the PV curve shifts. SV(t) should be recalculated against the new baseline. Some teams maintain both the original baseline SV(t) and the current baseline SV(t) for transparency. That's good practice, especially on NEC4 where the Project Manager may query why the schedule appears healthier after a re-baseline.</p></article></div>