Start with the change you want to see.
A brief is a decision tool. Before it becomes a list of features, it should explain what needs to improve and why that improvement matters. “Replace our platform” describes an activity. “Give the operations team one reliable view of incoming work” describes an outcome. That distinction creates room to consider more than one solution.
1. What is happening today?
Describe the current experience in concrete terms. Where does work slow down? What gets repeated? Who needs to intervene? Gather a few examples from the people closest to the process. A shared picture of the present is more useful than an early agreement on a product.
2. What would better look like?
Make the desired result observable. A simpler handoff, a more reliable service or an easier customer journey gives the project a direction. Choose a small number of measures you can establish before the work begins and review after it is complete.
3. What needs to work with it?
List the systems, teams and external services the change touches. Include data flows, ownership and the everyday tools people rely on. Dependencies are not a reason to avoid change; they are information that makes the plan more realistic.
4. What boundaries are real?
Separate fixed constraints from assumptions. A contractual deadline may be fixed. A preferred launch date may be negotiable. The same applies to budget, procurement rules and available internal capacity. Clear boundaries help a team propose a workable approach.
5. Who makes the decisions?
Identify the people who can approve scope, resolve trade-offs and accept the outcome. Agree on how they will stay involved. A good brief does not remove every uncertainty. It makes the next decision clearer—and gives the right people a shared place to start.