Slip on ‘project scoping’ and soon you will end up in ‘project coping

— #ProjectManagementTweet, Himanshu Jhamb & Guy Ralfe (2010)

One of the best-kept secrets on any project is this: everyone hopes — and says — that deliverables will land on scope and on time. And everyone, including the client, knows that it almost never does. It always costs more and takes longer than planned — a rule I wrote about last week [link to Week 2 post to be inserted].

Delays don’t wait politely for the project to start. They begin before the ink on the SOW is dry. I don’t say that despondently — quite the opposite. No matter how carefully scope is negotiated upfront, teams start out behind. Not because anyone did a bad job, but because of two things: the number of unknowns still hiding in the requirements, and the skill of the “scope-controllers”.

By “scope-controllers,” I don’t just mean the team on the delivery side managing scope. I mean the team on the client side too — how good are they at negotiating scope upward, with their own leadership? That’s where the real skill lives. And it’s why the strongest engagements I’ve run were built on one foundation with my counterpart on the client side: we were either going to succeed together, or fail together. Everything else about the project would change over the course of delivery. That part never did.

Here’s what that looked like in practice.

The War Room

We called it the War Room, for reasons that were never subtle. On this particular afternoon, it had two teams in it, both right, and getting nowhere. Engineering was on one side of the table, the PMO on the other, and the conversation had the particular heat of two groups who each understood their own half of the problem perfectly and couldn’t hear the other’s.

The issue was a piece of functionality that had looked straightforward in the requirements and turned out, once the engineers were actually inside it, to be genuinely hard to deliver in the timeframe we’d committed to. This wasn’t anyone dropping the ball. The complexity hadn’t been visible until we were mid-build — there was no realistic way anyone could have caught it at the scoping stage. As far as the room was concerned, it was an unsolvable problem. Not unsolvable in the abstract. Unsolvable by the people currently in that room, arguing about it.

Taking It Offline

I stepped in — not with an answer, but with a redirection. I asked the PMO lead to stop trying to solve it inside the four walls of the War Room and take it to the client instead.

We got on a call with the client team. Thirty minutes, no more. We laid out exactly what we’d found, when we’d found it, and why it hadn’t shown up earlier. No hedging, no softening it into something more palatable than it was.

The client’s response surprised the room, though it probably shouldn’t have. They asked for a day to talk it over internally. When they came back, they came back with a reduced scope — something that fit inside the timeline we’d already committed to, and something they could live with. Nobody blew up the plan. Nobody blew up the relationship.

What I Took Away

Two things stayed with me from that afternoon.

The first: a PMO team should lock down scope as early and as tightly as it possibly can — and hold, at the same time, the quiet certainty that scope will still move. Not because the process failed, but because some percentage of any complex build is genuinely unknowable until you’re inside it. Planning for zero scope movement isn’t discipline. It’s denial.

The second lesson is less about scope and more about judgment: not every problem belongs to the team that discovered it. The client is part of the team too, whether the org chart says so or not. Experienced teams know the difference between a problem worth fighting through internally and a problem that needs to go back to the client to solve jointly. Mistaking one for the other is how a hard-but-fixable issue turns into a War Room argument that goes nowhere.

That’s the piece I keep coming back to from that call: the client didn’t have to be generous with us. They chose to be, because the relationship going into that conversation was already built on the idea that a bad outcome would be shared, not assigned. Scope will always move, and timelines will always feel the effects of it. The teams that survive that reality aren’t the ones with the tightest contract. They’re the ones who never stopped being on the same side.

If your programme has hit a wall that no one inside your own team can solve alone, I’m happy to talk through it — sometimes the fastest way through is admitting the problem belongs to more people than you first thought.