Scope and requirements

Why it matters

Most project arguments are really arguments about scope. The sponsor thought "website" included a donor portal; the team thought it meant three pages. Writing scope down, including what is not included, is the cheapest risk control a project has. It also gives you something to point to when new requests arrive halfway through.

Requirements vs scope

• Requirements describe what the result must do or be, from the point of view of the people who will use it: "Volunteers can sign up for a shift on a phone in under two minutes."
• Scope describes the work and deliverables the project will produce to meet those requirements, and the boundaries: what is in, what is out.

Good requirements are specific and testable. "The site should be fast" is not testable. "Pages load in under three seconds on a typical phone connection" is.

To gather requirements, talk to the people affected (interviews, short workshops), watch how the current process works (the paper sign-up sheets), and look at existing documents. Write them down in the users' words, then confirm them back.

The scope statement

A scope statement is a one- or two-page document, agreed with the sponsor during planning. A practical structure:

1. Objective: one sentence on what the project achieves and why.
2. Deliverables: the concrete things handed over.
3. Acceptance criteria: how the sponsor will decide each deliverable is done.
4. Exclusions (out of scope): things people might assume are included, but are not.
5. Constraints: fixed limits such as deadline, budget, technology or regulations.
6. Assumptions: things believed true but not confirmed. If one turns out false, scope may need to change.

A worked example

Objective
  Replace paper volunteer sign-up sheets with a mobile-friendly website
  by 1 March, so the coordinator spends less time on phone calls.

Deliverables
  1. Public site: home, shift calendar, sign-up form, contact page.
  2. Coordinator admin screen to add shifts and export sign-ups to CSV.
  3. Email confirmation to volunteers after sign-up.
  4. A 2-page coordinator guide and one 60-minute training session.

Acceptance criteria
  - A volunteer can sign up for a shift on a phone in under 2 minutes
    (tested with 5 volunteers).
  - The coordinator can add a week of shifts in under 10 minutes.
  - Pages meet WCAG 2.2 AA colour contrast.

Exclusions
  - Online donations or payments.
  - A mobile app (the site works in phone browsers).
  - Migrating old paper records.
  - Support after 31 March (handled by the food bank's IT volunteer).

Constraints
  Budget USD 4,000; launch by 1 March; must use the existing web host.

Assumptions
  The food bank provides logo, photos and shift times by 15 January.

The exclusions list is the most valuable part. "Online donations" is there because someone will ask for it.

Scope creep and change control

Scope creep is uncontrolled growth in scope: small additions, each reasonable, that together break the schedule or budget. "Could it also send SMS reminders?" "Can volunteers pick a T-shirt size?" Creep often comes from good intentions, including the team's own "gold plating" (adding unrequested extras).

The answer is not to refuse every change. Projects learn things, and some changes are worth it. The answer is change control:

1. Write the request down (a short change request).
2. Assess the impact on scope, time, cost, quality and risk.
3. The sponsor (or a change board, on larger projects) decides: approve, reject or defer to a later phase.
4. If approved, update the scope statement, schedule and budget, and tell everyone.

For example, SMS reminders might add three days and a monthly messaging fee. The sponsor can then make an informed choice instead of the team silently absorbing it.

In agile projects, the same idea shows up as a prioritised backlog: new ideas go into the backlog, and the product owner decides what is worth doing next, within the fixed time and budget.

Common mistakes

• No exclusions, so every assumption becomes an argument.
• Untestable acceptance criteria such as "user-friendly".
• Saying yes in the hallway: agreeing to changes informally without assessing impact.
• Scope written by the team alone, without the sponsor's sign-off.

Quick recap

• Requirements say what the result must do; scope says what the project will deliver and where the boundaries are.
• A scope statement has an objective, deliverables, acceptance criteria, exclusions, constraints and assumptions.
• Scope creep is uncontrolled change; change control makes every change a visible decision.

Try it

Open the Do tab and write a scope statement, with at least four exclusions, for a small project of your own.