A shutdown is an operating event

This piece extends the work order is not the maintenance system. A shutdown is the clearest case where work orders sit inside a larger operating object.

A shutdown is often represented as a maintenance schedule.

A collection of work orders is assembled.

Activities are sequenced.

Labour is allocated.

Parts are staged.

The plant stops.

The work is completed.

The plant restarts.

That description is not wrong.

But it is incomplete.

A major shutdown is not simply a large maintenance job.

It is a temporary operating state in which production, maintenance, contractors, procurement, safety, engineering, logistics and commissioning all converge around a constrained window.

That makes the shutdown itself an important operational object.

The work orders sit inside it.

A useful proposition is:

A shutdown should be managed as an operating event, not merely as a collection of scheduled work orders.

The shutdown exists because production and maintenance intersect

Most maintenance work can be planned around normal operations.

A shutdown is different.

The operation deliberately gives up productive capacity so that work can be performed that cannot reasonably occur while the plant remains online.

That creates an immediate trade-off.

Production Opportunity
        ↕
Shutdown Duration
        ↕
Maintenance Scope

A longer shutdown may allow more work.

More work may reduce future failure risk.

But every additional hour may also carry a production consequence.

So the fundamental shutdown question is not simply:

What maintenance work can we complete?

It is:

What is the best combination of work, risk reduction, lifecycle benefit and production impact that can be achieved inside the available window?

That is an operating decision.

The work begins long before the plant stops

Shutdown execution may last days.

Shutdown planning may begin months earlier.

Potential work can emerge from:

• preventive maintenance;
• inspections;
• condition monitoring;
• recurring defects;
• lifecycle forecasts;
• engineering recommendations;
• statutory requirements;
• previous shutdown findings;
• production concerns;
• improvement projects.

At first, much of this is only candidate work.

A useful model might begin:

Asset Evidence
      ↓
Candidate Work
      ↓
Assessment
      ↓
Shutdown Scope
      ↓
Work Package
      ↓
Execution

That distinction matters.

A work order may already exist.

But being a valid maintenance requirement does not necessarily mean it belongs in this shutdown.

Scope is a decision

Every shutdown has more potential work than available time and resources.

Some work is essential.

Some work is beneficial.

Some work is opportunistic.

Some work can safely be deferred.

A useful scope model might classify work as:

MUST DO

SHOULD DO

OPPORTUNISTIC

CAN DEFER

The decision may consider:

• safety consequence;
• statutory obligation;
• failure probability;
• production consequence;
• remaining life;
• next shutdown opportunity;
• duration;
• parts availability;
• contractor availability;
• access requirements;
• resource demand.

This means shutdown planning begins before detailed scheduling.

It begins with deciding what should be included.

Remaining life matters to scope

Consider a component with:

Estimated remaining life      4,000 h

The next planned shutdown is:

3,000 operating hours away

The component may reasonably stay in service.

But suppose the production forecast changes.

Expected operation before the next shutdown becomes:

4,600 h

The scope decision changes.

Now the component may need to be included in the current shutdown.

The chain becomes:

Production Forecast
        ↓
Expected Usage
        ↓
Remaining-Life Comparison
        ↓
Shutdown Candidate
        ↓
Scope Decision

Shutdown planning therefore connects directly to lifecycle management.

The shutdown needs its own lifecycle

A normal work order might move through statuses such as:

Draft
Open
Scheduled
In Progress
Complete

That is too simple for a shutdown.

A shutdown has a broader lifecycle.

For example:

Candidate
    ↓
Scoping
    ↓
Planning
    ↓
Scope Freeze
    ↓
Readiness
    ↓
Approved to Start
    ↓
Execution
    ↓
Commissioning
    ↓
Return to Service
    ↓
Closeout
    ↓
Learning

Each phase answers different questions.

Scoping

What work should be considered?

Planning

How will the work be performed?

Scope freeze

What work is now committed to the shutdown?

Readiness

Can the work actually start when the plant stops?

Execution

Are we progressing to plan?

Commissioning

Is the plant ready to operate?

Closeout

What actually happened?

Learning

What should change next time?

That lifecycle gives the shutdown an identity beyond the work orders inside it.

Work packages may matter more than individual work orders

A shutdown planner may not think primarily in individual jobs.

The natural unit of planning may be a work package.

For example:

Crusher Area
    ↓
Primary Crusher Mechanical Package
    ↓
Conveyor Package
    ↓
Electrical Package
    ↓
Structural Package

A work package might contain:

Work Orders
Inspections
Contractor Tasks
Material Requirements
Isolation Requirements
Access Requirements
Commissioning Tests

