Abstract
Shutdown schedules are not forecasts. They are negotiated documents whose precision functions as a social signal rather than an engineering estimate, and almost everyone involved knows this while behaving as though it were not true. This paper argues that the lie is structural rather than dishonest, that optimization applied to unverified scope makes the problem worse rather than better, and that the cheapest fix in the whole of maintenance is a conversation held the day before.
Precision as a social signal
A shutdown schedule says a job takes eleven hours. Nobody believes eleven. The planner does not believe eleven, the supervisor does not believe eleven, and the crew certainly does not.
Eleven is there because a range would not survive the meeting. "Somewhere between eight and twenty, depending on what we find when we open it" is the honest answer and it is unusable in a document that has to sum to a window. So uncertainty gets converted into precision at the point where the number enters the schedule, and from then on it is treated as knowledge.
That conversion is the lie, and no individual tells it. It is produced by a document format that has no field for "we do not know yet."
The day before
Before I got into down-day planning, this happened constantly. Crews would get their locks on, walk to the job, and the parts were not there. Or nobody had told the next area their line was getting shut down.
Expensive down-day time, crews idle, unable to start.
My first fix was a band-aid and I am not proud of it, but it worked. I kept a stash of reserved backup work orders, filler jobs with no specific window, so I could throw a stalled crew at something instead of having them stand there. It became my permanent overflow stack for end-of-day work. It did not fix anything. It hid the cost.
The real fix was embarrassingly cheap. Start pulling the work orders the day before. Then I could confirm the parts existed and tell the other areas ahead of time. Pre-flight the day instead of discovering the gaps live.
That grew on its own into every area lead sitting in on the planning. Not taking it over. Sitting in, because we all have the same job, and it is a wonder how long that takes to sink in.
The day-before confirmation is the line between a schedule and a plan. A schedule is a list of intentions with times attached. A plan is a schedule whose assumptions somebody checked while there was still time to do something about them.
The most powerful fix for wasted time I ever found cost nothing. It was people talking to each other the day before. Everybody expects the answer to be software or a clever process. It is plugging the communication holes.
What the schedule cannot see
Three failures from one down day, and none of them appears anywhere in a scheduling tool.
We had three contractor crews swapping camelback chains on the log decks, three crews because the window had to be hit. On paper it was ready. Chains staged, torches out, crews onboard.
There was one crane. Nobody had thought about it. Three crews and one crane means somebody is always waiting to fly their chains up. They had two torches on the assumption three crews would share, and competing contractors do not share. The lockout crawled because three companies meant the isolation run three times over on a deck packed with bodies.
A crew that was behind and rushing hooked the crane straight to a chain instead of pulling it properly, caught the catwalk, and ripped thirty or forty feet of it out of the building.
The better part of a month, out of a day that looked good to go.
The smaller version of the same disease is almost funny. We planned to use the one skid steer for a waste-conveyor changeout. Went to do the job and it was gone. Production had it for down-day cleanup, because of course they did, and nobody had reserved it.
Every one of those is a dependency the schedule does not model. Scheduling software models task durations and predecessor relationships. It does not model one crane wanted by three crews, two torches given to companies with no reason to cooperate, or a skid steer that another department considers theirs.
After that day we built an asset-reservation system and started running real down-day meetings with the area leads and crews in the room. Reserve the iron the same way you reserve the window.
The failure that is invisible on any chart
There is one more, and it is the one no system will ever catch.
Down day, a crew on a deck changing out a set of rails. Big, heavy, worn-out things. I came up at coffee and they had been there for hours and done nothing. Nothing. They told me the rails were too heavy, they could not do it, so they had just sat there and waited.
They did not call anybody. They did not try another way. They did not flag it.
On a Gantt chart that job is in progress. The bar is the right colour. Nothing anywhere shows that the window is bleeding, and it will not show until somebody reports at the end of the day that the job did not get done.
Which is the argument against believing the schedule is the plant. On a down day you have to be on your feet running a circuit through your crews, because a stuck crew will not come and find you, and the cost of a crew quietly parked is invisible until you walk up on it.
Two different AI opportunities, routinely confused
Shutdown planning has two of them and vendors blur the line.
Scope construction asks what work belongs in the event and what each package actually requires.
Schedule optimization asks, given the work and its dependencies and resources, what sequence performs best.
Almost all shutdown failure happens before optimization is relevant. Incomplete scope, false durations, missing materials, undiscovered access conflicts, and work packages that restate the notification instead of planning the job.
AI schedule optimization cannot rescue fictional input. Optimizing a schedule built on eleven hours that everybody knows is really eight-to-twenty produces a beautifully sequenced fiction, and it is worse than the ugly version, because a plausible schedule is harder to argue with.
Vendors are moving into scope construction, which is the right direction. IAMTech markets generation of steps, trades, crew sizes, labour estimates, durations, materials, costs and confidence scores from work descriptions, drawings and documents. Prometheus describes AI-guided event setup drawing on historical turnarounds and ERP revision data. ALICE focuses on generating and stress-testing alternative schedules against time, cost and resource constraints.
Treat all of that as vendor description rather than independent validation. And ask the question that separates the useful from the impressive: what source evidence accompanies each generated duration? A confidence score computed from the model's own certainty is the same lie in a new font. A duration traceable to three comparable historical jobs, with their variances shown, is something a planner can argue with.
What honest scheduling looks like
Three changes, none of them software.
Carry ranges into the schedule, not point estimates, at least for the jobs whose scope was never verified. A window built from ranges is wider and true. A window built from points is narrow and fictional, and the difference gets paid at three in the morning.
Model shared resources as first-class objects. Cranes, torches, scaffold crews, skid steers, isolation capacity. If it can only be in one place, it belongs in the schedule as a thing that gets reserved.
Record which durations were verified and which were guessed. This costs one field. It also tells you, after the event, whether you have an execution problem or an estimating problem, and most plants have been calling the second one the first for years.
The day nobody remembers
I once tried to think of a great story about a down day that went perfectly, and I could not.
The good ones do not get remembered. Changed the bearing, parts staged, lockout done, everybody knew, handed it back early, went home. The end. Nobody tells that one at the bar.
The oilfield was often like that. You were handed a box with every part you could need, rarely wrong, so the work just went. That was not luck. It was a system built right.
A perfectly planned day is boring, and boring is the scoreboard. The goal of designing maintenance is to make it unremarkable, and the positive proof is not a war story, it is the absence of one.
Which is exactly why this is hard to fund and hard to sell. The schedule that did not lie produces no anecdote, no heroics, and nothing to point at in a review. The schedule that lied produces a month of stories, three of which will be told for twenty years.
Keep one distinction clean, though. Improvising for a genuine unforeseeable freak is craft. Improvising because nobody planned is failure. In a well-built system the only thing left to improvise is the real one-off.
Conclusion
Shutdown schedules lie because the document format converts uncertainty into precision, because the shared resources that actually break the day are not modelled, and because the only person who knows a job is stuck is standing on a deck with no reason to phone anybody.
None of that is fixed by optimization, and optimization applied on top of it makes the fiction more persuasive.
It is substantially fixed by pulling the work orders the day before, confirming the parts, telling the other areas, and putting the people who know the equipment in the room. That is not a product. It is a conversation, and it remains the cheapest thing in this entire series.
References
- IAMTech, “iPlanSTO / AI-powered planning & work pack generation.” https://go.iamtech.com/iplan-turnaroundinsurance/
- Prometheus Group, “From Hours to Minutes: How AI Is Transforming Maintenance Planning and Scheduling,” June 26, 2026. https://www.prometheusgroup.com/resources/posts/from-hours-to-minutes-how-ai-is-transforming-maintenance-planning-and-scheduling
- Misra, Vyas, Gutta & Mercangöz, “ADMITBench: A Safety-Governed Reference Framework for Evaluating the Admissibility of Industrial LLM Advisories,” 2026. https://arxiv.org/abs/2608.03866
- Crespo-Márquez & Gómez Fernández, “Agentic AI for maintenance management: a process-centric review and a staged framework for industrial adoption,” Computers & Industrial Engineering, 2026. https://www.sciencedirect.com/science/article/pii/S0360835226004869