STO·SPR · Schedule Performance Review
Where did the time really go, and what do you change next time?
Your baseline made a promise. The as-built, the gate log, the change orders, and the daily reports recorded what happened. STO·SPR joins them all, measures the event against the commitment, and tests every explanation for why against your own records, so your closeout is evidence, not memory, and your next event starts ahead.
The post-mortem, computed, not recalled.
retained
you actually ran
actual hours
confidence
The problem
A lessons-learned meeting produces opinions. Your records hold the evidence.
Most closeouts are a room full of memory and a binder that gets filed. Yet the reason the date moved is already written down, scattered across records nobody joins up: the schedule, the gate log, the change-order log, the daily reports. Until the explanations are tested against those records, the closeout is a story, and the same misses return.
What people remember and what the schedule records are rarely the same thing.
Without a measured cause, the fix is a slogan, and the slip comes back.
Leadership asks what happened, and the answer is a story, not a number.
What it measures
We join your baseline to the as-built, and read it four ways.
STO·SPR task-matches the frozen baseline to the completed schedule, then measures the event at every level. Every figure is computed by the engine; the written account is validated against it, never the other way around.
Event, phase, and unit
Where the days were won and lost, from the whole event down to the single unit, with earned schedule read as a rate: a window-clipped SPI(t) beside the day counts.
Plan versus as-built
What actually governed execution, how much of the planned path survived, and what entered and left it.
Earned over actual hours
The completed schedule’s earned hours against the gate-log actuals, by craft, so productivity is measured, not guessed.
The budget is additive and exact by construction: the named drivers plus the residual sum to the window slip, to the day. What the tool will not do is absorb the remainder into a driver to make the picture tidy. Here one driver is measurable and the residual is the larger number, and that is the finding: only 18% of the planned driving path survived, so the days went somewhere the schedule record cannot name. A review that quietly attributed them would be inventing a cause and calling it analysis.
SPI(t) reads performance in time rather than hours. An event that burned its labour early still shows the window it actually ran, which is the number a steering team is really asking about.
Productivity by craft
earned / actual
earned / actual
earned / actual
earned / actual
Earned hours over gate-log actuals, execution window. Reported only where the gate log covers enough of the hours to be meaningful.
Why it slipped
Every explanation for the slip, tested against your own records.
The engine raises thirteen candidate explanations deterministically from the measurements themselves, scope growth, late adds, productivity, undermanning, a critical-path shift, discovered work, external events among them. Each hypothesis is then tested against the change-order log and the daily reports, and returns a verdict, supported, partially supported, unsupported, or insufficient evidence, with a stated confidence. What could not be established is said plainly, so you know exactly which answers deserve action.
The records we pull in
| Baseline + as-built | Task-matched, so variance and the critical path are read against the frozen promise. |
| Gate log | Labor actuals in whatever format the site keeps, normalized to craft for earned-over-actual productivity. |
| Change-order log | Parsed to structured rows: dates, reasons, magnitudes. Corroborates where the added hours came from. |
| Daily reports | Indexed and searchable, so every hypothesis is tested against the field record. |
| Cost report | Client-supplied, read as indicative context, never treated as ground truth. |
The verdicts that come back
The signature analysis
A baseline defect, traced to the days it cost.
STO·SAR flags defects in a baseline before execution. STO·SPR closes the loop after it: every flagged defect is traced through the task match to the specific as-built activities it touched, and the slip it echoes. A logic finding stops being a hygiene point and becomes a measured consequence, the loop a point-in-time review cannot close.
Did the plan predict reality
The accountability loop most closeouts skip.
We score the baseline’s own quality against the outcome it produced. Each risk the plan carried is paired with what actually happened, and classified, so the readiness review that came before is held to account and the next one gets sharper.
The verdict that matters most is the one nobody asks for. A risk that emerged unflagged is a gap in the review method itself, and it is the only way the next readiness review gets better rather than merely longer.
Critical path · plan vs as-built
survived into execution
Flagged, then what happened
| Flagged in the baseline | What actually happened |
|---|---|
| Readiness: Conditional | Missed the committed date by 20 days Materialized |
| C2 unexplained float (Severe) | 53% of matched activities finished late Materialized |
| C3 path reach (Material) | 0% of the planned critical path survived Materialized |
| Materials on-site risk | Mitigated, delivered to need date Held |
| Not flagged | PSSR drove 25% of the startup slip Emerged unflagged |
What you get
An action register, not another binder.
The report ranks the credible causes by confidence and states what could not be established. The deliverable is a register of specific, owned actions in two tiers, next-event and systemic, each tied to a tested cause. It closes the assurance loop into the next event’s premise, and the coded outcomes build your benchmark over time.
of the event
test why
register + report
Every number is computed by the engine behind a hard wall: the model weighs the evidence and writes the account, is validated against the figures, and never invents one. Any cost you supply is reported as indicative, never treated as ground truth.
STO·SPR runs as a standalone review, or as the performance engine inside a STOAR4 closeout, where it opens the lessons workshop on measured facts.
What changes
The difference at the next event.
Without STO·SPR
- ×Lessons written from memory, and quietly filed
- ×Competing theories for the slip, none of them tested
- ×The same phase and the same craft slip again next event
With STO·SPR
- ✓A quantified account of where the time and hours went
- ✓Every explanation tested against your records, with a stated confidence
- ✓Owned actions tied to a tested cause, and a benchmark that compounds
Your guide
We have sat in the seat, on both sides of the table.
STO Intelligence is an independent assurance partner, founder-led by 25 years across refining, petrochemicals, and LNG, as the owner accountable for the outcome and as the consultant brought in to protect it.
Our methods stay at public-framework level, DCMA 14-point, GAO, AACE, and PMI, so every finding is defensible and nothing is a black box. You own the standard, not a proprietary score you cannot see inside.
Why STO Intelligence
Empathy for the seat you are in, explaining an overrun with nothing but recollections. Authority to settle it, the measured record, public frameworks, and a founder who has stood in the closeout room on both sides.
Where this goes
One review fixes one event. The system is the prize.
The action register fixes the next event. Run it inside a STOAR closeout and the lessons become owned actions in STO·PATH, landing on the next event’s own plan against the STO·CORE standard, so what this event taught you never has to be relearned.
Turn your last STO into your next one’s advantage.
Send us the baseline, the as-built, and the records you already keep. We will show you where the time went, why it went there, and how much confidence each answer deserves.