That allows the planner to manage a meaningful block of work rather than hundreds of disconnected transactions.

So the hierarchy might be:

Shutdown
    ↓
Area / System
    ↓
Work Package
    ↓
Work Orders / Tasks

The work order still matters.

It no longer has to carry all of the shutdown structure by itself.

Dependencies need to be explicit

Shutdown work is highly dependent.

One activity may not start until another is complete.

For example:

Plant Stop
    ↓
Electrical Isolation
    ↓
Guards Removed
    ↓
Conveyor Belt Removed
    ↓
Pulley Replaced
    ↓
Belt Installed
    ↓
Alignment
    ↓
Guards Reinstalled
    ↓
Isolation Removed
    ↓
Commissioning

These relationships create the schedule.

A delay in one task may delay several others.

That is why shutdown planning needs relationships such as:

Finish-to-Start
Start-to-Start
Finish-to-Finish

possibly with lead or lag.

The schedule is not just a list of dates.

It is a network of operational dependencies.

Critical path matters, but context matters more

Traditional project scheduling can identify:

• critical activities;
• float;
• dependency chains;
• forecast completion.

That is essential.

But a maintenance operating model can add context.

A project scheduler may know:

Activity 13842
Duration: 6 h
Predecessor: 13797

An asset-management model may know:

Pulley Replacement

Asset: CV104
Area: Crushing
Isolation: ISO-24
Required Crane: 80 t
Crew: Mechanical
Part: Pulley P104
Commissioning Requirement: Alignment and vibration test
Production Consequence: Crushing circuit unavailable

The schedule knows when the activity should occur.

The operating model knows what the activity means.

Both are useful.

Readiness is not the same as planning completeness

A work package may be fully planned and still not be ready.

The job instructions may exist.

The duration may be estimated.

The labour may be allocated.

But perhaps:

• the part has not arrived;
• the crane has not been confirmed;
• scaffolding is incomplete;
• engineering drawings are not approved;
• contractor mobilisation is incomplete;
• access permits are unresolved.

A shutdown system should therefore explicitly model readiness.

For example:

Scope ready?                 ✓
Engineering ready?           ✓
Drawings approved?           ✓
Parts available?             ✓
Labour confirmed?            ✓
Contractor mobilised?        ✗
Crane booked?                ✓
Scaffold ready?              ✗
Isolation defined?           ✓
Permit prepared?             ✓
Commissioning plan ready?    ✓

The important result is not necessarily:

Readiness = 82%

A simple percentage can hide critical exceptions.

The more useful result might be:

BLOCKERS

Vendor technician not mobilised
Scaffold incomplete
Critical seal kit not received

A single blocker can prevent the entire package from starting.

Material availability has stages

A shutdown part should not become “ready” merely because a purchase order exists.

A more useful material path might be:

Required
    ↓
Reserved
    ↓
Ordered
    ↓
Expedited
    ↓
Received
    ↓
Inspected
    ↓
Kitted
    ↓
Staged
    ↓
Ready for Work

A bearing still in transit is not ready.

A component received but awaiting inspection may not be ready.

A part in stores at another site may not be ready.

This makes procurement status operational rather than purely transactional.

Contractor readiness also has stages

Shutdowns are frequently contractor-heavy.

A contractor package may involve more than a purchase order.

It may require:

Contract
    ↓
Personnel
    ↓
Competencies
    ↓
Inductions
    ↓
Site Access
    ↓
Accommodation
    ↓
Mobilisation
    ↓
Tools / Equipment
    ↓
Work Area

The contractor may be commercially committed but still operationally unready.

That distinction matters.

For example:

Contracted boilermakers       18
Mobilised                     18
Site access approved          13

The commercial requirement is satisfied.

The operational requirement is not.

Isolation is a network problem

Isolation planning is another area where the shutdown should sit above individual work orders.

Several work packages may depend on the same isolation boundary.

For example:

Isolation Boundary ISO-24
        ↓
Conveyor Pulley Work
        ↓
Belt Replacement
        ↓
Sensor Replacement
        ↓
Structural Inspection

The planner can then ask:

If this equipment is already isolated, what additional work should be completed during the same window?

This can improve efficiency.

It also means isolation status should be connected to:

• affected assets;
• work packages;
• permits;
• energy sources;
• commissioning;
• de-isolation sequence.

Attaching an isolation document individually to each work order does not fully express those relationships.

Production impact should remain visible

Every shutdown has a production consequence.

The operation may know:

Planned duration      72 h
Throughput            1,200 t/h

A simplistic production-loss calculation might therefore be:

