Prepare a project brief that gives work a clear start

A project brief does not need to answer every technical question. It needs to make the work understandable enough for the right questions to be asked. Begin with a page that a colleague unfamiliar with the project could explain back to you.

Describe the current situation

Use one concrete example of what is not working. For an illustrative booking project, explain that enquiries arrive through several channels and staff cannot readily see which have been answered. This is more informative than a request for a modern system.

Attach a small, anonymised sample if it clarifies the issue. Do not send a whole customer database when a fictional record would show the same process. Identify any information the provider may need later and how access will be arranged appropriately.

Explain the desired result

State what somebody should be able to do after the project. The Design Council's briefing guidance connects a project to its business problem and intended outcomes. Keep your own description focused on the improvement rather than prescribing every implementation detail.

For the booking example, a useful result could be that authorised staff can identify an unanswered request and its owner. Decide how you would demonstrate that result. An agreed example gives both sides a clearer reference than adjectives such as intuitive or seamless.

Make constraints visible

List dates that genuinely matter, available budget boundaries and dependencies on other work. Explain why a deadline exists. A fixed event date calls for a different discussion from a preferred date chosen without a practical reason.

Name the person who can approve scope and the people who must be consulted. Add what your team will provide, such as content or access to an existing process. Separate confirmed information from assumptions that still require investigation.

Invite clarification before asking for certainty

End the brief with open questions and the next decision. A provider may reasonably suggest a discovery step before promising the full implementation. Ask what that step would establish and what usable output you would receive.

Review the brief together and record agreed changes. A useful brief is a shared starting point, not a document that becomes untouchable once sent. Keep one current version so that later offers and decisions refer to the same understanding of the work.

Sources: Design Council: Briefing by Peter L Phillips.