Schedule Performance Index (SPI): Formula, Interpretation and Examples

What is the schedule performance index?

The schedule performance index is an earned value management metric that compares the budgeted value of work completed with the budgeted value of work that should have been completed by a given date. It answers a narrow but important question: how much of the planned progress has the project actually earned?

SPI = EV ÷ PV

• EV (Earned Value) is the budgeted cost of the work actually completed by the measurement date.
• PV (Planned Value) is the budgeted cost of the work that was scheduled to be completed by that same date.

Both values are expressed in money, which makes the ratio dimensionless. An SPI of 0.80 means the project has earned 80% of the value it planned to earn. It does not mean the project is 80% complete, and it does not mean it is 20% late. Those are different calculations, and confusing them is the most common source of bad decisions.

> Important note: SPI is a cost-based schedule indicator. If your budget is uneven across phases, SPI can move for reasons that have nothing to do with speed. Always read it against the schedule baseline that produced the planned value.

How do you calculate SPI step by step?

The arithmetic is one division. The discipline is in defining earned value and planned value consistently, at the same cut-off date, against the same baseline.

Step 1: Approve and freeze the schedule baseline

SPI only means something relative to a baseline. Take the approved schedule and cost-loaded plan, including task durations, dependencies, and the budget assigned to each work package. If the baseline changes, record the change and the effective date before calculating the next period. Comparing new progress to an old baseline is not measurement; it is archaeology.

Step 2: Calculate planned value for the cut-off date

PV is the sum of budgets for all work scheduled to be complete by the measurement date. On a $600,000 project with a straight twelve-month spend curve, PV at the end of month 6 is $300,000. On a project with a front-loaded design phase, PV might be $420,000 at the same point. The shape of the curve matters.

Step 3: Calculate earned value with a consistent rule

EV is the sum of budgets for work that is genuinely complete. Use a written rule and apply it everywhere:

• 0/100: the task earns its full budget only when finished. Good for short, binary tasks.
• 50/50: the task earns half at start and half at completion. Simple, but optimistic at the start.
• Percent complete: only where a physical or verifiable measure exists, such as kilometers installed, test cases passed, or invoices processed.

The rule must be stable across periods. If a team switches from 0/100 to percent complete halfway through, SPI will jump for reasons that have nothing to do with performance.

Step 4: Divide and date-stamp the result

SPI = EV ÷ PV. Record the measurement date, the baseline version, and the top two contributors to any variance. A ratio without that context cannot be defended when someone challenges it three weeks later.

Worked example: a twelve-month ERP rollout

A mid-sized manufacturer is rolling out a new ERP system. The approved budget is $600,000 over twelve months, with roughly $50,000 of planned value per month. At the end of month 6:

The project has earned 80% of the value it planned to earn by month six. If the current rate continues, the twelve-month schedule behaves like a fifteen-month schedule: 12 ÷ 0.80 = 15 months. That is a three-month slip, and it is the number the sponsor actually cares about.

But look closer before you announce it. Suppose $45,000 of the missing earned value sits in a training workstream with four weeks of float, while the critical-path data migration is fully on time. The finish date may not move at all. Suppose instead the missing value is in the data migration itself. The three-month slip is real and probably understated, because late critical-path work tends to cascade.

How do you interpret an SPI result?

The scale is simple: 1.00 is on plan, above 1.00 is ahead, below 1.00 is behind. The judgment is not.

Three rules make interpretation more reliable.

Read the trend, not the snapshot. A single period at 0.96 after five periods at 1.01 is noise. Five periods of decline is a pattern. Patterns deserve a written cause, not a shrug.

Check the critical path before you forecast. SPI is calculated across all work. A project can be behind on paper while the finish date is safe, or on plan on paper while the critical path is quietly slipping. Pair SPI with the critical path method and the float on the delayed tasks.

Do not compare SPI across unrelated projects. A 0.90 on a repetitive manufacturing line and a 0.90 on a first-of-its-kind construction project describe very different levels of control. Compare a project with its own baseline and its own trend.

What is the difference between SPI and schedule variance?

