Presentation Tips for Maintenance Managers: Planned Downtime

By Daniel Harper · Career & Business

How should a maintenance manager present the case for planned downtime? Show production the cost of the breakdowns the work would prevent, in their terms: lost hours, missed orders, overtime. Present planned work as a schedule they helped shape, not a demand. For shutdowns, plan from how long past shutdowns actually took, not from the ideal plan, because estimates for our own work are reliably too optimistic.

A maintenance manager's presentations are mostly arguments about time: time to take equipment down for planned work, time a shutdown will take, time a repair needs. Production wants the equipment running; maintenance knows it will run longer if it is looked after. The presentations that win that argument make the cost of not doing the work as visible as the cost of doing it.

Make the cost of breakdowns visible

Production managers feel every hour of planned downtime, because it is on their schedule. They feel breakdowns too, but the link to skipped maintenance is often invisible. Make it visible:

  • The last year of unplanned downtime on the key assets, in hours and in lost output.
  • The share caused by failures that planned maintenance would likely have caught.
  • The cost in overtime, missed orders, scrap and emergency repairs.

Then compare it with the planned downtime you are asking for. "Last year this line lost 61 hours to unplanned stops, 40 of them from failures our inspections would have caught. We're asking for 24 hours of planned downtime across the year."

Plan the schedule together

Planned maintenance presented as a demand gets resisted. Presented as a schedule production helped shape, it gets protected. Bring the maintenance plan to the production planning meeting, show what needs doing and how long, and ask when it causes the least disruption. A slot production chose is a slot production will defend.

Shutdowns: plan from what actually happened

Major shutdowns are the presentation maintenance managers most often regret, usually because the duration was promised too confidently. There is a well-documented reason for that.

Roger Buehler, Dale Griffin and Michael Ross found that people's predictions of how long their own tasks would take were reliably too optimistic, and that they focused on how the task would go rather than on how similar tasks had gone before. When people were asked to connect their predictions to relevant past experience, the optimism disappeared.1

For a shutdown plan, that means:

  • Start from history. How long did the last three similar shutdowns actually take, against their plans?
  • Present a range, not a single finish time, and name what would push it to the long end (a part that arrives late, a problem found once the equipment is opened up).
  • Say when you will know more: usually once the equipment is opened and inspected.

A shutdown presented as "five to seven days, most likely six, and we'll confirm on day two" protects your credibility far better than "five days" followed by a quiet extension.

Reporting to leadership

Leadership wants maintenance in the language of the business: reliability of key assets, maintenance cost against budget, the backlog of work and the risk it carries, and what you need. Show the trend of planned against reactive work; it is one of the clearest signs of whether maintenance is getting ahead or falling behind.

Briefing your own team

The maintenance team needs a different presentation: the week's priorities, the safety focus (especially isolation and lockout), and what went wrong last week. Keep it short, practical and two-way. Technicians often know which assets are about to fail before any report does.

For the interview version of these situations, see behavioral interview questions for maintenance managers. For presenting a date you are not sure of, the approach in presentation tips for software development managers works for shutdowns as well.

References

  1. Buehler, R., Griffin, D., & Ross, M. (1994). Exploring the "planning fallacy": why people underestimate their task completion times. Journal of Personality and Social Psychology, 67(3), 366–381. https://doi.org/10.1037/0022-3514.67.3.366