Spend enough time around turnarounds and you've heard this one:

"While we're in there, can we just add one more job?"

On paper it looks harmless. A 12-hour task on a pump or a valve. The labor curve barely twitches. The hours fit the window. The schedule owner hesitates, asks a question or two, then says yes.

Two weeks later that "small" job has driven an extra scaffold build, a second round of isolations, a permit rewrite, two crafts reshuffled, and a half-day slip on a critical-path system.

So how did a 12-hour task eat three days of your schedule?

Because scope isn't a list of jobs. It's where complexity is born.

We tend to treat scope like a grocery list. Line items, hours, priorities. If the total fits the window and the resource curves look sane, we tell ourselves the scope is about right.

But the complexity of an event isn't driven by how many jobs you've got or how the hours add up. It's driven by the shape of the scope. Which assets. Where they sit. How many crafts and vendors it takes. How much enabling work and interference the jobs create for each other.

Two events with identical hours can feel like completely different animals in the field. One flows. The other is a street fight from Day 1. That difference almost never lives in the spreadsheet. It lives in how the scope got built.

Look at real events through a complexity lens and the same handful of factors keep showing up.

Work mix is the first. Ten thousand hours of inspection and cleaning is not the same animal as ten thousand hours of heavy rotating overhauls. Different mixes stress different parts of the organization: tooling, specialist skills, QA, vendor support, and start-up risk. Load a scope with heavy mechanical and E&I modifications and you've built a very different event than one full of inspections and light repairs, even when the hours match to the minute.

Spatial clustering is the second. Where the work happens matters as much as how much of it there is. Thirty jobs spread across the plant is nothing like thirty jobs crammed into one congested unit. Stack too much into one area and you overload access routes, set crafts tripping over each other, drive up simultaneous-operations risk, and start a turf war over scaffolding, cranes, and rigging. The schedule sees "work in Area 100." The field sees a coordination knot.

Access and enabling work is the third, and it's the one that hides best. Some jobs drag a lot of baggage in behind them: scaffolding, insulation, civil repairs, temporary power, confined-space controls, special lifts. Stare only at the direct labor estimate and you miss the downstream footprint. The complexity was never in the 12 hours of wrench time. It was in the scaffold, the permits, and the interference.

Risk concentration is the fourth. How much high-risk work are you packing into one window? Critical-path repairs, invasive inspections, and modifications all fight over the same senior people, the same QA attention, the same operations support. Run too many in parallel and the odds climb that one slips and drags the others down with it.

Here's the mental model worth keeping. Every job has two sizes.

There's the size you see in the planning system: hours, craft, duration. And there's the size it actually takes up in the plant: access, constraints, risk, and the way it bumps into everything around it.

Build scope as if jobs are independent and you only ever see the first size. You read a list, add the hours, and assume the sum tells the truth about the work. It doesn't. Some jobs cast a much bigger shadow than their labor line suggests. More enabling work, more concurrency, more ways for the jobs around them to slip. Add a few of those big-shadow jobs into one area and complexity doesn't add up. It multiplies.

That's why "one more job" on a congested system can hurt you worse than five jobs scattered across simple ones.

Treat scope like a loose shopping list and a few familiar patterns show up every time.

Creep, first. Everybody tries to sneak their work in under the flag of efficiency. We're already down, so let's do it all. Late add-ons, second. Work gets added late, with almost no read on

its downstream footprint. And reactive de-scoping, third. As the window closes in and reality lands, teams start hacking scope under pressure with no real grip on the risk, or the maintenance debt, they're creating.

On the surface, all three look like decisions about hours and dates. Underneath, they're decisions about complexity. You're either cramming it into a narrow window or shoving it into the future. Either way, the bill comes.

You don't need exotic software to treat scope as a design problem instead of a shopping trip. A handful of disciplined moves carry most of the weight.

Shape scope early, before detailed planning, in sessions that look at the work by system and area, by work mix, and by enabling work. The question isn't "do we have all the jobs?" It's "where are we building hotspots?" Tag the complex work explicitly: the jobs heavy on enabling work, multi-craft interference, or risk, flagged so you can see where they cluster. Set the rules for add-ons up front, so new work on a critical system past a certain date triggers a quick impact check on access, permits, and scaffolding instead of a shrug. Map the work density in the plant, because a simple area plot will surface hotspots your spreadsheet keeps hidden. And document every conscious deferral, with the reason and the risk you're accepting, which turns accidental maintenance debt into a choice you can actually track.

This is the work we tend to do alongside clients before a single job pack gets finalized. Not adding process for its own sake. Looking at scope as a shape, finding the hotspots while they're still cheap to move, and making the add and de-scope calls on purpose rather than under pressure at the worst possible moment.

Most of the complexity you fight during execution isn't a surprise. It's the downstream effect of scope decisions made months earlier, framed in hours and budget instead of complexity and risk.

Treat scope as the birthplace of complexity and the question changes. You stop asking "can we squeeze in one more job?" and start asking "what does this job really cost us in complexity, and is it worth it, here, now, in this window?"

Next in the series, we stay on that last point. Every late add and every quiet de-scope is also a deposit into your maintenance debt. We'll look at how that debt actually gets created, one reasonable decision at a time, and how to make those calls deliberately instead of by default.