From brief to Statement of Work

Among the epitaphs of the PM Butcher, the book’s serial killer of project managers, there is one that reads: “Every ignored requirement is a project gone”. It is a macabre line, but it is also the truest thing you can say about the start of a project. Most of the problems that blow up halfway through were already written, or left unwritten, in the first documents.

There are three of those documents, and they are often confused. They have different authors, different moments and different purposes.

Document	Who writes it	What it is for
Requirements	Gathered together, client and supplier	Understanding needs and expectations: what the product or service must do
Brief	The client	Describing the problem, the context, the audience, the goals and the constraints
Statement of Work	The supplier, approved by the client	Setting out what will be delivered, how, with what timing, costs, roles and responsibilities

The brief: what it must contain

A good brief is precise, concise and consistent. It doesn’t tell everything: it says what is needed and leaves the rest to the attachments. These are the items that should never be missing.

• Header: subject, type (pitch or direct assignment), date, contact person, deadline for proposals.
• Context: the company, the product or service, the moment. Briefly: brand book and product sheets go in the attachments.
• Objectives: the general ones and the measurable ones, with their starting values. “Increase visits by 10%” means nothing if nobody knows how many there are today.
• Audience: data, habits, motivations. Buyer personas, if there are any, are worth more than any demographic table.
• Competitors and market: who is out there, what they do, what works in the sector.
• Creative guidelines: tone, style, references. A trick that always works: “three websites we like, three we don’t, and why”.
• Deliverables: what you expect to receive, as a list or a paragraph, but without ambiguity.
• Budget: always the most delicate point. Whoever writes the brief fears that any figure stated will be spent in full; whoever receives it doesn’t know how to size the proposal without one. A range (“between 30 and 50 thousand”) or a ceiling, with value for money among the evaluation criteria, almost always solves the problem.
• Timing: two calendars, not one. The selection one (questions, Q&A, proposal deadline, decision, kick-off) and the project one (deliveries, reviews, launch).
• Exclusions: what is not included. The classic “media excluded” saves weeks of misunderstandings.
• Evaluation criteria: how proposals will be judged. They are rarely found outside public tenders, which is a pity: they help everyone work better.

The most common mistakes

Too vague or too detailed. A vague brief produces proposals that miss the point; an over-detailed one leaves no room for the solution. The balance lies in describing the problem well and leaving the answer open.

Hidden or outdated information. A true story: a brief for a website rebuild, without telling the supplier that a complete rebrand was under way. The brand identity changed while the site was being built, and everything had to be reworked on the fly, at the last minute. The explanation: “It was confidential”. Confidential matters are what non-disclosure agreements (NDAs) are for; silence, on the other hand, costs everyone.

No room for questions. However clear a brief is, whoever receives it will have questions. Planning Q&A sessions is the minimum; when it isn’t a pitch, working on the concept together is even better.

Impossible timing. Briefs sent at the end of July or on 23 December, on Friday for Monday. Awards that come late without the start and delivery dates moving. These mistakes undermine a project before it even begins.

Knowing how to receive a brief

Reading a brief well matters; receiving it well matters just as much, and people think about it less.

• Listen to what the client says, and to what they don’t. Silences and hesitations often point to where the problems are.
• Ask straight away, or note it for later. If the presentation is for several suppliers and questions come at a later stage, write your doubts down while you have them.
• Insist on a written brief. If the client doesn’t produce one, write it yourself from what you heard and send it to them for confirmation. It is the most useful thing a PM can do at the start of a project.
• Prepare a summary sheet for the team. Always the same structure: client, people present, previous work, known issues, objectives, audience, deliverables, dos and don’ts, budget, internal deadline and client deadline, date and format of the presentation. In time, the team will read it in a minute.

Going beyond the brief

Sometimes a brief doesn’t convince: the requested solution seems wrong, or you think you can do better. Proposing an alternative can be the winning move, or the quickest way to lose a client. Before you do it, it is worth asking yourself:

1. Have I really understood what the client wants to achieve, and what problem they want to solve?
2. Are my doubts objective, or am I missing information?
3. Which needs don’t show in the brief, but are there in my view?
4. Am I convinced enough to stake everything on it, including the project?

Two things help you answer: a session with the team, almost as if you were re-briefing yourselves, and a conversation with the client. People often believe that asking questions during a pitch is a sign of weakness. It isn’t: keeping a channel open is part of the job of whoever looks after the client, in constant alignment with the PM.

When you decide to go beyond the brief, present the alternative alongside the requested solution, not instead of it: “The brief asks for X; we believe Y could work better, for these reasons”. With data, concrete examples and a willingness to work on it together.

The Statement of Work

The Statement of Work (SoW) is the document that closes the phase of intentions and opens the phase of commitments. To all intents and purposes, it is the basis of the contract. It must state:

• why the project is being done and with what objectives;
• what is included and, just as clearly, what is excluded;
• the assumptions it rests on: if they change, the project changes;
• how it will be done: approach, phases, tasks, methodology;
• what will be delivered and with what acceptance criteria;
• time and cost;
• who does what and who approves (the governance).

A well-written SoW is not there to defend you from the client: it is there so that nobody needs defending. It is the basis for estimating, planning and handling changes when they come. And they always come.

In more structured projects, two other documents sit next to the SoW. The Project Charter officially authorises the project and gives a short overview of it: why, who, what, when. The Project Plan comes after, and guides execution with tasks, resources, costs, risks and communication. The first says the project exists; the second says how we will get it done.