A retailer replaces its point-of-sale system. The scope document is circulated, signed off without objection, and the project goes live on time and close to budget. Within a quarter, three parts of the business say it failed. Store staff expected mobile stocktaking. The buying team expected the supplier portal to be connected. Finance expected the old pricing system to be switched off. None of those things was in the scope. None of them was excluded either.
Nobody lied and nobody changed their mind. The scope said what the project would produce and said nothing about these three things. Experienced people read that silence the way silence is usually read when a significant investment is being made on your behalf: as “not yet detailed”. The authors of a scope read it as complete. Everyone else reads it as a sample.
This article explains why a scope needs two lists, what is in and what is out, how to collect the expectations that matter, how to handle the edges where your work meets someone else’s, and how to agree what “done” means before work begins. It applies whether you are scoping work for a customer, buying from a supplier or running an internal project. It is general information.
A scope is a boundary, and a boundary has two sides
The purpose of a scope statement is a shared understanding of what will be produced. Shared understanding is a two-party condition: it exists only when the reader’s expectation matches what was written. A list of inclusions cannot achieve that on its own, because it describes the inside of the boundary without locating the outside.
Four misreadings cause trouble:
- A scope is a description. It is a claim about a boundary. Describing the inside carefully does not tell anyone where the outside is.
- Silence is neutral. The author knows which items were considered and declined. The reader cannot tell “considered and declined” from “not thought about yet”. An unstated exclusion is read as an inclusion that has not been detailed.
- An exclusion is a kind of assumption or constraint. An assumption is a belief that may prove false. A constraint is a limit on how the work can be done. An exclusion is a decision already taken that something will not be produced. Filed with the others, it gets lost.
- Missing exclusions are somebody’s fault. Nobody can list everything a job will not do. The skill is finding the few absences that somebody is currently planning around.
Collect expectations; do not invent exclusions
The exclusions list is not everything outside the scope. It is short and targeted, and it is collected rather than imagined, because the person writing the scope does not hold the expectations. The people who do are those who will use, run or depend on the result.
Ask them a simple question: what do you currently believe this work is going to give you? Not “do you agree with this scope?”, which produces agreement. Sort the answers into three groups:
- In scope but poorly described: fix the wording.
- Out of scope: write it into the exclusions, in the words the person used.
- Not yet decided: the most valuable group. Each item needs an owner and a date, because an undecided item behaves exactly like an unstated one.
Every exclusion also needs a destination: is the item being done by someone else, scheduled for later, or not happening at all? “Not in this job” is half an answer, and a list that does not say which of the three applies will be read as the most optimistic.
Then publish the exclusions in the same document as the scope, at the same time, and record who was told. An exclusion that nobody outside the project has read is not an exclusion; it is a defence prepared in advance, and it will be recognised as one.
Where work is subtractive, such as closing sites, clearing a building or removing a product range, state the residue: “everything goes except these three items”. A finite list of what remains is far easier to check than an open-ended description of what goes.
Ambiguous verbs hide scope
Many scope disputes start with a reasonable-sounding phrase. A supplier is engaged to “install and commission” a machine. Does that include electrical isolation, new cabling, network configuration, operator training, trial material, performance testing, removal of packaging? Each party may answer differently, in good faith.
Test every key verb in a scope by asking what it does and does not include, and write the answers down. Useful headings for a statement of work include the objectives, the deliverables, the standards to be met, the timing, the customer’s responsibilities, site conditions, other contractors involved and how acceptance will be decided.
When writing requirements for suppliers to quote against, classify them:
- mandatory: must be met;
- evaluated: will be compared between quotes;
- optional: welcome but not required;
- information only: context, not a requirement.
“High-quality support” is not a requirement anyone can price or later enforce. “Responses to priority-one issues within two business hours, 8 am to 6 pm on business days” is.
Interfaces deserve more attention than their length suggests
Many disputes do not arise inside a deliverable but at its edges, where one party’s work meets another’s. A business installing automated inspection equipment might find the supplier thinks its job ends at commissioning the machine, operations expects stable settings for every product, quality expects validated measurement and IT expects secure integration with existing systems. None of these expectations is unreasonable. The job fails if each assumes someone else owns the connection.
For each significant interface, name:
- which existing systems or processes must connect;
- who supplies data, utilities, approvals and people;
- who owns training and process change;
- what must be true before handover;
- where the supplier’s responsibility ends and operational responsibility begins.
The who can change what the job is for article covers handling unwritten expectations once the work is under way.
Agree what “done” means before the work starts
Near the end of many jobs, someone is shown the finished result and asked to sign. The team believes it met the specification. The users find practical problems. The supplier says the requested changes are out of scope. Each party has been working towards a different definition of done.
Acceptance criteria state the conditions under which a deliverable will be recognised as complete and fit for its intended use. Written before work begins, they bring disagreements forward to when they are cheap to resolve. Written after the output exists, they turn into negotiation around what was produced.
Distinguish acceptance from success. Acceptance asks whether this output met its agreed conditions. Success asks whether the wider investment achieved its purpose. A machine can pass its acceptance tests while the business case fails because demand did not arrive; the two need different measures and owners.
Good acceptance criteria:
- protect something that matters: a benefit, obligation or significant risk;
- are clear enough that two competent people would judge them the same way;
- use realistic conditions: real materials, real changeovers, real users, not the supplier’s best demonstration;
- cover end-to-end operation, not just individual components;
- name who provides the evidence, who checks it and who accepts;
- say what happens with marginal or conditional results, and which defects or obligations carry into operation.
Avoid undefined words like “user-friendly” or “satisfactory” unless you also say who judges and how. Where uncertainty is high, stage acceptance: factory tests, site tests, user trials and a period of stable operation each give stronger evidence. The after the signature article covers making sure the people who can reject work also review it along the way.
Scope is an investment boundary
At the level of the owner or sponsor, scope is not a list of features. It is a decision about what change the business is willing to fund and own. A useful scope answers five questions:
- What problem or opportunity justifies doing anything?
- What should be different when the work is finished?
- What must be produced to make that possible, including integration, training and handover work?
- What is explicitly excluded or deferred?
- How will we decide the commitment has been fulfilled?
Where uncertainty is high, the first approval does not have to release the whole investment. It can authorise investigation, design or a pilot, with the larger commitment reserved for a later decision once more is known.
The boundary should also be controlled, not frozen. When evidence changes, changing scope may be entirely sensible, as long as everyone understands what extra value is expected, what moves as a result and what else is displaced. The variations article covers handling those changes once work is under way.
A worked example
This is an illustration. A small IT services firm is engaged by a 40-person accounting practice to “relocate IT systems to the new office”. The firm’s first draft lists what it will do: move and reconnect workstations, servers and printers, configure the network and test everything.
Before finalising, the firm’s project lead asks the practice manager, the receptionist and two partners what they expect. The answers reveal several assumptions:
- the receptionist expects new phone handsets;
- a partner expects the internet connection at the new office to be arranged;
- the practice manager expects the security cameras to be moved;
- everyone assumes the new office’s data cabling is included.
The firm sorts them. Cabling is out, to be done by the building’s electrician, already booked by the landlord for 3 June. The internet connection is out, to be ordered by the practice from its provider by 1 May. Phone handsets are in, poorly described, and are added explicitly. The cameras are not decided: the practice manager will decide by 15 May whether to move them, and the firm provides a quote.
The firm then writes acceptance criteria with the practice manager: every workstation logs in and accesses client files; printing works from every desk; incoming calls reach reception and transfer correctly; internet speed meets an agreed minimum; and the systems run for two business days without significant issues. The scope, exclusions with their destinations and acceptance criteria go out in one document, and the firm records that the practice manager and both partners received it.
The move takes place over a weekend. On Monday, the only issue raised is a printer on the second floor, which is fixed the same day. Nobody asks about cabling or cameras. When the practice later asks the firm to quote for its next office fit-out, it asks for the same format.
How this applies to a small Australian business
- Write two lists: what is in and what is out.
- Ask people what they expect before finalising scope.
- Give every exclusion a destination: someone else, later or never.
- Publish scope and exclusions together, and record who received them.
- Test key verbs such as “install”, “set up” or “support”.
- Name owners for every interface.
- Agree acceptance criteria before work starts, using realistic conditions.
- Separate acceptance from success, and give each its own measures.
Signals worth watching
- Scope documents with no exclusions section.
- Sign-offs with no questions or comments.
- Phrases like “install and commission” with no detail.
- Requirements such as “high quality” or “user-friendly” with no measure.
- Interfaces where each party assumes the other is responsible.
- Acceptance criteria written after the work is finished.
Common mistakes
- Treating a list of inclusions as a complete boundary.
- Inventing exclusions instead of asking what people expect.
- Leaving undecided items unowned.
- Filing exclusions with assumptions or constraints.
- Testing components but not the whole system.
- Confusing acceptance with success.
Frequently asked questions
Won’t listing exclusions look unhelpful to customers? Usually the opposite. Customers appreciate knowing early what to arrange themselves, and it prevents disappointment later.
How long should the exclusions list be? Short. Focus on the items people are likely to assume are included, which you discover by asking.
What if a customer insists something excluded should be included? That is a conversation about scope and price, much better had now than at handover.
Who should approve acceptance criteria? The person who will accept the work, ideally with input from the people who will use it.
Do internal projects need this? Yes. Internal stakeholders form expectations just as customers do, and the same silence causes the same disappointment.
Should exclusions go in the contract too? Yes, for work done under contract. A clear exclusions schedule, cross-referenced to the scope, is one of the simplest ways to prevent disputes.
Questions to ask
- What do the people affected currently believe this work will give them?
- Which of those beliefs are wrong, and have we told them?
- Where does each exclusion go: someone else, later or never?
- Which phrases in our scope could be read two ways?
- Who owns each interface?
- What evidence will show the work is done, and who will judge it?
Bringing it together
A scope that lists only what is included is read by everyone else as a sample. Write two lists, collect expectations from the people who will use or depend on the work, and give every exclusion a destination. Test vague verbs, name owners for every interface and classify requirements so they can be priced and enforced. Agree acceptance criteria before work begins, under realistic conditions, and keep acceptance separate from success. A boundary stated clearly at the start costs an hour; a boundary discovered at handover costs the relationship.
Source: KEVOS notes, drawing on teaching material on project scope statements, exclusions, statements of work, requirements and acceptance criteria. Examples in this article are illustrations. This article is general information.
