Planning the Shutdown You Get Once a Year
Everything that cannot be done on a running plant queues up for one window. The instrumentation and controls work in that queue fails for predictable reasons, most of them scheduling rather than technical.

A continuous plant gives you one window. Everything that needs the process stopped — the instrument that cannot be isolated, the controller firmware that requires a reboot, the cable pull through an area that is normally live, the tie-in for next year's project — waits for it. The list is written months ahead and is always longer than the window.
What goes wrong is rarely the technical work. It is the ordering.
The single most common failure is discovering a dependency during the shutdown rather than before it. The new transmitter needs a different impulse line; the impulse line needs a fitter; the fitter is scheduled for a different unit that day; by the time they arrive the isolation has been handed back. None of those steps is difficult. Together they consume six hours of a window that had four to spare. Writing down, for every task, what has to be true before it can start — which isolation, which permit, which trade, which part physically on site — turns the list into a sequence and exposes the tasks that cannot actually happen in the order someone assumed.
Parts are the second. A shutdown list that includes "replace the flow element" and a purchase order with a fourteen-week lead time placed nine weeks ago is a task that will not happen, and it is better to know that in week two than on the day. Every item on the list needs a physical location: on site, in the stores, with a serial number checked against the drawing. "Ordered" is not a location.
The third is that shutdowns are when latent faults surface. A plant that has been running for a year has motors that have not been stopped, valves that have not been stroked, and instruments whose readings have drifted together so nobody noticed. Stop everything and a proportion of it will not start again cleanly. Anyone who has done a few knows to reserve contingency for this, and the useful version of that reserve is not just time but people — a spare electrician and a spare instrument technician with nothing scheduled, because they will be needed and the alternative is pulling them off planned work.
For controls specifically, three habits pay off disproportionately. Take a verified backup of every controller program, HMI project and drive parameter set before anything is touched, and verify it by restoring one somewhere harmless — a backup nobody has restored is a hypothesis. Change one thing at a time where the schedule allows, because a controller that will not start after four simultaneous changes is a long night. And keep a written record of what was actually changed, as it happens, rather than reconstructing it afterwards; the reconstruction is always wrong in the one detail that matters in March.
Then the part most often skipped: plan the start-up as carefully as the work. A shutdown's success is measured by the plant running, not by the tasks being ticked. That means knowing the order in which systems come back, who confirms each one, what "confirmed" means for an instrument that has been recalibrated, and what the fallback is if something does not come back. Loop checks, alarm tests and interlock proving all belong in the schedule with time attached, and they are the first things compressed when the window slips — which is how a plant restarts with a protection function that nobody actually tested.
Last, capture the list for next year while it is fresh. Every shutdown generates a set of "we should have" observations that are completely obvious on the day and entirely forgotten eleven months later. An hour of writing in the week afterwards is worth more than any amount of planning in the week before.