Bad digital project scoping does not show on day one. The project starts, everyone nods, and sometimes it takes the first demo to discover that marketing and engineering had different projects in mind. If you are launching a website, an integration or an application and everyone describes it in their own way, that is where I would spend the first week.
My missions begin with a few days of diagnosis, before anything gets built. Here is one way of dividing that time over five days, the scoping note that comes out of it, and the cases where a week is not enough. The split is a working frame, not a ritual: on your project, Tuesday may well spill over into Wednesday.
01What scoping has to produce: a decision
People often assume that scoping produces a document. I would rather it produced a decision: carry on, cut back or stop. Nielsen Norman Group's channel advises framing the goal of a discovery as a decision point, meaning what the team wants to be able to agree on at the end. I find that wording very useful, because it gives the work an end date.
Stopping is one of the possible answers. The UK government's service manual says so plainly: it is not a failure to stop at the end of this phase if the research shows that is what you should do. I wrote the same rule into my content machines: an article that cannot pass honestly is dropped with a note rather than forced through. The pressure to finish pushes you to make things up. On a project, it pushes you to start anyway.
To decide, you need five things on the table by the end of the week:
- the problem, in one sentence;
- the scope, including what is excluded;
- the constraints, split between those you have to live with and those you can change;
- the remaining unknowns, and who will resolve them;
- the name of whoever decides what.
Nielsen Norman Group adds that this phase is not about producing outputs for their own sake. If a diagram does not help the decision, I do not draw it.
02One week, when GOV.UK talks about four to eight
GOV.UK says a discovery typically lasts around 4 to 8 weeks, adding that there is no set period, that a problem nobody has researched may need longer and that a well-known one may need slightly less. That guidance is written for public services, where user research often starts from a long way back.
The week I am describing sits at the other end of that scale: a company that knows its customers, a project of reasonable size, decision makers who are available. It does not replace research. It gets what the company already knows down in writing, shows what it does not know, and forces a choice.
The short deadline also has an effect I learned well before digital, in audiovisual production: when the date cannot move, you stop debating everything and you choose. That is what I am after here.
03The plan, day by day
Monday: move from the requested solution to the problem
The web project kick-off happens on this day, and it rarely starts with a problem. You get asked for a map, an app, a new website. GOV.UK has a good example: “we need to build an interactive map to show people where our contact centres are” is not a problem. The problem is how to make it easier for people to find their nearest centre when they need a face-to-face appointment.
For this workshop, I would reuse the five steps from Nielsen Norman Group's video on kick-off workshops: everyone's roles, the problem statement, the goal framed as a decision, unknowns ranked by risk, and a plan with an owner and a time box for each activity. Half a day seems enough to me for a first version.
Tuesday: listen to the people who will live with the result
Short interviews, one person at a time: the sponsor, those who will do the work every day, those who talk to customers, those who look after the technical side. Ask everyone the same questions: the interesting part is the gap between the answers.
Nielsen Norman Group recommends a small team of 3 to 7 people, with an owner influential enough to get access to people and data. Over a single week, I would check this on Monday: if nobody can open the doors, Tuesday is lost.
Wednesday: list the constraints and sort them
Legislation, contracts, legacy technology, existing processes: these are GOV.UK's categories, and it separates hard constraints, which you will not change, from soft constraints, which you should work to change. The sorting matters more than the list. Mistake a soft constraint for a hard one, and the project works around a process for good when one meeting could have fixed it.
France Num points out that you do not need to know the technology behind your future site, but you do need to state which tools it will have to work with, such as a CRM or an ERP. I add reference data. On one project, a mix of centimetres and millimetres between two tools was enough to distort an entire render. So I ask who holds the right value, and in which unit.
Thursday: cut the scope, and show it
This is the least comfortable day. France Num says that wanting to do everything at once is the main cause of budget overruns and advises separating what you need at launch from what can wait for a second phase. I suggest three columns: at launch, later, never. The “never” column is the hardest to fill in, and it is the one that forces a choice.
When a disagreement will not shift, I make it visible. Showing several mock-up directions at the same level of finish unblocks a decision better than a long debate, because everyone is reacting to the same thing. A Thursday is enough for simple sketches, not for a finished mock-up.
Friday: write it up, then get a decision
The note gets written in the morning and goes out to the decision makers ahead of the afternoon session. That session has one subject: carry on, cut back or stop. Nothing new arrives in the room, as with a steering committee that has to decide: everyone has read it beforehand, and you leave with a written decision.
04The scoping note fits on two pages
A project scoping note is not a specification. France Num reckons that five to ten well-structured pages are enough for a specification for a brochure site or a simple online shop, and that document comes afterwards. I aim for two pages for the note, because I want people to read it again. Here is the template:
- Project, date, version number
- Problem to solve: one sentence, naming no solution
- Decision expected: carry on, cut back or stop
- Objectives in order of priority, with a measure for each
- In scope at launch
- Later
- Out of scope
- Hard constraints / soft constraints
- Remaining unknowns: who resolves them, by when
- What the project does not promise
- Who decides what: sponsor, business, technical
- Next: first milestone, budget envelope
Two lines come straight from my own practice. “What the project does not promise” borrows a field from the brief of one of my content machines, which makes you list what the text refuses to claim: writing the limits down before you start stops promises slipping in along the way. And the version number comes from an integration between an ERP and an online shop, where the specification moved at almost every meeting. I kept it evolving version after version, so that everyone was talking about the same document.
I also take inspiration from my writing brief, which refuses to go further while a field is empty. An empty line in this note marks an unknown, to be assigned to someone.
That leaves the question of who holds the pen. In a paper published by PMI, Richard and Elizabeth Larson write that project managers usually create the charter, whereas sponsors should keep ownership of it. I can write the document, but the sponsor has to be able to explain it without having it in front of them.
05What happens to the scope after scoping
The scope will move, and that is fine. The same authors draw a distinction I think is right: an approved expansion of scope is not scope creep. The trouble is the addition nobody decided on, because it looked small. They also name the opposite excess, “scope kill”: a process so rigid that useful changes get turned down.
So I suggest a light rule, one line per request: what is being asked for, which objective in the note it answers, the effect on time and cost, who decided. France Num also advises keeping a reserve of 15 to 20% for unanticipated needs: those lines tell you when to touch it.
06When one week is not enough
There are several cases where I would not use this format.
- Nobody in the company has spoken to the users concerned. On Moonworkers, the product was designed from its users, with personas and wireframes: a week of scoping does not replace that work.
- The project spans several organisations, each with its own decision makers. Finding a common slot will take a week on its own.
- It is an SAP or ERP overhaul. I do not do those, and this is not the right scale.
- The sponsor has no time that week. Without them, you will produce a document and no decision. I would move the week.
The method has a cost too. It asks several people to interrupt their work, and it can conclude that the project should not go ahead, which is not always welcomed by whoever was championing it. It leaves unknowns: they are written in the note, but they are still there. I also have no measurement proving that one week beats two; it is a choice of method, to adjust to your situation.
07Where to start on Monday
You do not have to wait for the official launch. Ask three people on the project to write down, separately, the problem in one sentence and what is out of scope. Compare. If the answers look alike, your scoping may already be done and only needs writing up. If they diverge, you know what has to be settled before anyone estimates anything.
Then book a slot with the sponsor for the following Friday, before you fill in the rest of the template. That appointment is what will hold the rest together.
If you would rather have someone from outside run this week with you, it is the start of what I offer in project direction, and we can talk about it.