A useful project brief does not need to be long. It needs to remove the most expensive forms of guesswork.
Start with the problem
Describe what is currently difficult, slow or unreliable. Avoid beginning with a preferred feature. A team can propose a better route when it understands the real obstacle.
Name the people who will use it
A client, administrator and field operator often need very different experiences. List the main users, what each one needs to achieve, and any information they should not see.
Separate essential outcomes from ideas
Write the three outcomes the first version must deliver. Keep additional ideas in a later list. This protects the budget and makes the first release easier to test.
Share the working conditions
Mention the expected launch window, available content, existing tools, approval process and realistic budget range. Constraints are useful design information, not something to hide.
Define what success looks like
Use observable outcomes: a report that takes minutes instead of days, a contribution history members can inspect, or a course a learner can complete on a phone. Avoid impressive-sounding numbers that have no evidence behind them.
A clear brief is the beginning of a good working relationship. It gives the project manager enough context to ask sharper questions, agree the scope and match the right people to the work.