Planning guide · 1 min read

What belongs in a useful project brief?

A project brief connects the business outcome to the first release, the constraints, and the decisions a delivery team needs to make.

01Start with the problem

Describe who experiences the problem, how they handle it today, and why the current approach falls short. Include one concrete example. “Customers call to change appointments” is more useful than “we need digital transformation.”

02Define success before features

Choose observable outcomes: completing a booking without a phone call, reducing a manual handoff, or testing demand for a paid product. Specify how you will evaluate the first release.

03Separate the first release from later ideas

List essential user journeys, then group capabilities into must-have and later. Include what is explicitly outside the scope. An exclusion is often as valuable as a feature.

04Make constraints visible

Record your budget band, preferred launch window, data sources, integrations, privacy needs, and internal reviewers. Mark unknowns instead of quietly treating them as settled requirements.

05Ask for comparable proposals

Ask every supplier to explain assumptions, milestones, acceptance criteria, intellectual-property ownership, support, and change control. Compare the same scope across teams.

Editorial approach

This guide offers practical planning questions. It is not a guarantee of delivery outcomes. Adapt the checklist to your project and validate assumptions with the proposed team.

Further reading: GOV.UK Service Manual — related delivery guidance

Keep exploring