86,400 tonnes

Reality is usually more complicated.

The impact may depend on:

• stockpiles;
• downstream capacity;
• upstream constraints;
• alternative circuits;
• product inventory;
• market demand;
• partial operation.

But the production consequence still matters.

That allows better scope decisions.

For example:

Optional maintenance job

Expected duration             +4 h
Estimated intervention cost   $80k
Estimated outage exposure     +4 h
Failure risk if deferred      High
Expected breakdown duration   18 h

Now the decision is not merely:

Do we have four spare hours?

It becomes:

Is accepting four hours now preferable to the risk of an eighteen-hour unplanned outage later?

That is a much better operational question.

The shutdown should optimise risk, not just duration

A short shutdown is not automatically a good shutdown.

Suppose work is removed to meet an aggressive duration target.

The plant restarts on time.

Two weeks later a deferred component fails.

The shutdown may have met its schedule KPI while creating a worse operating outcome.

So shutdown performance should potentially consider:

Duration
Cost
Scope completed
Risk removed
Reliability improvement
Production restored
Post-shutdown failures

The real objective is not simply:

minimise shutdown hours.

It may be:

minimise total operational consequence while achieving an acceptable future risk position.

That is a more useful optimisation objective.

Break-in work needs explicit governance

Shutdowns often uncover unexpected conditions.

A cover is removed.

A crack is discovered.

A bearing is worse than expected.

Additional wear is identified.

This creates break-in work.

The process should not simply be:

Discover issue
    ↓
Add another work order

A stronger process might be:

Discovery
    ↓
Assessment
    ↓
Risk if Deferred
    ↓
Duration Impact
    ↓
Resource Impact
    ↓
Production Impact
    ↓
Decision

The decision may be:

DO NOW

or

DEFER

That decision should be traceable.

Useful information might include:

• why the work was added;
• who approved it;
• schedule impact;
• critical-path effect;
• cost impact;
• production consequence;
• future action if deferred.

Break-in work is one of the clearest examples of why shutdown execution requires its own governance.

Forecast completion should keep moving

The baseline shutdown end time matters.

But as execution progresses, the current forecast matters more.

A useful view may retain:

Baseline Completion

Current Forecast Completion

Variance

Primary Delay Drivers

For example:

Baseline complete          Sunday 06:00
Current forecast           Sunday 11:30
Variance                   +5.5 h

Drivers:
Pulley removal             +2.0 h
Break-in structural work   +2.5 h
Commissioning delay        +1.0 h

That is much more useful than showing individual late work orders without explaining the total consequence.

Commissioning is part of the shutdown

Maintenance completion and shutdown completion are not the same thing.

The last mechanical work order can be closed while the plant remains unfit for production.

A complete shutdown lifecycle needs:

Mechanical Completion
        ↓
Inspection
        ↓
Isolation Clearance
        ↓
Pre-Start Checks
        ↓
Functional Testing
        ↓
No-Load Commissioning
        ↓
Loaded Commissioning
        ↓
Production Acceptance
        ↓
Return to Service

This is where maintenance and operations reconnect.

The shutdown is complete when the operation has safely regained the required operating capability.

Budgeting needs the same operational view

A shutdown budget should also distinguish:

Budget
Baseline
Committed
Actual
Forecast Remaining
Expected Outturn

For example:

Approved budget            $4.2m
Actual to date             $2.3m
Committed                  $1.7m
Forecast remaining         $0.8m
-------------------------------
Expected outturn           $4.8m

The system should explain why the forecast moved.

For example:

Break-in mechanical work    +$250k
Crane extension              +$90k
Additional contractor hours  +$140k
Unused contingency           -$80k

The shutdown budget then becomes part of the operating position rather than a separate financial report.

Labour and other resources should also have positions

The same principle applies to resources.

For example:

Mechanical labour

Planned                    8,400 h
Committed                  8,700 h
Actual                     5,200 h
Forecast total             9,350 h

Or:

80 t crane

Planned                      36 h
Current forecast             51 h

That allows planners to identify resource pressure before it becomes a schedule failure.

The shutdown should learn

A shutdown produces a large amount of evidence.

It reveals:

• actual job durations;
• actual labour;
• actual material use;
• unexpected asset condition;
• actual component lives;
• planning errors;
• contractor performance;
• readiness failures;
• commissioning issues;
• break-in work;
• production consequences.

Those findings should not disappear into the completed schedule.

They should change future assumptions.

For example:

Planned pump replacement     12 h
Actual                        18 h

Future job plans may need to change.

Or:

Expected liner life          18 months
Actual life                  13 months

