A one-page project scoping note that guides decisions

Name the problem

A one-page scoping note aligns decisions before anyone details features. Start with the observable problem: who is affected, which task is difficult today and why the current way of working is no longer satisfactory.

Avoid presenting a solution as the need. "Reduce duplicate entry" leaves several options open; "build a dashboard" already chooses a format without showing that it addresses the problem.

Describe the intended outcome

State what users should be able to do when the project is delivered. Add one or two verifiable signs of success: a task completed end to end, information available at the right time or a manual step removed.

If there is no baseline measure, say so. The note can explain how to obtain one; it does not need an invented percentage to sound persuasive.

Set the scope

List what belongs in the first release, what can wait and what is explicitly excluded. Note tools to connect, required data and known constraints without turning the page into a full specification.

Record open questions instead of hiding them. Dependence on access, content or a business decision may change the schedule and should be visible from the start.

Define acceptance

Explain how people will know a deliverable is acceptable. A user might need to complete a journey without help, a sample of data might need to be correctly restored, or a message might need to arrive after a form is submitted. These criteria can be expanded in the project specification.

Decide who tests and when. A deliverable is not accepted just because it is technically accessible; it has to produce the intended result.

Name the decision-makers

Identify the sponsor, the person who sets priorities, the person who provides information and the person who accepts delivery. If one person fills several roles, make that explicit.

Add the date of the next decision and where decisions will be recorded. A useful scoping note also states who may change the scope.

Use the note

Review this page at launch and whenever something important changes. If the need or scope evolves, update the note before changing the team's tasks. Its value comes from a shared decision, not its layout.

• State the problem before the solution.
• Define the outcome, scope and exclusions.
• Write verifiable acceptance criteria.
• Name decision-makers and open questions.