A project scope that survives the first change

Every project changes once work begins. A site turns out to need more preparation than the survey showed. A supplier withdraws a product. The sponsor sees the first finished room and wants the others different. None of this means the scope was wrong. It means the scope is about to be tested.

A scope that survives that test is not longer or more detailed than one that fails. It is clearer about four things: what the project delivers, how everyone will know it is done, what it leaves out, and what it takes for granted.

Describe the deliverables, not the activity

A weak scope lists work. "Design the office. Manage the contractors. Install the systems." Each line describes effort, and effort has no natural end.

A strong scope lists things that will exist when the project is over, each one specific enough to inspect. An office for a stated number of desks, with the meeting rooms, the server room and the finishes set out in an attached schedule. A booking system live for named teams, with their existing records moved across. When a deliverable is a thing, both sides can point at it and agree whether it is there.

Where a deliverable depends on a drawing, a specification or a schedule, attach it and name its version. A scope that refers to "the latest drawings" changes every time someone saves a file.

Write down how acceptance works

For each deliverable, say how the sponsor will accept it. Who inspects it, against what, and how long they have to respond. A fit-out might be accepted room by room against the finishes schedule, with a list of minor defects to be put right by an agreed date. A system might be accepted after a set period of use by the people who will depend on it.

Acceptance criteria protect both sides. The sponsor knows what they are entitled to receive. The people delivering the project know when they have finished. Without them, the end of a project becomes a negotiation, and the negotiation usually happens when everyone is tired and the budget is spent.

Say what is out of scope

Some of the most useful lines in a scope describe what the project does not include. Loose furniture, which the sponsor will buy directly. Changes to the building's main services, which need the landlord's consent. Training beyond the first group of users.

These lines answer questions before anyone asks them, and they stop two people from carrying different pictures of the same project. When a sponsor later asks for something on the excluded list, the conversation is short and friendly. It is a new request, and it can be priced and planned like one.

List the assumptions and who carries them

Every scope rests on assumptions. Access to the site from a given date. Drawings approved within two weeks of submission. A supplier's stated lead time. Write each one down, and say who carries the consequence if it proves wrong.

Suppose a fit-out assumes the landlord will hand over the space on the first of the month, and handover slips by three weeks. If the assumption is in the scope, everyone already knows that the programme moves and who bears the cost of waiting. If it is not, the delay starts an argument about something nobody wrote down.

Make change a routine

A scope survives change when there is a known way to change it. Agree at the start how a change is requested, who assesses its effect on cost and programme, who approves it, and how it is recorded. Then use that route every time, including for small changes and for changes the sponsor asks for in passing on a site visit.

Each approved change becomes part of the scope, so the scope stays a true description of the project as it now stands. At handover, the sponsor can compare what was delivered with what was agreed, changes included, and see that the two match.

We plan and run projects for owners and sponsors, from the scope to the handover.