STO·SAR · Schedule Assurance Review
The execution schedule is the one artifact your whole turnaround rides on: every crew, permit, and the restart date resolve to it. STO·SAR works that schedule in full and hands your team a prioritized correction plan before baseline lock, while the logic can still be fixed.
Deep analysis in. A short, prioritized plan out.
The problem
A schedule with broken logic is a paper map in a nice frame: it shows the route, but it cannot tell you the bridge ahead is out. Sound logic is what lets a schedule behave like a live map instead, rerouting and re-forecasting the finish the moment something moves. Most execution schedules are baselined without anyone stress-testing the logic underneath, and three failures hide there in plain sight.
If the driving chain does not run to the business milestone, the date on the cover is not the date the logic supports.
Add crews to a resource-driven event and it compresses; to a logic-driven one and nothing moves. You need to know which you have.
Float is not contingency. We measure the real reserve between the plan and the date you committed to.
What makes it different
STO·SAR rebuilds your schedule’s logic from first principles with a calendar-aware critical-path engine, then reads it three ways that a settings audit cannot.
P6 overwrites the evidence when it levels, so we determine the leveling state forensically, then measure how much of the duration is logic versus resource limits.
We trace the driving chain backward from the business startup milestone, not the network’s last bar, and report how far it actually reaches through real work.
We separate the planned duration from the real built-in reserve to the date you committed to, and flag a finish that logic does not actually drive.
Leveling, and the real driver
Contingency to the committed date
Every check we run
Each check is measured against public frameworks, DCMA 14-point, GAO, AACE, and PMI, and weighted by how much it puts the restart at risk. Nothing is a proprietary score you cannot see inside.
| Check | What it catches | |
|---|---|---|
| Configuration & integrity10 of 100 points | ||
| A1 | Scheduling settings | The P6 options are set so the forward and backward pass can be trusted. |
| A2 | Calendars | Work patterns are real, and no calendar is quietly set to run more hours than its name implies. |
| A3 | File & status integrity | One data date, clean actuals, nothing corrupting the calculation. |
| Network logic35 of 100 points | ||
| B1 | Open ends | Every activity has something driving it, so a slip actually propagates. |
| B2 | Dangling logic | No activity tied on only one side, hiding its true impact on the finish. |
| B3 | Relationship types | Finish-to-start dominant; overlaps modeled honestly, not by convenience. |
| B4 | Lags | Delays built into the logic are justified, not padding the plan. |
| B5 | Leads / negative lags | No negative lags papering over missing sequence detail. |
| B6 | Hard constraints | Dates are driven by logic, not pinned by constraints that mask the real risk. |
| B7 | Redundant & circular logic | No loops or duplicate ties distorting the calculated path. |
| Float & critical path22 of 100 points | ||
| C1 | Negative float | The plan is achievable as drawn, not already behind on day one. |
| C2 | Unexplained high float | No activity floating longer than the entire event with no reason it should. |
| C3 | Critical-path validity & reach | The critical path is continuous, real, and reaches the startup you promised. |
| C4 | Near-critical & merge exposure | The paths about to become critical, and the points where many converge, are visible. |
| C5 | Float distribution | The criticality profile is sane, not a network with no real spine. |
| Durations & milestones10 of 100 points | ||
| D1 | Activity durations | No oversized activities hiding sequence, detail, and risk. |
| D2 | Level of effort | Hammocks and LOE are bounded, not silently inflating the critical path. |
| D3 | Milestones | Feed-out, handover, and startup milestones are structured and tied on both sides. |
| Resources, leveling & density12 of 100 points | ||
| E0 | Leveling state | Whether the schedule was resource-leveled, determined forensically from the file. |
| E1 | Resource loading | The work that should carry crews and hours actually does. |
| E2 | Assignment integrity | No broken, zero-unit, or impossible resource assignments. |
| E3 | Leveling coherence | The leveled dates and the underlying logic agree with each other. |
| E4 | Resource density | The manpower curve is physically achievable, not a wall of parallel work. |
| Coding & traceability11 of 100 points | ||
| F1 | Code completeness | Phase, unit, system, and discipline coding present, so the plan can be sliced and audited. |
| F2 | WBS structure | A clean, meaningful hierarchy, not empty scaffolding. |
| F3 | Traceability | Activities tie back to work orders and carry unique, legible names. |
The engine settings are valid, so the calculated dates can be trusted at all.
The critical path is continuous, made of real work rather than level-of-effort, and reaches the promised startup.
One data date and clean actuals, so the measurement rests on solid ground.
How it reads out
A schedule can be well built and still not ready, so we report quality and readiness separately. You see how good the model is, and, independently, whether it is safe to sanction.
An absolute maturity grade across all 25 elements. The industry median sits in Developing, so the grade is honest and the headroom is real.
What you get
The analysis is exhaustive. What comes back to your team is not: a clear, prioritized plan that maps each issue to its fix, early enough to make the changes before the baseline is frozen and the date is committed.
The correction plan is the decision document: each finding, why it matters, and the specific fix, in priority order. The workbook behind it is the line-by-line repair manual, every flagged activity with its issue and acceptance criteria.
STO·SAR runs as a standalone review, or as the schedule engine inside a STOAR3 gate review, where it feeds the final sanction.
What changes
Send us the P6 file for the event you are planning now. We will show you where the logic holds, where it does not, and what to fix before you lock the baseline.