Getting started with project scoping
We end up explaining this on discovery calls often enough that it deserved writing down. A short on-ramp to project scoping for teams who have not touched it before.
The projects that go badly are rarely the ones with the hardest technical problems. If it only works because one person remembers to do something, it does not work yet.
Why this earns attention
Vague scope is the root of most budget disputes. In practice this is a scheduling problem more than a technical one. It is the sort of thing that looks like polish right up until it costs you an enquiry.
Your first week
- Find out what is already in place
- Write down what is explicitly out of scope
- Change one thing and measure it
Assumptions should be recorded, not held in someone's head. It is worth being explicit about, because assumptions differ quietly. If it only works because one person remembers to do something, it does not work yet.
In practice
Strategy work is mostly deciding what not to do, and writing it down so it stays decided. 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.