Working notes

Writing the brief is most of the job.

Priya Raman·9 March·7 min

Every project I have rescued was not failing on execution. It was failing because nobody had written down, in one place, what finished looked like.

The pattern is consistent enough to be boring. A team is three months in. The work is real and the people are capable. Ask five of them what the project delivers and you will get five answers that overlap by about seventy per cent — which sounds fine until you notice the thirty per cent is where all the arguments live.

A brief is not a description of the work. It is a description of the moment you get to stop.

What a brief has to contain

Three things, and they are all unglamorous. What exists now, stated plainly enough that somebody outside could verify it. What will be true afterwards, in terms you could test. And what is explicitly not included, which is the part everyone skips and the part that saves the relationship.

The test I use: could a competent stranger read this and tell me, without asking a question, whether the work is done? If not, it is a wish, not a brief.