Future shutdown scope may need to change.

The feedback loop should be:

Shutdown Plan
      ↓
Execution
      ↓
Actual Evidence
      ↓
Lifecycle Update
      ↓
Resource Update
      ↓
Job-Plan Update
      ↓
Future Shutdown Forecast

Every shutdown should make the next shutdown better.

Shutdown history can improve production forecasting

Shutdown performance also affects future production assumptions.

If planned outages consistently run longer than expected, production plans based on unrealistic shutdown durations may be overstated.

Historical evidence might show:

Planned duration average     72 h
Actual duration average      81 h

Future production forecasts should account for that evidence unless the underlying planning capability improves.

The shutdown is therefore not just maintenance history.

It is production-planning evidence.

The shutdown can have an operational position

A useful CPM shutdown view might look like:

SHUTDOWN SD-27-01

Window
Baseline                   72 h
Current forecast           76 h

Scope
Approved packages          184
Ready                      172
At risk                      8
Blocked                      4

Cost
Budget                    $4.2m
Committed                 $3.9m
Forecast                  $4.6m

Labour
Planned                 14,000 h
Forecast                15,100 h

Materials
Required                   1,238
Ready                      1,196
At risk                       42

Production
Planned restart          06:00
Current forecast         10:00

That is essentially an operational position for the shutdown.

It brings together information that is otherwise spread across maintenance, procurement, contracting, scheduling and production systems.

This does not mean CPM should become a project scheduler

There are mature tools for large-scale project scheduling.

Primavera, Microsoft Project and specialised turnaround tools already provide sophisticated scheduling capabilities.

CPM does not necessarily need to replace them.

A more useful role may be:

CPM
Operational Meaning
        ↕
Project Scheduler
Time / Dependencies

The project scheduler can manage:

• activity dates;
• dependencies;
• critical path;
• float.

CPM can manage:

• asset context;
• condition;
• shutdown scope;
• readiness;
• materials;
• isolations;
• production consequence;
• commissioning;
• lifecycle feedback.

The two can integrate.

That may be considerably more realistic than rebuilding every specialised scheduling function.

What this could mean for CPM and DSLCore

For CPM, shutdowns should probably become a first-class domain rather than a filter over work orders.

Useful entities might include:

ShutdownEvent
ShutdownWindow
ShutdownScopeItem
WorkPackage
WorkDependency
Milestone
ResourceRequirement
MaterialRequirement
ContractorPackage
IsolationBoundary
PermitRequirement
ReadinessRequirement
ScopeFreeze
ScopeChange
BreakInWork
ProductionConstraint
CommissioningPlan
CommissioningTest
ShutdownForecast
ShutdownCloseout

Existing entities remain:

Asset
WorkOrder
Person
Contractor
InventoryItem
PurchaseOrder
Inspection
ConditionReading
Component
Risk

The shutdown domain links them.

That is the important architectural difference.

It also reinforces the broader CPM model

The earlier discussions lead toward an operating architecture something like:

Production
     ↓
Asset Usage
     ↓
Condition / Lifecycle
     ↓
Maintenance Requirement
     ↓
Shutdown Candidate
     ↓
Scope
     ↓
Readiness
     ↓
Execution
     ↓
Commissioning
     ↓
Production
     ↓
Updated Lifecycle Model

The shutdown is one part of a continuous operating loop.

It is not isolated from what happened before or what happens next.

A working hypothesis

The proposition is not that shutdowns have been poorly managed simply because work orders are involved.

Work orders remain essential execution records.

Project schedules remain essential.

The question is whether the shutdown itself deserves to be represented explicitly as an operating state.

A useful distinction may be:

Work orders describe the work performed during the shutdown.

The shutdown model explains why that work is included, whether it is ready, how it interacts, what it costs, how it affects production, and whether the operation can safely return to service.

That is a broader problem.

It needs a broader model.

Questions worth testing

Should shutdowns be first-class objects in asset-management systems?

How should candidate work be prioritised before scope freeze?

Should remaining component life and production forecasts automatically influence shutdown scope?

How should material, contractor, isolation and access readiness be represented?

Should break-in work require explicit operational-impact assessment before approval?

How should shutdown cost, duration, production loss and risk reduction be evaluated together?

Where should a CMMS stop and a specialised project scheduler begin?

Should commissioning and production acceptance be treated as part of maintenance execution or as a separate operating phase?

And perhaps the broader question:

If a shutdown temporarily changes the entire operating state of a plant, should we continue to model it mainly as a collection of maintenance jobs?

A shutdown may be one of the clearest examples of why maintenance systems need to understand not only work, but operational context.