Five mistakes teams make with project scoping

The version of this that works is simpler than the version most people imagine. These are the ones we run into repeatedly when we audit project scoping.

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Common failure modes

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Vague scope is the root of most budget disputes
• Write down what is explicitly out of scope
• Never checking whether the fix actually worked

Assumptions should be recorded, not held in someone's head. There is a version of this that is over-engineered, and it is worth avoiding. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Making it stick

How to tell if yours is fine

The projects that go badly are rarely the ones with the hardest technical problems. Three things worth confirming about project scoping before you move on:

• Someone can say what the current setup is without going to look
• Vague scope is the root of most budget disputes — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.