This transcript was produced by robots and left as-is. Accuracy and elegance are not guaranteed.

“We thought you guys were doing that.”

That’s what we heard near the end of a shutdown. We were just getting ready to start testing and commissioning the control system. And when we asked the electrical contractor whether the instrumentation was set up yet.

You guys. They meant us, the engineers doing the automation work. Well so when we asked, they said no. And that’s when the trouble started. There was no one on deck to tackle this one.

Now, this is the third episode in a row about failures that never set off an alarm. In episode 39, it was decisions you made by not acting. So there was never anything to review. In episode 40, it was feedback that stopped coming because bringing it forward cost too much.

That’s the one where I used an HMI alarm scenario or example for the alarm that gets acknowledged but never cleared. This episode is about the assumptions at the boundaries between scopes.

These ones don’t even make it into the alarm list because no one ever configured them as an alarm.

I didn’t plan these three as an arc, but as I worked through them, I could see the pattern forming.

Setting up and configuring the field instruments wasn’t in our scope. We were there for the automation and control systems work. We weren’t instrument techs.

But the control system was useless without the instruments, and startup wasn’t going to wait around while someone checked the scope document. So we took care of it. I pulled another person onto the job.

It was almost a full day of effort that nobody had planned for. But it kept the schedule intact.

And nobody on our side had wondered about it beforehand. We showed up to test and commission systems that connected to those instruments, and it never occurred to us to ask.

So why did we walk in so certain? Because our work only made sense if theirs was done. We considered setting up the instrumentation to be part of the scope, their scope. So our brains filed it as done. It was a fact instead of a guess. It’s like control logic pointing to a transmitter that nobody has set up and ranged.

The logic has no way to tell the difference. It runs on a signal, it assumes it’s good, until the process proves it wrong.

This problem came up because the work sat right on the boundary. It was adjacent to two scopes, and it wasn’t inside either one. The electrical contractor thought it was ours, and we thought it was theirs. And the client, they didn’t even know the work existed. They were paying for a plant that ran at the end of the shutdown. And that’s the only part that they could see.

The same gap can show up for other reasons. On another job, everyone assumed the plant’s instrument tech would take care of setting up the instrumentation.

And that was the whole plan going in.

Then we learned he only worked on maintenance jobs and we were executing a capital project. We had the same scramble during commissioning, with different people pointing at each other, but no actual solution. The first time, the assumption was that it was in someone else’s scope. The second time, it was that a particular person owned that. Different reasons led to the same scope gap.

That’s a pattern, not a one-off.

So why don’t people ask even when they do wonder? I’ve seen this time and time again. Sometimes asking sounds like an accusation. Is anyone handling the instrument setup? That can come across as, I don’t think you’ve done your job. Other times, the person asking knows they’ll probably inherit the work.

The question gets asked and the answer comes back, hey, good catch. Do you think you can take that on? Most engineers have seen that happen. So staying quiet protects your budget as much as your ego.

On that first job I described, my contingency covered the extra effort. But that’s not what the contingency was meant for. I built it in for problems that were inside of our own scope, the one that we defined at the beginning. It wasn’t meant for work that nobody had priced, accounted for, or planned.

The problem is that the client never saw that gap.

So nobody had a reason to raise it on the next job. And that included me.

Absorbing that cost, it felt like the professional thing to do.

We were looking to make sure it was a successful project. In practice, it deleted the only evidence that the gap ever existed.

So what can you do about it? How do you turn this from an accusation into a standard operating procedure?

At kickoff or handoff, list every point where your work depends on someone else’s and ask who’s taking care of each one. When it’s an item on a checklist, it’s a scope confirmation, not finger pointing.

And when you ask, be ready with a price. Understand what that work would cost and have it priced and ready to go. That way, if it turns out to be on nobody’s list, it becomes a change order instead of unpaid work.

And if you do end up eating that work, the way I did on the first job, report it anyway. Write it down so the client understands the cost, even if they don’t pay it. That way, there’s evidence for you and for them on the next job.

So pick a project you’re working on this week. Find one boundary where your work depends on someone else’s and ask who owns it before startup forces the answer.

We thought you guys were doing that one. When’s the last time you heard that?