Scope Management: Why Four Pages Isn't Enough

Hey Friend 👋

Early in my career, I worked on a major track renewal at one of London's busiest sub-surface stations. The window was Christmas. The station had to reopen for Boxing Day services. No slippage. No second chances.

Our scope document? Four pages, half of it formatting.

Weeks before delivery, we realised what we'd missed. We knew about the civils work. But the associated electrical works in the subways? Completely overlooked. Lighting, PA systems, advertising displays. You can't reopen a subway without lighting.

We'd been asked: "How did you miss it?" The honest answer: we didn't break the scope down far enough, and that four-pager was filed away after kickoff.

That project taught me: scope isn't a document you file away. It's a living framework you build up as the project evolves.

We'd treated it like a formality. Create the four-pager, get it signed off, move on. But we never broke the work down properly. What looked simple on the surface had dozens of interconnected pieces. Miss one connection and the whole thing falls apart.

Here's what actually prevents those gaps:

• Break deliverables down: Techniques like Product Breakdown Structure (PBS) and Work Breakdown Structure (WBS) would have caught what we missed. PBS maps what needs to be built, WBS maps the work required to build it.
• Make it visible: Turn your scope into something the team can see and use. A diagram, a breakdown, something better than pages of text that get filed away.
• Document what you don't know: Note assumptions, "to be determined" items, and connections with other systems. Make uncertainties explicit early.
• Keep it alive: Review and update scope regularly, especially when new people join or when you learn something that changes the picture.

I've seen teams turn lengthy scope documents into single A3 diagrams. Suddenly people stopped asking the same questions about what was in or out. Clarity reduces mental load. When scope is clear and visible, people can focus on solving problems rather than constantly re-interpreting what they're supposed to be doing.

Next time you start a project: Don't settle for the high-level document. Break it down. Make it visible. And treat it as something that evolves with your understanding, not something you create once and file away.

What did you miss in your scope that came back to bite you? Hit reply. I read them all and often feature reader insights in future newsletters.

Want to go deeper? You can read more in the full deep-dive with examples on scope management, or try the Mindcast for hands-on practice making these calls in realistic PM scenarios.

Making things happen,
Bilal Jamil