Schedule variance is an amount; SPI is a ratio. SV = EV − PV, so in the ERP example SV is −$60,000. SPI = EV ÷ PV, which is 0.80. SV tells you how much budgeted value is missing. SPI tells you how large that gap is relative to the plan, which makes it easier to compare performance across phases or projects of different sizes.

Neither measure tells you days. A $60,000 schedule variance on a $600,000 project at month six could mean two days late or two months late, depending on which work is missing and where it sits in the network. That is why serious schedule analysis uses duration-based methods alongside earned value.

Why does SPI converge to 1.00 at the end?

This is SPI’s most important structural flaw. At project completion, all planned value has been earned, so EV equals PV and SPI returns to 1.00. A project that finishes six months late will still show an SPI of 1.00 on the day it closes. The metric forgets the delay precisely when the delay has become permanent.

The problem is worse in the final third of a project. As remaining work shrinks, EV approaches PV regardless of how late the team is. Managers who rely only on SPI often report improving schedule health while the finish date keeps moving.

The earned schedule fix

Earned schedule (ES) converts earned value into time. The idea is simple: find the point on the planned value curve where the current EV should have been earned, and compare that date with today.

• ES = the time at which PV equals the current EV.
• SPI-t = ES ÷ Actual Time (AT).
• SV-t = ES − AT, expressed in days, weeks, or months.

In the ERP example, EV is $240,000. At $50,000 of planned value per month, that corresponds to month 4.8. At month 6, SPI-t = 4.8 ÷ 6 = 0.80. Same ratio here because the plan is linear, but now the unit is time, and it stays meaningful near the end of the project.

Forecast duration with earned schedule:

EAC(t) = AT + (Planned Duration − ES) ÷ SPI-t

For the ERP: 6 + (12 − 4.8) ÷ 0.80 = 15 months. The forecast matches the simple SPI method in this case, but it will not collapse to “on time” as the project closes. That property alone makes SPI-t worth the extra spreadsheet column on long projects.

What does SPI miss?

SPI is a useful instrument with a narrow field of view. These are the blind spots that cause the most damage.

Critical path and float. SPI treats a dollar of earned value on a non-critical task the same as a dollar on the critical path. It has no concept of dependencies or slack. A project can earn plenty of value in parallel workstreams while the one sequence that determines the finish date stalls.

Quality and rework. A task can be marked complete, earn its value, and fail acceptance two weeks later. SPI records the earn; it does not record the rework that follows. Pair it with defect and acceptance data.

Scope changes. If approved changes are not loaded into the baseline, SPI compares new work with an old plan. The ratio may look stable while the real workload has grown 20%.

Level-of-effort tasks. Project management, coordination, and support activities often earn value simply by consuming time. That inflates EV and flatters SPI without delivering anything a customer would pay for.

Resource loading. SPI says nothing about whether the team has the capacity to recover. A 0.80 SPI with everyone already at 110% utilization is a different problem from the same SPI with two idle contractors.

Forecast realism. SPI assumes the current rate continues. Projects rarely move at a constant rate. The last 20% of work often takes longer than the first 80%, especially in integration, testing, and handover.

> Practical tip: Add a “schedule driver” line to every SPI report: “SPI fell from 0.93 to 0.80 because the data migration vendor delivered the extraction script nine days late; 60% of the variance sits on the critical path.” That single sentence turns a metric into a decision.

How do you forecast the finish date?

Three methods are useful, in increasing order of rigor.

1. SPI-based duration forecast. Planned duration ÷ SPI. Simple, fast, and directionally useful in the middle of a project. It assumes a linear plan and a constant performance rate, so treat it as a first estimate, not a commitment.

2. Earned schedule forecast. EAC(t) = AT + (PD − ES) ÷ SPI-t. Better near the end of the project and more honest about time. It still assumes the remaining work will be performed at the current time efficiency.

3. Schedule network reforecast. Update remaining durations and dependencies in the schedule, then recalculate the critical path. This is the most reliable method because it accounts for float, parallelism, and resource constraints. It is also the most work, which is why teams often skip it until the forecast becomes a crisis.

