Six weeks after a team chooses a supplier, someone asks why the cheaper proposal was rejected. The minutes say only “agreed to proceed.” The decision survived, but its reasoning did not.
A useful decision log is short enough to maintain and specific enough to explain the trade-off later. It records the problem, the options considered, the choice, the owner and the conditions under which the decision should be reviewed.
Preserve the strongest alternative
Do not describe the rejected option as obviously foolish. Write why it was credible and what outweighed its advantages. In a fictional example, a lower-cost supplier may have offered suitable materials but could not meet the required delivery window. That explanation is more useful than “quality concerns” when quality was not the deciding issue.
Distinguish known facts from assumptions. “Delivery confirmed in writing” and “we expect demand to rise” belong in different categories. The second may be reasonable, but a later reader needs to know it was an expectation.
A compact entry
- Decision: use supplier B for the first production run.
- Alternative: supplier A costs less but cannot confirm the required date.
- Reason: the launch depends on that date.
- Review trigger: reconsider if the launch moves or supplier A confirms capacity.
- Owner and date: the person accountable for the choice and when it was made.
Keep sensitive commercial details in the appropriate restricted system. Link to supporting evidence rather than copying private correspondence into a widely shared document.
When circumstances change, add a new entry that refers to the old one. Do not rewrite history to make the earlier decision look inevitable. The record should show what the team knew at the time and why its choice was reasonable under those conditions. That makes learning possible without turning every changed decision into an argument about memory.