Scoping and Gathering Requirements

What a Project Is, and What ‘Done’ Actually Means gave you a definition of done — a clear, agreed picture of the finished result. But before you can define done, you have to answer a more basic question: done with what, exactly? A goal like “improve the customer experience” or “fix the ordering system” could mean a hundred different things. Left unspecified, everyone fills the gap with their own version — and you discover the mismatch only when you deliver.

This page is about closing that gap before you commit any effort. It has two halves that work together. Scope is the fence around the work: an explicit statement of what is included and what is not. Requirements are what you learn by asking the right people the right questions — the specific, testable needs the work must satisfy. Get these two right and most of a project’s chaos never happens. Get them wrong and no amount of hard work later can fully rescue you.

Scope is a fence, and a fence has two sides

Think of scope as drawing a fence around a piece of land. The fence says: this is the work, and that over there is not. People instinctively focus on the first side — listing what the project will do. But the more valuable side of the fence is the one nobody wants to write down: what the project will not do.

Here is why the “out” side matters so much. An unstated exclusion is not really excluded — it is just undiscussed, and undiscussed things drift inward. If you build a new booking system for a clinic and never say “this does not include migrating the ten years of old paper records,” half the staff will assume it does. They will be surprised and disappointed at handover, and you will be blamed for a promise you never made — because you never said the opposite out loud.

So a real scope statement has two columns:

IN SCOPE                              OUT OF SCOPE
- New online booking form             - Migrating historical paper records
- Email confirmation to patient       - SMS/text reminders (later phase)
- Staff view of the day's schedule    - Billing and payment
- Works on phone and desktop          - Integration with the lab system

The right-hand column is not an admission of laziness. It is a gift to everyone involved: it tells them precisely where their expectations should stop, so nobody is quietly counting on something you were never going to build.

In practice — the cafe’s new menu

A cafe owner asks a small team to “redo the menu.” One person starts designing a printed card. Another starts costing new dishes. A third assumes it means an online ordering page. Three weeks in, they realize they have been doing three different projects. A single scope line at the start — “In scope: redesigned printed menu and updated prices. Out of scope: new dishes, online ordering” — would have pointed all three at the same fence. Scope is cheap to write and expensive to skip.

Requirements come from people, not from your imagination

Once you know roughly where the fence goes, you need to know what the work inside it must actually do. Those specifics are called requirements. The single most important thing to understand about requirements is where they come from: from the people who will use or be affected by the result — not from your own guess about what they need.

This sounds obvious, and almost everyone violates it. It is far easier and more comfortable to sit at your desk and imagine what users want than to go and ask them. But your imagination is built from your experience, not theirs. The nurse who will use the booking system all day knows things about the ward’s real workflow that you cannot invent — that patients often call to change appointments, that the front desk is chaotic at 8am, that the current system logs everyone out after five minutes. You learn these only by talking to them.

The people you talk to fall into two groups worth naming:

• Stakeholders — anyone with an interest in the outcome: the person paying for it, the manager who requested it, the department it affects, sometimes a regulator or a partner. They shape why the project exists and what “success” means to them.
• Users — the people who will actually touch the result day to day. They know the messy reality the thing has to survive in.

A common failure is talking only to stakeholders (who describe the vision) and never to users (who know the reality), or the reverse. You need both, and their answers will often disagree — which is itself valuable information you want before you build, not after.

The common trap — building for the customer in your head

The seductive trap is the imagined user: a tidy, reasonable person who wants exactly what you find interesting to build. Real users are messier and their priorities are frequently surprising. Teams that skip the conversations don’t skip the requirements — they just invent them, and pay to correct the invented ones later. The fix is humble and cheap: before you commit to building anything, go and have a small number of real conversations with the people who will live with the result.

Ask for the need, not just the request

When you do talk to people, you will hit a subtle but crucial distinction. What someone asks for is rarely the same as what they actually need. People describe their problem in terms of a solution they have already imagined — and their imagined solution is often not the best one, or even the real problem.

The classic illustration: a customer asks for a faster horse. What they need is to get somewhere quicker; the horse is just the only solution they know. If you deliver exactly the faster horse they requested, you have satisfied the request and possibly missed the need.

The practical tool here is simple: when someone states a request, ask why — gently, a couple of times — until you reach the underlying need.

REQUEST:  "I need a button on this screen that exports to a spreadsheet."
  Why?    "So I can email the weekly numbers to my manager."
  Why?    "Because she asks me every Monday how last week went."
NEED:      The manager wants a reliable weekly view of performance.

Notice how the need opens up better options than the request did. Maybe the manager gets an automatic Monday email and nobody exports anything. You could not have seen that if you had simply built the button as asked. Requests are the surface; needs are what you are really being paid to satisfy.

