Project scoping for small teams

The advice here is unglamorous, which is probably why it gets skipped. Most advice about project scoping assumes a team that does not exist at your size. Here is the version that does not.

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

What to keep

Vague scope is the root of most budget disputes. The reasoning matters more than the rule, because the rule has exceptions. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Where this goes wrong is almost never a lack of knowledge.

What good looks like

Assumptions should be recorded, not held in someone's head. Getting it slightly wrong is survivable. Ignoring it entirely is not. Write the reasoning down alongside the decision, because the reasoning is what changes first.

How to tell if yours is fine

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
• 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.