Planning the week in maintenance

Weekly planning is where you decide whether a maintenance plan actually gets followed or just gets drawn up on paper. And it almost always fails for the same reason: you plan at 100% of capacity, a breakdown comes in on Tuesday, and the rest of the week turns into improvised reshuffling.

This is about how to approach it so it survives contact with reality.

Capacity isn’t the same as the workday

The first calculation error. If a technician has forty hours, they don’t have forty hours of assignable work.

You need to subtract travel time, waiting, meetings, and the time lost to the unforeseen. Exactly how much depends on each operation, and there’s no universal percentage: it comes out of your own reports on non-effective hours and the gap between estimated and actual time.

Planning against the full workday guarantees the plan will be broken from Monday.

Reserving room for what can’t be predicted

The most important decision of the week, and the one almost nobody makes explicitly: how much capacity to leave free for corrective work.

If the historical proportion of corrective work is high, reserving too little means every breakdown displaces scheduled work. If it’s low and you reserve too much, you waste hours.

The figure comes from the report on the ratio of preventive to corrective hours, viewed over several months. It’s one of the few planning decisions you can make with a number instead of a gut feeling.

Against reality, not against a calendar

A plan that places work on a holiday or under the name of someone on vacation isn’t a plan.

In GMAO Cloud, before generating a preventive order, the system checks whether the day is a holiday and whether the technician is available, using the shifts, schedules, vacations, and holidays from staff management.

It’s a check that seems minor and that eliminates an entire category of delays.

Seeing the load, not the list

A list of orders sorted by date doesn’t let you see what matters: who’s overloaded and who has room.

The calendar and the diagram-based planning view show each technician’s load across the weeks. And the most useful thing on that screen isn’t what’s assigned: it’s what has no owner, which can be distinguished by color, because that’s exactly what’s going to fall through.

Rescheduling has to be cheap

The rule that decides whether the system reflects reality: if updating the plan costs more than ignoring it, it gets ignored.

That’s why it matters that moving a job means dragging it to another day, not opening a form and filling in fields. When rescheduling is expensive, people write the change down in a notebook and the system ends up describing a week that never happened.

The intervention windows

In many sectors, work can’t be done whenever the technician wants: with the public inside, with the line running, with the shop open, or with a room sold.

It’s worth identifying those windows and planning against them, not against theoretical availability. And it helps that the client can see their upcoming preventive visits from their client portal, so they can arrange site access without having to call anyone.

Letting the technician adjust

The person on the ground has information the office doesn’t. They can see unassigned work and pick it up, and sort their orders by route using GPS from the app.

Watch for the side effect: with an open queue, people tend to grab the easy jobs, leaving a residue of difficult orders nobody picks up. It’s fixed with real priorities and deadlines on incidents, not by closing the queue.

What to prepare before the week starts

Half an hour on Friday that saves several hours the following week:

Material. Check whether the scheduled orders need parts and whether they’re available. The minimum stock setting in warehouses and items warns you ahead of time, but it’s worth checking.

Open anomalies. If a piece of equipment due for inspection has something pending from the last visit, the order has two objectives and needs more time allotted.

Access. Which sites need advance notice.

Grouping by zone, not by apparent urgency

A planning criterion that saves more than it seems and goes against instinct: when there are several non-critical interventions scattered around, it’s worth grouping them by zone even if that delays some of them by a few days.

Three minor visits to the same area done in one trip cost much less than three separate trips, and in dispersed operations that difference is the biggest lever available. To do this you need to see at once what’s pending and where it is, which comes from cross-referencing the calendar with the location recorded on each asset’s record.

The limit is obvious: anything with a committed deadline or risk doesn’t get grouped, it gets attended to. That’s why it matters to have priorities and maximum times per status set correctly, because they’re what determines what can wait and what can’t.

What to check when closing the week

Two things, and they take no more than ten minutes:

What was left undone, and why. If a type of inspection is systematically postponed, either the frequency is wrongly set or the intervention window doesn’t exist. Both are fixable, but only if it gets recorded — and for that you need to leave the order open with its reason instead of closing it as done.

How much the actual work deviated from the plan. This is what progressively sharpens the estimates for the following weeks.

The most expensive mistake

Closing orders as done when they weren’t, just to make the plan look completed.

It’s the easy temptation and it ruins the data: the percentage of plan completed will read 100%, corrective work won’t drop, and nobody will understand why. A postponed order with its reason attached is worth far more than one closed falsely.

In short: plan below capacity, reserve room for the unforeseen with a number instead of a hunch, check availability before generating orders, and make rescheduling cheaper than ignoring the plan. With those four, the plan survives the week.

If you’d like to see how planning would look with your own team, you can request a demo.