Earned scheduleSPI(t)
Classic SPI always ends at 1.0.
A schedule index should get worse as a job gets later. The classic one does the opposite: it climbs back toward 1.0 in the final stretch no matter how far past the finish date the work runs. Earned schedule measures performance in days instead of dollars, so the index keeps telling the truth until the last activity closes.
What earned schedule measures
Earned schedule (ES) is the point in time at which the planned value curve equals the value earned to date. Comparing ES with actual time elapsed gives SPI(t) = ES ÷ AT and SV(t) = ES − AT, schedule performance measured in days rather than dollars, so the index stays honest all the way to the finish.
The idea is older than most people assume. Walt Lipke introduced earned schedule in 2003 as a fix for a flaw controllers had lived with for decades: the schedule half of earned value was measured in money, and money cannot tell you a date. Take the same three curves every earned value system already carries, planned value, earned value, and actual cost, and ask a different question of them. Not “how much value have we earned against plan?” but “which day of the plan have we actually reached?”
That day is ES. Everything else follows from the distance between it and today.
Why classic SPI stops telling the truth
Classic SPI is EV ÷ PV. Early in a job it works. But planned value is a curve that flattens toward the budget at completion and then stops, while earned value keeps climbing toward that same cap for as long as the work continues. Past the planned finish, the numerator catches the denominator whatever the calendar says, and the ratio closes to 1.0.
A job that ends four months late ends with a classic SPI of 1.00. The index fails in exactly the window a controller most needs it. SPI(t) has no ceiling to drift toward, because time keeps elapsing, so its denominator keeps growing until the last activity actually closes.
| Classic SPI | SPI(t) | |
|---|---|---|
| Formula | EV ÷ PV | ES ÷ AT |
| Units | Value: dollars or percent complete | Time: working days |
| What it reads | Value earned against value planned to date | Days of plan earned against days elapsed |
| Late in the job | Drifts to 1.0 as planned value flattens, however late the work is | Keeps falling while the delay grows; reaches 1.0 only on an on-time finish |
| Trust it when | Early in the job, and as a cost-forecast input | Any point in the job, and for every finish-date forecast |
How to find ES, SPI(t), and SV(t)
Start with earned value to date. Slide left along the planned value curve until you reach the period where cumulative PV equals that EV, then interpolate inside that period to the exact day. Counted in working days from the start, that is your earned schedule. It is a date the plan expected you to be at, expressed as a day number.
Actual time, AT, is how many working days have actually elapsed, in the same units the baseline was drawn in. SPI(t) is ES divided by AT. SV(t) is ES minus AT, and a negative result is days behind. Divide the planned duration by SPI(t) and you have an independent estimate of the finish: 180 ÷ 0.85 is about 212 working days, roughly 32 days late if the pace to date holds.
None of this needs new data. PV, EV, and the calendar are already in every earned value report. What changes is the axis you read them along.
Worked through in days
A job is planned at 180 working days. Today is day 120. The value earned so far is the value the plan expected to have earned by day 102, so ES is 102. SPI(t) is 102 ÷ 120 = 0.85. SV(t) is 102 − 120 = −18 working days, about three and a half weeks behind. Now read the same job in value: because this plan is front-loaded and its S-curve has already flattened, earned value sits only four points under planned value, and classic SPI reports 0.96. One number says the job is nearly on plan; the other says a month of schedule is gone. Against a target SPI(t) of 0.95, the second is the one to act on. Hold this pace and the finish lands near day 212, not 180: the 18-day gap is still widening.
The time projection
The curve is cumulative planned value across the 180-day baseline. The marker at day 120 rises to the value actually earned today, a few points short of the curve, which is all classic SPI can see. Then the sweep runs left along that earned value until it meets the plan, at day 102. The red bracket between the two is SV(t): the same shortfall, measured on the axis that finish dates live on.
How much, versus which
SPI(t) and SV(t) are whole-job numbers. They answer whether the project is behind and by how many days, with a confidence classic SPI cannot offer late in the work. They do not answer which activities put it there. An 18-day variance can come from one late structural pour or from a dozen small slips on finishes, and the recovery plan for those two cases looks nothing alike.
That second question belongs to the critical path. Read the two together: earned schedule sets the size of the problem in days, the critical path names the activities whose float has run out and whose recovery would actually move the finish. A controller who carries SPI(t) without a current critical path knows the score but not the play.
An illustration of the worked example as a period-by-period view: ES against AT, SPI(t) against its 0.95 target, and the trend from week 8 to week 24. Notice the direction. SPI(t) falls from 0.98 to 0.85 as the delay compounds, which is exactly the movement classic SPI would be hiding by drifting the other way.
Earned Schedule
Four ways the reading goes wrong
Once planned value starts to flatten, EV ÷ PV improves on its own with every period the job stays open. A schedule index that reads 0.96 in the final third of a late job is describing the shape of the S-curve, not the state of the work.
Earned schedule is found on the real planned value curve, interpolated inside the period where PV crosses today’s EV. Assuming a straight-line plan flattens the curve you are measuring against and puts ES on the wrong day.
ES comes from a curve drawn in the baseline’s time units. If AT is counted in calendar days against a working-day plan, weekends inflate the denominator and SPI(t) reads worse than the job really is.
SV(t) is a whole-job number. It says the project is 18 working days behind; it does not say which trade or hand-off caused it. Pointing it at a subcontractor skips the step the critical path exists for.
A schedule reported at the finish vs one read every period
Earned schedule is only a method. It is worth exactly as much as the freshness of the planned and earned figures it is read from, and a time index computed on last month’s progress describes a job that no longer exists.
- ·Progress is re-keyed into a spreadsheet weeks after the period closes
- ·Classic SPI is the only schedule index on the report, and it is drifting up
- ·The planned value curve and the actual dates live in different files
- ·The delay is discovered when the finish date is already gone
- ·POD reads the schedule, budget, and progress data your job already produces
- ·Earned value and classic cost and schedule performance stay current per project
- ·Planned against actual is visible every period, not reconstructed at closeout
- ·The figures a time-based reading starts from are never a month behind
POD reads the schedules, cost reports, and pay applications already moving through a job and keeps earned value and the classic performance indices current per project, so the planned and earned figures this method depends on are today’s. It pairs with earned value management, the critical path, and baseline discipline. Earned schedule is read across all three.
The project controls library
The pillar guide: where a time-based schedule index sits among cost, commitments, and earned value.
PV, EV, and AC, the three curves earned schedule is read from, and how CPI and classic SPI are derived.
SPI(t) says how many days behind; the critical path says which activities put you there.
Earned schedule only means something against a fixed planned value curve. Move the baseline and ES moves with it.
A job running at SPI(t) 0.85 burns overhead for extra weeks; the time index feeds the cost forecast.
Where the baseline dates, actual dates, and progress that earned schedule depends on are meant to live.
Earned schedule questions
What is earned schedule in construction?▾
Earned schedule (ES) is the point on the baseline timeline at which the planned value curve equals the value the job has actually earned to date. Instead of asking how many dollars of work are done against how many were planned, it asks which day of the plan the job has actually reached. Comparing that day with the days actually elapsed turns schedule performance into time units, which is what a finish date is written in.
How is SPI(t) calculated?▾
Find the earned schedule first: read the earned value to date, then locate the date on the planned value curve where the plan expected to have earned that same amount. That date, counted in working days from the start, is ES. Divide it by actual time elapsed, AT, in the same units. On the example in this guide, ES is 102 days and AT is 120 days, so SPI(t) = 102 / 120 = 0.85.
What is the difference between SPI and SPI(t)?▾
Classic SPI is earned value divided by planned value, a ratio of money or percent complete. SPI(t) is earned schedule divided by actual time, a ratio of days. The two agree early in a job and diverge late in it, because planned value flattens toward the budget at completion and drags classic SPI toward 1.0 no matter how late the work is. SPI(t) has no such ceiling and keeps reporting the delay until the last activity closes.
Why does classic SPI return to 1.0 on a late project?▾
Planned value is capped at the budget at completion once the baseline finish date passes, and earned value reaches that same cap the day the work is actually done. Past the planned finish, EV climbs toward a PV that is no longer moving, so the ratio closes to 1.0 even if the job runs months over. The index reads as recovered when the calendar says the opposite, which is exactly when a controller most needs a true reading.
What is SV(t) and how should I read it?▾
Schedule variance in time, SV(t), is earned schedule minus actual time: ES − AT. A negative result is the number of working days the job is behind the plan; a positive one is days ahead. It is the whole-job delay, not an activity-level one, so it tells you how far behind you are but not which activities put you there. For that, go to the critical path.
How does earned schedule relate to what POD tracks?▾
POD reads the schedule, budget, and progress data a job already produces and computes earned value and classic cost and schedule performance per project, kept current as you confirm each period. Earned schedule is a method a controller applies to those planned and earned figures against the calendar. This guide teaches that method so the numbers can be read in days as well as in dollars.
POD keeps planned and earned current
Start with the free schedule baseline log, then let POD read the schedules and progress reports your jobs already produce, so the figures behind every schedule index are this period’s, not last month’s.