The evidence — where projects actually fail

Studies of failed projects across industries generally point to the same culprits far more often than to technical difficulty: unclear or changing requirements, and poor communication between the people who wanted the work and the people who did it. The lesson is consistent and a little humbling — most projects are not lost in the building; they are lost in the understanding of what to build. Time spent up front getting the need right is among the cheapest insurance you can buy.

Separate must-haves from nice-to-haves before you start

Once you have a list of requirements, a new problem appears: they are not all equally important, but they will feel equally important if you never rank them. Everything anyone mentions gets quietly treated as required, the list balloons, and you cannot tell what would actually count as success.

The remedy is to sort requirements into priority tiers before work starts, while everyone is calm and nothing is late yet. A common and honest way to phrase the tiers:

MUST have      Without this, the project has failed. (Patients can book online.)
SHOULD have    Important, but the result still works without it. (Email confirmation.)
COULD have     Nice if there's room; first to be cut under pressure. (Choose a preferred nurse.)
WON'T have     Explicitly excluded this time — same as "out of scope." (SMS reminders.)

The magic of doing this early is that the hard trade-off conversation happens when it is cheap — in a calm meeting — rather than expensive, in a panic, the week before the deadline. When time gets tight (and it always does — see Scope Creep and the Iron Triangle), you already know what to protect and what to drop, and you agreed it together. Priorities decided under pressure are just whoever shouted loudest; priorities decided in advance are a plan.

Turn vague requirements into testable ones

The final skill is the one that separates requirements that protect you from requirements that betray you. A vague requirement feels like agreement but hides disagreement. “The system should be fast.” “The report should be easy to read.” “The room should be ready in good time.” Everyone nods — and everyone is picturing something different. You have written down a disagreement and mistaken it for a decision.

The test for a good requirement is brutally simple: could two different people look at the finished result and agree on whether it was met? If the answer depends on opinion, the requirement is not done yet. Make it specific and testable — put a number, a condition, or an observable outcome on it.

VAGUE                          TESTABLE
"The system should be fast."   "A booking page loads in under 2 seconds
                                on a normal office connection."
"The report should be
 easy to read."                "A manager can find last week's total
                                without scrolling or opening a second screen."
"The room should be ready
 in good time."                "The room is fully set up 15 minutes before
                                the session start time."

You do not need every requirement to have a stopwatch on it. You need each one to have a shared, checkable meaning, so that “done” is something you can point at rather than argue about. This is exactly the definition of done from the previous page, applied requirement by requirement.

How it connects

Scope and requirements are the raw material for everything that follows in this part. You cannot break work down and build a plan for work you haven’t defined, and you cannot estimate something whose boundaries keep moving. The clarity you create here is also your defense later: when someone asks for “just one more thing” during execution, a written scope with an “out” column turns a silent assumption into an honest, visible decision about the trade-off.

Try this

Take a project or task you’re about to start this week — however small — and write two short lists before you touch any of the work. First, a scope statement with two columns: in scope and out of scope (force yourself to name at least three things that are out). Second, list the requirements and mark each one must / should / could. Then look at every “must” and ask: could two people agree on whether it was met? Rewrite any that fail into something specific and checkable.

Reflect

1. Think of a recent project or task that disappointed someone. Was the problem really the work — or was it a mismatch about what was in scope that nobody named up front?
2. When was the last time you built or delivered something based on what you assumed people needed, without asking them? How did it turn out?
3. Recall a request someone made of you recently. If you had asked “why?” a couple of times, what underlying need might you have found beneath it?
4. Look at how you currently list requirements or tasks. Are must-haves and nice-to-haves mixed together as if equal — and what would change if you ranked them before starting?
5. Find a requirement or instruction you’ve given or received lately that sounds clear but is actually vague (“as soon as possible,” “make it nice”). How would you make it testable?

Show reflections

1. Most delivery disappointments trace back to an unspoken scope boundary, not poor execution. The useful move is to notice that the fence existed in people’s heads all along — it just was never written down where the mismatch could be caught early.
2. The honest answer usually reveals that assuming felt faster but cost more. Connect the outcome to the skipped conversation: the surprise at the end was information that a five-minute chat at the start would have given you for free.
3. A good answer reaches past the stated request to a need with more than one possible solution. That’s the whole point of “why” — it reopens options the request had quietly closed.
4. If everything is a “must,” nothing is protected when time runs short. Ranking in advance means the trade-off is made calmly and together, not by panic or by whoever is loudest near the deadline.
5. The test is whether two people could agree the requirement was met by looking at the result. Strong answers replace the feeling (“nice,” “fast,” “soon”) with an observable outcome, a number, or a condition anyone can check.