Defining scope and success criteria

Many projects that go wrong were unclear from the start. Someone asked for “a new website” or “a better onboarding process”, the team started building, and three weeks later it became obvious that people had different pictures of the result. Defining scope means answering three questions in writing before planning: what problem are we solving and for whom, what will we deliver, and what will we deliberately not deliver. The last question matters as much as the first two, because unstated assumptions about what is included are a major source of later conflict.

Start with the outcome, not the output. The output is what the team produces, such as a redesigned checkout page; the outcome is the change it should cause, such as fewer abandoned orders. Write the outcome as one sentence, then list the deliverables needed to achieve it. Next, write an explicit out-of-scope list: items that someone could reasonably assume are included but are not, such as “mobile app changes” or “migrating old customer data”. Aim for at least three. If you cannot think of any, you have probably not looked hard enough at the edges.

Success criteria turn the outcome into something you can check. Good criteria are specific, measurable and time-bound: “checkout abandonment below 55 percent, measured over the four weeks after launch” rather than “a smoother checkout”. Include three kinds: outcome criteria (the business result), delivery criteria (deadline and budget) and quality criteria (what must be true for a deliverable to be accepted, such as accessibility checks passed). Agree who will measure each one and when. Three to five criteria are usually enough; with twelve, nobody remembers any of them.

Watch for common scoping mistakes. Defining the solution before the problem locks the team into one approach too early. Choosing criteria the team cannot influence, such as total company revenue, turns success into a matter of luck. Agreeing scope verbally with one stakeholder while others hold different expectations only postpones the argument until it is expensive. Finally, remember that scope is a baseline, not a contract carved in stone. When it changes later, change it deliberately through a change process, which you will set up in the last module, rather than through quiet additions.