Project scoping, explained without the jargon

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. Here is project scoping without the vocabulary that usually surrounds it.

Clear scope protects the client at least as much as it protects the agency. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

The short version

Vague scope is the root of most budget disputes. The reasoning matters more than the rule, because the rule has exceptions. If two people in the business would answer this differently, that gap is the actual problem.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The reasoning matters more than the rule, because the rule has exceptions.

Write down what is explicitly out of scope. This is the sort of thing that compounds, quietly, in both directions. Budget a little time for it every quarter and it never becomes a project of its own.

What to do next

Assumptions should be recorded, not held in someone's head. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is the sort of thing that looks like polish right up until it costs you an enquiry.

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
• Write down what is explicitly out of scope — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.