the brief — risks
Risks
Two or three sentences. Not a general risk register — the specific unknowns that could invalidate the direction if they turn out differently than assumed. The one or two concrete things that, if they change, require the trio to reconvene before delivery continues.
Risks in the brief are directly traceable to the named unknowns in What We Learned. If a risk appears here with no corresponding unknown in What We Learned, either it is too generic to be a real risk for this brief, or it was missed in What We Learned and should be added there.
A risk written correctly — specific, traceable, actionable
✗ "There may be technical challenges with the school system integration. The timeline could be affected."
Generic. Applies to every integration project ever written. Cannot be acted on, tested, or resolved.
✓ "We have not observed the school admin's side of the submission flow. If the school system requires a specific file format rather than a platform-generated receipt, the Decisions section changes. This must be resolved before the submission Epic enters Scope — it cannot be deferred to implementation without risking a full solution rebuild."
A well-written Risk names the specific unknown, the specific consequence if it resolves badly, and the specific action required. It is actionable — someone can go and close it.
How to apply this
- ✓ Connect each risk to the named unknown in What We Learned. If you cannot find it, add it to What We Learned or reconsider whether this is truly a risk for this brief.
- ✓ Name the action required to close the risk. A risk with no action is an observation. A risk with an action is something that can be tracked and resolved.
- ✗ Do not write generic risks. "There may be scope changes" applies to all software projects. Name the specific thing that could invalidate this direction for this feature.