Schedule Variance in Time: SV(t) Formula Explained

SV(t) is schedule variance measured in time units, weeks, months, whatever your reporting period uses. Unlike traditional Schedule Variance, 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 Earned Schedule 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.

SV(t) = ES - AT

Where ES = Earned Schedule and AT = Actual Time (current date).

This term is part of the earned value definitions glossary. For the parent metric that drives SV(t), see Earned Schedule.

The Formula

Where:

• ES (Earned Schedule) = the point in the baseline programme when the current cumulative EV was planned to be achieved
• AT (Actual Time) = where you actually are on the calendar

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.

Why SV(t) Exists: The Convergence Problem

Traditional SV (in pounds) has a fatal flaw. As the project completes, EV and PV both converge to BAC, 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.

SV(t) doesn't have this problem because it measures against the timeline, not the cost baseline.

 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?

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.

How to Calculate ES (and Therefore SV(t))

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.

 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.

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.

Worked Example: £25M Rail Depot at Month 12

When to Use SV(t) vs Traditional SV

Both have their place. Don't throw SV away, just know when each one is more useful.

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.

Common Mistakes

1. Only using SV(t) when the project is late. 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.
2. Confusing SV(t) with critical path float. 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.
3. Using SV(t) without checking the PV baseline quality. SV(t) is only as good as the PV curve it's derived from. If your Planned Value 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.

Frequently Asked Questions

Is SV(t) an official part of the ANSI 748 standard?

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.

Can SV(t) be calculated at control account level?

Yes, and it should be. Each control account has its own PV curve. The CAM can derive ES and SV(t) for their specific package. This is where it gets really useful, knowing the M&E package is 2.3 months behind while structural is 0.5 months ahead gives the project director actionable intelligence for resource allocation.

How does SV(t) handle programme re-baselines?

When the baseline changes, say, after an accepted compensation event 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.