Writing the scope for a website project

The most expensive document in a website project is not the quote. It is the page where scope is written. When that page reads “five pages, contact form, mobile friendly”, everyone spends the project picturing their own version of the site, and the difference shows up at handover.

What a feature list fails to measure

“Contact form” sits on one line. Behind it are at least five decisions: which fields, what spam protection, where submissions land, what the confirmation says, whether a copy is kept on the sender’s side.

None of those get discussed when the line is written. They surface one by one as the project runs, and each produces a small negotiation. A list of ten items means fifty negotiations.

The question to ask while writing scope: when this item is delivered, will both sides see the same thing? If the answer is unclear, the item is not scope yet. It is a heading.

Writing scope as limits

What turns an item into scope is as much what will not be built as what will. Without a limit, the default is unlimited, and nobody meant that.

Concretely. Instead of “blog”: a listing and a post page, category filter yes, tag filter no, search no, comments no, not multilingual. Five lines, and nothing left to argue about at handover.

The same applies to content. Who writes the copy, who supplies the images, how many rounds of revision. When those three go unwritten, they produce the longest waits in the project.

Page count is the wrong unit

Counting pages is a habit and it does not describe the work. Ten service pages carrying the same content are one template; three pages that differ from each other are three jobs.

There is a better unit: the number of distinct layouts. How many page skeletons get designed, how many components get built? A project laying ten pages over three layouts costs about the same as one laying three pages over three layouts.

That unit also means something to a client. “Five layouts and twelve components” is less abstract than “fifteen pages”, because it explains what does and does not change when a page is added later.

The change route is part of the scope

Every project produces a request that falls outside scope, and that is normal. The problem is not the request; it is that nothing was written about what happens to it.

One paragraph in the scope document is enough: how out-of-scope requests are assessed, how the effect on time and budget is reported, and who decides. Without that paragraph, every request turns into a negotiation and the relationship frays a little each time.

Defining done

The last and most-skipped item in a scope document is when the project ends.

What needs writing is not a date but a set of conditions: which browsers it will work in, which viewport widths get tested, which measurements have to be met, which documents get handed over. With that list, delivery is an event. Without it, delivery is a process, and that process can run for months.

The six lines of a scope

A scope document does not have to be long. Six headings cover most projects:

1. How many layouts, how many components.
2. What each layout includes and excludes.
3. Who supplies copy and images.
4. How many rounds of revision, at which stages.
5. What happens when an out-of-scope request arrives.
6. The conditions for delivery.

Write those six and the quote clarifies itself. Leave them out and the number in the quote is an estimate, and the same side always pays for the gap.