A risk register that evolves into a decision log is one of the most useful artifacts a program can produce. The pre-mortem nobody ran generated eighteen risks; by the time the engagement ended eight weeks later, those risks had grown into a forty-seven-entry decision log that became the single most referenced document in steering committee meetings. What started as a risk exercise became the program’s institutional memory.
Specific Risks Produce Actionable Decisions
The pre-mortem followed the standard format: assume the program has failed, then identify the most likely reasons. The eighteen risks clustered into four categories:
- Resource conflicts (i.e., shared resources that multiple workstreams needed during overlapping windows)
- Dependency failures (i.e., handoffs with no fallback if one side delivered late)
- Organizational constraints (i.e., blackout windows, budget cycles, and leadership availability gaps)
- Alignment gaps (i.e., places where two stakeholders had fundamentally different assumptions about scope or priority)
Each risk was specific enough to act on. “The pilot store selection will be contested because the regional VPs were not consulted” generates a clear next step. “Stakeholder alignment may be a challenge” generates nothing. The pre-mortem format produces the first kind because it asks people to describe how the program failed, which forces specificity. That specificity is what makes designing for failure productive rather than demoralizing.
Triage Turns Risks into Recorded Decisions
The pivot happened during triage, when we asked a single question about each risk: what are you going to do about this? Every answer fell into one of two categories:
- Accept the risk and monitor it
- Mitigate it with a specific action now, or redesign the plan so it no longer applies
Each answer was a decision, and each decision required a rationale and an owner on record. The risk about contested pilot store selection produced a decision to brief the regional VPs before the selection was announced. The risk about a shared testing environment produced a decision to split integration testing into two phases with dedicated windows. The risk about a vendor’s missed delivery dates produced a decision to build a two-week buffer into every dependent milestone.
We captured each decision in the same artifact that held the original risk. The risk register gained new columns: decision taken, decision owner, and date. The eighteen risks became the first eighteen entries in what was now functioning as a decision log.
A Shared Format Makes Logging Decisions Reflexive
Over the next eight weeks, the decision log became the natural home for every cross-functional tradeoff the program encountered. Resource allocation conflicts from roadmap sessions and governance design decisions from operating model work all went into the log with the same structure: what was decided, by whom, on what date, and with what rationale. The constraints calendar fed directly into many of these decisions by revealing execution windows that shaped the tradeoffs.
The log grew because the team had a place to put decisions and a habit of recording them. The pre-mortem established the practice of writing down what was decided and why; the roadmap sessions extended that practice to scope decisions; the operating model sessions extended it to governance decisions. By week ten, logging a decision was reflexive rather than facilitated.
Decision Logs Turn Steering Committees into Decision-Making Bodies
The decision log became the primary steering committee artifact because it answered the question steering committees actually care about: what has been decided and on what basis? Status updates tell a steering committee what’s happening, and the roadmap tells them what’s planned, but the decision log tells them what tradeoffs have been made. When the executive sponsor asked “why did we push the pilot by two weeks?” the answer was a specific entry with the rationale, the alternatives considered, and the name of the person who made the call.
This specificity made the steering committee more efficient. Instead of relitigating decisions already made, the committee could review the log, confirm they agreed with the tradeoffs, and focus their time on the open decisions that needed their authority.
The value of a risk register is the decisions the risks force. Every risk requires the team to choose: accept it or change the plan. Those choices are the first real decisions a program makes, and recording them in a structured format creates a practice that extends to every subsequent decision. By the time the transfer of ownership happened, the decision log with its forty-seven entries was the most complete record of how the program had been designed.
