How we scope a project in one page

Every project in our work index is written up the same way: the problem, the idea, what we built, the outcome. That isn't a format we invented for the website. It's the shape of the brief we write before we start. The write-up is the brief, with the past tense filled in.

The brief is one page. Short documents aren't virtuous in themselves. A page is just about how much a project can hold before people stop agreeing on what it is.

The problem, in a sentence

Start with what's wrong today, in the words of the person who has the problem. Not a goal, not a feature. A specific, slightly annoying fact.

For the location page builder, it was this: every new store meant copying a page by hand, and the old store's phone number always slipped through. For the card-fee audit: card fees were buried in monthly statements that nobody compared. You can picture both. You can also tell, later, whether they've been fixed.

If the problem takes a paragraph, it's usually two problems. Pick one, and save the other for the next page.

The idea, in another

The idea is how you'll fix it, in one line, before any design. The location page builder's was: clone the layout, check for leftovers, and make every change reversible. That sentence did a lot of work. It said the job was a safer way to do something people already did, not a new way of building pages.

A good idea sentence makes some requests easy to turn down. If a new request doesn't fit the sentence, it goes on the out list. Or it changes the sentence, and everyone agrees that it did.

What's in, and what's out

Below the idea go two lists. In: the things that will exist at launch, each one small enough to check off. Out: the things someone has mentioned that won't. The out list is the more useful of the two.

Everything on the out list was a reasonable idea. That's why it needs writing down. Without it, reasonable ideas arrive one at a time during the build, each too small to argue about, and together they double the work. With it, there's a place to put them that isn't the current project.

Here is the whole page:

• The problem, in one sentence, in your words.
• The idea, in one sentence.
• In: what exists at launch, as a short list.
• Out: what was discussed and isn't happening now.
• Who decides, and who will use it day to day.
• What we need from you, and by when: access, content, and a person who can answer questions.
• The launch note.

Write the launch note first

The last part of the brief is the message we'll send on launch day, written before any work starts. Three or four sentences: what's live, what changed for the people using it, and what to do if something looks wrong.

It sounds like a formality. It's the most honest part of the page. If you can't write the launch note, you don't know what you're building yet. If the note is vague, so is the scope. And if the note mentions something that isn't on the in list, you've found a gap before it costs anything.

For the location page builder, the note would read something like this: new location pages can now be cloned from an existing one, and each clone is checked for anything left over from the original before it goes live. That's a promise you can test on launch day, by cloning a page and looking for the old phone number.

Fixed scope or monthly

Once the page is agreed, there are two ways to run the work, and the brief usually makes the choice obvious.

If the in list is short, stable and checkable, it's a fixed-scope project. We agree the list, build it and launch it. New ideas go on the out list for a later round, or swap places with something already on the in list.

If the in list keeps growing because the work keeps teaching you things, a monthly arrangement fits better. Each month gets its own short brief: what's in this month, what's out, and what the note will say at the end of it. The same people keep designing, building and hosting it, so nothing gets lost between rounds.

Neither is better. The mistake is running a monthly kind of project as fixed scope, where every new idea becomes a negotiation, or a fixed one as monthly, where it never quite ends.

Try it on your next project

You can do this with anyone, for anything. Write the problem in one sentence and the launch note in four. If you can't, don't start yet. If you can, you've already done the hardest part of the scoping, and the rest is lists.