Project scoping: the questions we get asked most

There is no clever trick in this one, just a handful of decisions worth making deliberately. The questions about project scoping that come up most often on our calls.

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.

Do we need to care about this?

Vague scope is the root of most budget disputes. Small and consistent beats large and occasional here. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. It is worth being explicit about, because assumptions differ quietly.

How do we know it is working?

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.

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
• Assumptions should be recorded, not held in someone's head — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.