A useful project brief helps a group agree on what needs attention. It gives the discussion a starting point without pretending that the solution is already known. The first version can fit on a single page and still expose the questions that matter.
Begin with the work as it happens today. Describe an observable situation, then connect it with a decision the organization needs to make. Words such as “modernize” or “improve efficiency” need more detail before they can guide a project.
1. State the situation in ordinary language
Describe the process, the people involved and the point where work becomes difficult. Compare “We need a better customer experience” with “A customer request can pass through three inboxes before someone accepts responsibility.” The second statement gives the team something to investigate.
Keep your proposed explanation separate from the observation. You may suspect that the routing rules are unclear, but the brief should leave room for another explanation to emerge.
2. Name the decision
A project becomes easier to frame when the decision is explicit. The team might need to choose an intake process, decide whether to change a staffing arrangement or establish which service request should be handled first.
Write who will make that decision and when it is needed. If nobody can identify a decision owner, resolve that uncertainty before adding a long list of deliverables.
3. List useful evidence and practical limits
Start with information that is already available: a sample of requests, handoff records, response times or observations from the people doing the work. Record the limitations alongside it. A small sample can be useful, but it should not silently become a claim about every customer.
Then describe the boundaries: the tools that must remain, the people available, the timing and any restrictions on sharing information. Those details help identify a feasible next step.
4. Put the brief together
The following is a fictional example.
| Brief field | Example |
|---|---|
| Situation | New customer requests arrive in several inboxes and can be forwarded repeatedly. |
| Consequence | The team cannot easily see which requests are unassigned. |
| Decision | Choose one intake process before the next service review. |
| Owner | The service lead, with input from both receiving teams. |
| Starting evidence | An anonymized sample of recent requests and handoffs. |
| Boundaries | Use existing tools and avoid interrupting active customer work. |
| First step | Map the current route for ten recent requests. |
| Review question | Where does ownership become unclear, and which change can we test? |
Set a scope that can survive the first meeting
Write what the brief includes and what it leaves for another decision. In the service-team example, the initial scope could be to understand intake and assignment for ordinary customer requests. Replacing the company’s entire support platform would be outside that first investigation.
This boundary is useful even when a wider change may eventually be necessary. It gives the team a proportionate starting point and a way to recognize when the work has expanded. If the investigation reveals a broader problem, describe it explicitly and decide whether to extend the scope.
Turn a deliverable into an acceptance question
A deliverable should answer a useful question. “Process map” is a label; “a map that both receiving teams agree describes how ordinary requests are assigned” explains what makes the deliverable usable.
| Proposed output | Acceptance question |
|---|---|
| Current-process map | Can the people doing the work identify where ownership changes? |
| List of recurring problems | Does each problem connect with an observed example? |
| Options for a different intake process | Are the effort, constraints and consequences clear enough to compare? |
| Recommended next test | Is an owner able to run it and explain the review criteria? |
These questions keep a team from confusing the existence of a document with a resolved business issue. They also help an adviser understand what the organization needs to do after the work is delivered.
Record the unknowns without letting them stop everything
Every early brief contains uncertainty. List the questions that could change the scope, the proposed decision or the evidence required. Then distinguish an unknown that blocks the next action from one the investigation itself can answer.
For example, not knowing the total number of requests might still allow the team to map ten recent handoffs. Not knowing who is authorized to share the records may prevent that step until the appropriate access is arranged. Different uncertainties require different responses.
Review the brief from three positions
Ask the person doing the work whether the situation sounds accurate. Ask the decision owner whether the proposed output would help them choose. Ask someone unfamiliar with the problem to explain the brief back in their own words.
If the explanations differ substantially, revise the relevant sentence. Do not solve a gap in understanding by adding pages of background that nobody will use.
Common questions
How long should the first version be? Short enough to read together in one sitting. Detail belongs where it changes scope, evidence or the decision; supporting records can remain separate.
Should a preferred solution appear? It can appear as an option or hypothesis. Keep the underlying problem and the evidence visible so the team can compare alternatives.
What if the scope changes? Record the new boundary, reason and effect on timing or effort. A visible change is easier to manage than an assumption that every new request was always included.
5. Use the brief to begin learning
Ask each participant which statement they would change and what evidence supports the change. Different answers may reveal a useful disagreement about the problem. Capture it rather than polishing the wording until the disagreement disappears.
After the first investigation, update the brief. Keep the original question visible and explain what you learned. A good brief is a working document: specific enough to guide the next action and small enough to revise when the evidence changes.