"We've found one more critical job we really need to get done while we're down. It's only about 16 hours. Can we squeeze it in?"

The night before the outage, the list looked locked. Scope frozen. Schedule built. Permits and isolations drafted. Crews knew exactly where they were headed on Day 1. The planning team had finally let themselves exhale.

Then that email lands.

Nobody wants to be the one who says no to critical work the night before an outage. So after a quick huddle, the answer is yes.

Forty-eight hours later, Day 1 is a mess. Scaffolds moved twice. Permits rewritten. Two crafts stacked into the same tight corner. A critical-path task started late because the add-on tied up the isolations and the access.

How did a 16-hour job cost you most of a day? Because late changes don't just add work. They multiply complexity.

Not all scope changes are equal.

Add work months ahead and it stings, but you can absorb it. There's room to re-sequence, re-level the crews, redo the scaffold plan, rewrite the permits, and tell everyone long before a single boot hits the field.

A late change is a different animal. Made after scope freeze, or worse, after execution starts, it lands in a world where the resources are already committed, the scaffolds and isolations and permits are lined up, the work is sequenced tight to fit a narrow window, and operations and contractors have signed up for one specific plan. At that point you're not slipping in a task. You're rewriting a web of interdependent decisions under serious time pressure.

The visible cost is the labor on the new job. The invisible cost, the one that actually hurts, is the rework of access, permits, sequences, and risk controls that the change drags along with it.

Take that 16-hour job and look at what it sets off when it shows up late.

Permits and isolations have to be written, reviewed, and approved fresh, or extended and altered, and that pulls time from operations and safety people who are already committed somewhere else. Scaffold crews have to mobilize, build, modify, or relocate, which means yanking them off other work and sometimes throwing up a less efficient structure because they're improvising. The crafts you need are probably already allocated, so you either delay other jobs or push people into extended shifts and overtime, and fatigue and quality ride along with that. And the new job competes with critical-path work for the same systems, space, and support, so tasks that were supposed to run in parallel suddenly run in series while simultaneous-operations risk climbs.

Here's the number worth keeping in your head. Reliability data has long put emergency and unplanned work at three to five times the cost of the same work done as planned, once you count overtime, downtime, expedited parts, and secondary damage. A late change shoves otherwise-planned work into that quasi-emergency mode, and it carries the same multiplier. So the 16-hour decision quietly becomes dozens of lost hours, higher risk, and schedule creep.

Late changes aren't random. They feed on a few habits.

The soft scope freeze, first. The freeze date exists on paper, but everyone knows exceptions are always on the table, so nobody takes it seriously. Weak pre-work, second. When operations and engineering skip their own early scoping and risk thinking, real work surfaces late, right as the window gets real. The "just this once" culture, third. Leaders wave through critical items without ever feeling the complexity footprint, and every exception chips away at the discipline for the next one. And no pricing of change, fourth. Because the true cost of a late add never gets made visible, the decision-maker sees slack in the labor graph and assumes the work is basically free.

Leave those alone and a manageable event turns brittle. And brittle events handle surprises badly, which is a problem, because surprises are the one thing you can count on.

The goal isn't to kill all change. Plants are living things. You'll learn new information closer to the event, and some work will genuinely need to go in. Mature organizations don't chase zero change. They chase disciplined change.

A few principles carry it. Make the cost visible, treating every request like a mini business case that spells out not just hours and materials but the hit to permits, isolations, scaffolds, crafts, and critical path. Protect the critical-path windows hardest, because if you're going to pile complexity onto the spot where you're least resilient, you'd better do it with your eyes open. Reserve a little capacity for growth, an explicit five to ten percent of hours, so legitimate new work doesn't instantly overload a plan you pretended was perfect.

And tighten the approval bar as the event gets closer:

That escalating hurdle is exactly what the best STO organizations use, and most of them learned it the expensive way.

You don't need an elaborate system to get a grip on this. A few simple tools move behavior quickly.

A change request form that asks the right questions does most of the work. What's the risk if we don't do this now? What permits and isolations does it touch? What scaffold or access changes does it force? What crafts and hours does it need, and where are we pulling them from? Does it hit critical path or high-risk work? A visible change log in the war room does the rest, tracking the count of changes, the hours added, and where they cluster, so leaders can actually see how many "just one more" calls have already been made. Then a post-event review of changes closes the loop: which were truly necessary, which could have been caught earlier, and which you'd decline next time.

Make change structured and make its full cost visible, and people get a lot more selective about what they ask for and what they approve.

Late changes are one of the most powerful complexity multipliers in maintenance and turnaround work, and they're almost entirely self-inflicted. They show up exactly when your system is least able to absorb them, carrying a cost that dwarfs the hours on the job plan.

You can't eliminate them. You can stop treating them as free. Price the full footprint, hold the line with disciplined decisions, and your events get more predictable even when you have to adapt on the fly.

Next in the series, we cross back to the debt side and a fair question. We've spent these posts arguing that maintenance debt is real and that you can't manage what you can't see. So how do you actually see it? We'll get into measuring maintenance debt with a handful of simple indicators, no PhD required.