The real cost of ignoring project scoping

It comes up on almost every project, usually later than it should. Nobody bills you for neglecting project scoping. The cost shows up somewhere else.

The projects that go badly are rarely the ones with the hardest technical problems. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Where the cost lands

• Time spent on work that should not have been necessary
• Enquiries that quietly never arrive
• Vague scope is the root of most budget disputes
• Rework, once the problem is finally visible

Write down what is explicitly out of scope. The reasoning matters more than the rule, because the rule has exceptions. If it only works because one person remembers to do something, it does not work yet.

Making it stick

Assumptions should be recorded, not held in someone's head. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What this looks like day to day

Clear scope protects the client at least as much as it protects the agency. 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

Pick the one that would hurt most if it failed, and start there.