Ask any turnaround scheduler what keeps them up at night and the answer is rarely the whole schedule — it is the twenty or thirty activities that sit on the critical path, where a single day of slip anywhere in that chain becomes a day of slip on the entire event. Everything else on the schedule can absorb some delay without consequence, because it carries float. The critical path carries none, which is exactly why building it correctly, resource-leveling it honestly, and protecting it relentlessly through execution is the single most consequential piece of turnaround scheduling work. Get it wrong and a schedule that looks complete on paper turns into a live-fire exercise in recovery the moment the unit comes down. Our turnaround scheduling specialists can review how your critical path is currently built and where it might be exposed.
The Schedule Only Has as Much Discipline as Its Critical Path
Why the Critical Path Is the Only Schedule That Actually Matters
A turnaround schedule can run to several thousand activities across dozens of work fronts, and it is tempting to think of schedule performance as a broad average across all of them. It is not. The activities that sit on the critical path — the chain with zero total float running from the first shutdown activity through to startup readiness — are the only ones where a delay translates directly into turnaround duration. Every other activity in the schedule can slip within its available float without moving the completion date by a single day.
This is why experienced turnaround schedulers spend a disproportionate amount of their attention on a relatively small number of activities. A thousand-activity schedule might have only twenty-five to forty activities actually sitting on the critical path at any given point in execution, and those are the activities that get daily scrutiny, dedicated resources, and priority access to cranes, scaffolding, and specialized labor. Everything else gets managed by exception. Confusing this distinction — treating all activities as equally important, or worse, not knowing which activities are actually on the critical path at a given moment — is one of the most common and costly scheduling mistakes on a turnaround.
The practical discipline this creates is a daily triage exercise rather than a one-time planning decision. Every progress update changes the remaining duration and float on dozens of activities simultaneously, and a scheduling team that treats the critical path as something calculated once during planning and then left alone is working from a picture that is stale within days of execution starting. The teams that manage this well build the daily critical path recalculation into the same rhythm as their progress reporting, so that the list of activities receiving priority resources on any given shift is always the current list, not the one from the original baseline.
Building the Work Breakdown Structure First
A critical path is only as reliable as the work breakdown structure it is built on top of. Schedulers who jump straight into activity sequencing without a properly leveled WBS end up with a schedule that looks detailed but is actually inconsistent — some work fronts broken down to the task level, others lumped into single multi-day activities that hide the real logic and dependencies underneath them.
| WBS Level | Scope | Typical Duration Granularity |
|---|---|---|
| Level 1 | Overall turnaround event | Single milestone-to-milestone span |
| Level 2 | Major unit or process area | Weeks |
| Level 3 | Equipment or work front | Days to weeks |
| Level 4 | Individual work package | Hours to days |
| Level 5 | Task-level activity | Hours |
The right level of detail for critical path activities is typically Level 4 or 5 — granular enough that resource assignments, durations, and predecessor relationships are realistic rather than aggregated guesses. Non-critical support activities can often stay at Level 3 without harming the schedule's integrity, since the float available on those activities absorbs the loss of precision. Getting this balance right keeps the schedule detailed where it matters and manageable everywhere else, rather than uniformly over-detailed in a way that makes the schedule impossible to maintain through execution.
Resource Leveling: What Changes Before and After
An unleveled schedule almost always looks better than it actually is, because logic-only sequencing assumes unlimited crew and equipment availability at every point in the schedule. Resource leveling is the process that exposes where that assumption breaks — where three work fronts all need the same crane on the same day, or where a specialty welding crew is scheduled to work in two locations simultaneously because the logic never accounted for their actual headcount.
The cost of resource leveling is almost always an extended schedule compared to the pure logic-only version, because activities that were assumed to run in parallel now have to be sequenced against real crew and equipment constraints. This is an uncomfortable but necessary conversation to have during planning rather than execution — a schedule that only works on paper because it assumes infinite resources is not actually a schedule, it is a target that the field will inevitably miss once real constraints show up during the shutdown itself.
Parallel Work Streams and Float Management
Most turnaround schedules are built around parallel work streams — separate work fronts on different equipment or process areas that proceed independently except where they share a resource, a permit dependency, or a physical access constraint. Managing these streams well means understanding exactly where they interact with the critical path and where they carry their own float that can absorb delay without affecting the overall completion date.
The lane with only a single day of float, shown above, deserves nearly as much daily attention as the critical path itself, because it is one delayed activity away from becoming the new critical path. This is the concept of near-critical activities, and experienced schedulers track them explicitly rather than assuming the critical path identified at the start of the turnaround stays fixed through execution. In practice, the critical path frequently shifts during a live turnaround as different work streams consume or lose their float, and a scheduling process that does not re-calculate and communicate that shift daily is working from an outdated picture of what actually needs protection.
Primavera P6 vs. MS Project for Turnaround Scheduling
Both tools can build and resource-level a critical path schedule, but they are not equally suited to every scale of turnaround, and the choice matters more as the activity count and resource complexity grow.
| Capability | Primavera P6 | MS Project |
|---|---|---|
| Activity count handling | Strong at 5,000+ activities | Workable to a few thousand before performance degrades |
| Resource leveling depth | Advanced multi-resource, multi-calendar leveling | Basic leveling, less granular by resource type |
| Multi-user collaboration | Built for large distributed scheduling teams | Better suited to single-scheduler or small-team use |
| Reporting and EVM | Native earned value and progress reporting | Requires add-ins or manual tracking for EVM |
| Learning curve | Steeper, purpose-built for project controls staff | More familiar to general project managers |
For a large, multi-unit turnaround with several thousand activities, dozens of contractors, and a dedicated project controls team, Primavera P6 is almost always the better fit given its depth in resource leveling and earned value reporting. For a smaller, single-unit turnaround managed by a leaner planning team, MS Project can be entirely adequate, provided the scheduler is disciplined about keeping the critical path visible and current rather than letting the tool's simpler leveling capability mask real resource conflicts.
Schedule Compression: Crashing vs. Fast-Tracking
When a leveled schedule comes back longer than the target duration, schedulers have two standard compression techniques available, and choosing the wrong one for the wrong activity is a common source of hidden risk.
Crashing works well on labor-driven activities like insulation removal or scaffolding erection, where more crews genuinely produce faster completion. It works poorly on activities with a fixed physical duration regardless of crew size, such as a hydrotest hold time or a catalyst regeneration cycle, where adding resources does nothing to shorten the clock. Fast-tracking carries its own risk profile — overlapping an inspection activity with the repair work it is meant to scope, for example, can create rework risk if the inspection finds something the overlapping repair crew was not prepared for. Both techniques belong in the scheduler's toolkit, but only when applied to the specific activities where the underlying constraint actually supports compression.
What Disciplined Critical Path Management Delivers
Turnarounds that manage the critical path with the same rigor they apply to cost and safety consistently see measurable schedule performance improvements, independent of any change in scope or budget.
Critical Path Miscalculation Errors That Slip Through
Even experienced scheduling teams introduce errors into the critical path calculation that go unnoticed until the schedule is already being executed. These are not exotic mistakes — they are the kind of small logic errors that accumulate across a schedule with thousands of activities and hundreds of predecessor relationships entered by multiple planners over months of development.
| Error Type | How It Happens | Effect on the Path |
|---|---|---|
| Missing predecessor link | An activity entered without its true logical dependency | Understates float, hides the real critical path |
| Hard constraint dates | A fixed start or finish date entered instead of logic-driven scheduling | Masks true float and can suppress the real critical path entirely |
| Out-of-sequence progress | Field progress reported before a predecessor is actually complete | Distorts remaining duration and float calculations |
| Unresolved open ends | Activities with no successor left dangling in the network | Breaks the continuous logic chain needed for an accurate path |
Hard constraint dates deserve particular attention because they are often entered with good intentions — a scheduler locking in a known equipment delivery date, for example — but they suppress the network logic that the critical path calculation depends on. A schedule riddled with hard constraints can show a critical path that looks stable and reasonable while actually hiding several activities that would otherwise be flagged as zero-float if the logic were allowed to run freely. Periodic schedule health checks that flag constraint counts, open-ended activities, and missing logic links are a standard project controls discipline precisely because these errors are common and because they are invisible in a normal Gantt chart view unless someone is specifically looking for them.
