Why your maintenance schedule isn't driving execution

It is where engineering recommendations become real interventions before failures happen. Where overdue work gets actively managed before it accumulates. Where technician hours get directed toward the work that matters most.

And ultimately, it is where all upstream maintenance effort either turns into operational action — or quietly disappears.

Because plan attainment is not really the root metric.

The real question is: does the schedule actually influence what work gets executed?

At many heavy asset sites, the answer is no.

Even at organisations with sophisticated scheduling departments and highly detailed Primavera schedules, the schedule often operates beside execution instead of driving it.

Most work never properly enters the schedule. Much of the work that does enter it gets administratively "closed" later to match planned dates rather than reflecting what really happened. The schedule looks detailed, professional, and controlled — while daily execution follows a completely different rhythm underneath it.

This article explains:

• what scheduling should actually achieve
• why many sites struggle to achieve it
• how to diagnose the disconnect
• and what changes when scheduling becomes integrated into the real maintenance process instead of operating as a separate layer

What scheduling is actually supposed to do

Good scheduling is not just about creating a calendar.

It is supposed to connect planning, engineering, resources, and execution into one operational rhythm.

That means three things need to happen.

Engineering recommendations need to become scheduled work.

If an engineer recommends replacing a bearing within four weeks based on vibration analysis, that recommendation should become visible operational work:

• visible to planners
• visible to schedulers
• visible to supervisors
• visible to technicians

If the recommendation never lands in the schedule, then the engineering effort never truly became operational action.

Overdue work needs to be actively controlled.

A functioning schedule helps the organisation:

• prioritise overdue work
• rebalance capacity
• sequence interventions realistically
• prevent overdues from silently compounding

Without that visibility, overdue management becomes reactive instead of controlled.

Resources need to align with the most important work.

Scheduling is ultimately about deciding where limited technician hours go.

That means the organisation should be able to direct labour toward:

• reliability-critical work
• high-risk overdues
• preventative interventions
• operational bottlenecks

Instead, many sites slowly drift into a situation where technicians simply pick up whatever work becomes easiest or most urgent in the moment.

At that point, the schedule stops driving execution. Execution starts bypassing the schedule.

Why this breaks at many sites

The core problem is usually structural.

Planning, scheduling, engineering, and execution all operate in different systems with different visibility.

The planner prepares work in SAP. The scheduler builds schedules in Primavera. The engineer creates recommendations in notifications or separate reliability systems. Technicians capture actual work somewhere else entirely.

Each role sees part of the picture. Nobody sees the whole operational flow.

The planner may know:

• priority
• due dates
• required labour
• material readiness

But once work leaves SAP and enters the scheduling tool, visibility often disappears.

The scheduler builds a detailed schedule based on the information available to them. But they may never see:

• the original engineering recommendation
• the true operational due date
• changing field priorities
• the reasons work is slipping

The engineer creates recommendations but often receives no feedback loop afterwards. Questions like:

• Did the work land in this month's schedule?
• Was it delayed?
• Was it executed late?
• Did the intervention prevent failure?
• Was the original timing recommendation correct?

At many sites, nobody can answer those cleanly.

The schedule becomes a representation of work. Not the mechanism actually driving it.

How to check whether this is happening at your site

Most organisations already feel this disconnect intuitively.

The useful question is how to measure it objectively.

The following checks compare scheduling-system behaviour against SAP execution behaviour.

1. How much scheduled work actually exists cleanly in SAP?

Take all workorders appearing in the scheduling system and compare them against SAP records.

Do statuses align? Do dates align? Do workorders transition consistently?

The overlap tells you how connected the scheduling layer really is to the operational system underneath it.

2. Do labour bookings support the reported execution dates?

For workorders marked "executed" in the schedule, compare the reported completion dates against technician labour bookings.

If work is shown as completed but no technician hours were booked anywhere near that timeframe, then the closure likely reflects administrative behaviour instead of operational reality.

In one analysed Primavera site, only roughly one-third of closure dates had labour bookings that realistically supported the reported execution timing.

3. Are actual completion dates genuinely actual?

Compare planned completion timestamps against actual completion timestamps.

At many sites, enormous percentages match almost perfectly — sometimes even down to the exact minute.

Operationally, that is extremely unlikely.

Usually, it indicates planned dates being copied into actual dates automatically during status transitions instead of true execution behaviour being captured.

That destroys one of the most important learning signals in maintenance: whether the original schedule was actually realistic.

4. How much executed SAP work never appeared in the schedule?

Take all workorders with labour bookings in SAP during the period and compare them against scheduled work.

This is often where organisations discover the real scale of the disconnect.

5. What statuses exist underneath "not executed" work?

Take workorders still shown as pending or unexecuted in the scheduling system and compare them against SAP user statuses.

Usually you find several hidden categories:

• genuinely still-open work
• technically completed work still appearing scheduled
• stale statuses never updated correctly
• overdue work trapped in administrative limbo

The split reveals where the operational disconnect actually lives.

What this looks like in practice

When organisations discover these gaps, the first reaction is often:

"Our schedule just doesn't cover everything."

But the problem is usually much bigger than scheduling coverage. If most technician hours are being spent outside scheduling visibility, then the organisation is no longer actively directing labour toward the most important work.

Instead, execution becomes decentralised:

• Technicians pick up work directly
• Supervisors reprioritise locally
• Urgency overrides planning
• Side systems emerge
• Hidden schedules appear

Gradually, the official schedule becomes more administrative than operational. Meanwhile the organisation often still believes scheduling control exists, while underneath:

• reliability work gets delayed
• overdues grow silently
• capacity is consumed inefficiently
• engineers lose feedback
• planners lose visibility
• KPIs stop reflecting reality

The schedule still looks impressive. But it is no longer steering the operation.

Why the scheduler is usually not the problem

The issue is rarely that schedulers are doing poor work. Many build extremely detailed and professional schedules under difficult conditions.

The real issue is isolation.

The scheduler often operates without:

• full engineering visibility
• live operational feedback
• integrated planning visibility
• trustworthy execution feedback

So even a highly capable scheduler ends up building schedules from incomplete information.

The disconnect is systemic, not personal.

The solution is not removing scheduling capability.

The solution is integrating scheduling into the actual maintenance workflow instead of running it as a parallel layer beside it.

What "the right level of detail" actually means

One of the biggest traps in maintenance scheduling is over-detailing daily work.

Primavera-level scheduling detail makes enormous sense during:

• turnarounds
• shutdowns
• large projects
• highly constrained execution windows

In those environments:

• dependencies matter deeply
• contractor coordination is complex
• minute-level sequencing creates real value

But many organisations apply that same level of scheduling detail to routine maintenance.

Operationally, it often creates huge administrative effort without improving execution quality.

A practical example:

A scaffolding contractor usually does not need to know: "this exact work starts Thursday at 14:00."

They need to know: "the scaffold must be ready before execution starts."

That is the level of coordination they actually work from.

Anything more detailed often becomes noise — which is why contractors and supervisors frequently rebuild simpler side schedules themselves.

The right level of detail is not: the maximum level the software can produce.

It is: the minimum level required for effective operational coordination.

When scheduling is properly integrated into the maintenance process, the right level of detail tends to emerge naturally.

When scheduling operates beside the process instead of inside it, organisations either:

• massively overcomplicate scheduling, or
• barely schedule at all