A practical cadence: use the SPI forecast for the weekly dashboard, the earned schedule forecast for the monthly report, and a full network reforecast whenever SPI leaves its agreed band for two consecutive periods or a critical-path milestone slips.

What should you do when SPI is below 1?

The instinct is to add people or hours. Both can work, and both have costs that show up in CPI and in morale. The table below compares the common recovery options.

Two rules keep recovery honest. First, protect the critical path; recovering three weeks on a task with four weeks of float changes nothing. Second, Forecast the cost of recovery before you approve it. Crashing a project from SPI 0.80 back to 1.00 usually costs more than the original budget allowed, and the sponsor should see that number before saying yes.

If the project is already late and the deadline is fixed, the conversation shifts from “how do we recover” to “what do we cut”. That is a scope decision, not a scheduling one, and it belongs with the sponsor.

How often should you measure SPI?

Match the cadence to the pace of the work and the cost of collecting clean data. Weekly suits software delivery, marketing launches, and any project where a week of drift is expensive. Monthly suits construction, engineering, and enterprise programs where earned value rules are formal and cost collection runs on an accounting cycle.

Whatever the cadence, keep three things constant: the cut-off date, the baseline version, and the earned value rule. Most “SPI surprises” are not performance changes at all. They are inconsistent measurement.

Set an operating band during planning. A stable, repetitive project might use 0.97–1.03. A project with weather, regulatory approvals, or new technology might use 0.90–1.10. Define what happens when the band is breached: who investigates, who approves recovery spending, and when the sponsor is informed. A threshold without a response path is just a number with a color.

Does SPI work for agile and hybrid projects?

SPI can work, but it needs translation. Agile teams plan in sprints and measure progress in completed increments, not in cost-loaded tasks. Two adaptations are common.

The first maps story points to budget and treats completed points as earned value. It is workable if the mapping is stable and the team does not re-estimate mid-flight. The risk is false precision: velocity is not a currency, and converting it into one can obscure the real constraint.

The second uses earned schedule at the release level. Plan the release in weeks, measure completed scope against the release plan, and calculate SPI-t from the planned value curve. This avoids sprint-level noise and gives leadership a time-based view that matches how they think about launches.

Hybrid projects usually work best with a phase-level SPI. Use earned value for the plan-driven phases, such as procurement, construction, and compliance, and use flow metrics such as cycle time and throughput for the discovery and delivery phases. Trying to force one metric across both worlds creates arguments about definitions instead of decisions about the project.

Common SPI mistakes to avoid

• Using SPI as a percent-complete measure. SPI 0.80 does not mean the project is 80% done. It means 80% of the planned value for today has been earned.
• Ignoring the critical path. A healthy SPI on non-critical work can hide a late critical path, and a weak SPI on float-heavy work can exaggerate risk.
• Letting earned value rules drift. Consistency matters more than sophistication. A simple 0/100 rule applied consistently beats a sophisticated rule applied differently by each team.
• Reporting SPI without a baseline date. A ratio without a baseline version is impossible to audit.
• Celebrating SPI above 1 without checking scope. Ahead-of-plan can mean efficient delivery, or it can mean the team is doing less than the customer expects.
• Trusting SPI near completion. It converges to 1.00 by definition. Switch to earned schedule or a network reforecast for the endgame.
• Hiding the cause in a footnote. The number is the headline; the cause is the story. Put the cause in the same slide.

(/planning/cost-performance-index/) for the cost side of the same picture.”]

Conclusion

SPI turns “are we on schedule?” into a number you can track, challenge, and forecast from. The formula is one division, but the value comes from the discipline around it: a stable baseline, consistent earned value rules, a cut-off date everyone respects, and the habit of checking the critical path before believing the ratio.

Use SPI as an early warning system, not a verdict. Pair it with CPI, add earned schedule when the project enters its final third, and write down the cause behind every meaningful move. Teams that do this catch schedule problems while they are still cheap to fix, instead of discovering them in the final month when the only remaining option is a conversation about what to cut.

If this post on schedule performance index was helpful, you might also enjoy What Does a PMO Do? Roles, Responsibilities, and Daily Work and How to Plan Team Capacity (Step-by-Step Guide).