Planning a Shutdown Against a Hard Window, Buffer and All

The Problem

A planned shutdown — a valve tie-in, a process isolation, a main cut-over — is a race against a clock somebody else set. Customers can be out of water for so long, the tanks hold so many hours, the lane closure ends at dawn. The work is a serial chain of steps that mostly can't overlap, and the honest question the night before is not “can we do it?” but “does it fit, with room for the thing that goes wrong?” I wanted to lay the steps on the clock and get a straight go or no-go.

The Approach

You list the steps in order with a duration each, set the maximum allowable out-of-service window, and add a contingency buffer as a percentage of the planned time. The tool sums the serial durations, stamps each step with its start and end clock time (rolling past midnight with a +1d), and compares the committed time — planned plus buffer — against the window. The verdict is a go/no-go with the slack, and a timeline draws the steps end to end with the buffer appended and the window marked, so an overrun is a bar crossing the line, not a number you have to interpret.

The planner: eight sequenced steps with clock times, a GO verdict with 1 hour to spare, and a timeline where the step bars and gold buffer bar land just inside the 8-hour window line
Figure 1: An eight-step valve replacement — 5:50 of work plus a 20% buffer commits 7:00 of an 8-hour window. GO, with an hour to spare.

The buffer lives inside the window

The one discipline the tool is built to enforce is that the contingency buffer belongs inside the window, not outside it. Serial work has no float of its own — every step waits for the one before — so the reserve for the valve that won't seat, the coupling that's the wrong size, or the pipe that turns out to be a different material than the record drawing claims has to be planned time, sitting between the last real step and the deadline. Squeeze it to make a too-long job “fit” and you've simply deleted your only response to the overrun you should expect. And some steps can't be compressed at all no matter the manpower: a pressure test holds for its full duration, sample results come back when the lab runs them, the inspector arrives when they arrive — so the tool lets you flag those as hold points.

Planning notes
  • Set a go/no-go decision time — the point of no return where, if you're not at a given step, you abort and restore service on the old configuration rather than run past the window.
  • Have a real plan B for restoring service: temporary connections, a bypass pump, a valve that lets you re-pressurize the old alignment. “We'll hurry” is not a contingency.
  • If the committed time doesn't fit, the answer is to phase the work across two shorter shutdowns, bypass so service continues, or move the constraint — not to shave the buffer.
  • The return-to-service steps have their own tools: flushing and disinfection take real, plannable time. Put them in the sequence.

It's a single static file, vanilla JS, everything persisted in localStorage and nothing leaving the browser — and it slots in with the other project-controls tools like the look-ahead Gantt, just at the scale of one long night instead of two weeks.

The tool: Shutdown Window Planner.

References

  1. [1] The utility's / owner's shutdown and outage procedures, and the customer-notification or boil-water policy that sets the allowable duration (governing).
  2. [2] Companion field tools: pipe flushing and chlorine dosing for the return-to-service steps.