Decision Journal and Outcome Review

Preserve the original evidence and expectations, then diagnose the gap between forecast and outcome without using hindsight as proof.

Reviews that teach the wrong lesson

Writing the rationale after the result is known
Treating every bad outcome as proof of a bad decision
Collecting reviews without changing a future rule or action

Capture the decision before the outcome

Write the options, owner, deadline, constraints, criteria, strongest evidence, unresolved unknowns, and chosen rule before committing. Include the best reason for the rejected option. This creates a fair record of what was knowable and prevents later memory from turning a difficult choice into an obvious one.

Keep the entry short enough to maintain. A useful record can fit on one page when it links to supporting calculations or documents. The goal is not to archive every thought. It is to preserve the assumptions and boundaries that could teach you something later.

Make expectations observable

For each important expected benefit or risk, state what you would observe and by when. Replace this should improve teamwork with a measure such as fewer handoff delays during the first six weeks, plus the source of that observation. Use ranges when a precise forecast would be invented.

Separate outcome forecasts from implementation commitments. A forecast might be wrong even when the team follows the plan, while a missed task is an execution issue. Recording both makes the review more diagnostic and stops a poor rollout from being mislabeled as a bad comparison method.

When the review shows that past investment is controlling the next step, apply the forward-looking sunk-cost decision rule.

Project platform: separating product fit from a training miss

A small agency chooses a project platform and predicts that setup will take three to five days, handoff questions will fall within a month, and export will remain usable. At the six-week review, setup took eight days because training was missed, handoff questions fell as expected, and export worked. The team keeps the platform, separates the implementation miss from product fit, and adds a named training owner to future software decisions.

Schedule reviews around learning

Choose a review date when meaningful evidence should exist, not simply a convenient calendar interval. Some choices reveal usability within days but cost, retention, or maintenance only after months. Use more than one checkpoint when early warning and long-term value appear at different speeds.

Define reopening triggers separately from review dates. A review gathers evidence; it does not automatically reverse the choice. A trigger names the threshold that justifies corrective action, a new comparison, or exit. This protects the decision from daily mood while allowing a real failure to be addressed promptly.

Separate process quality from outcome luck

At review, first hide the original prediction if possible and describe the observed outcome. Then compare it with the recorded range. A sound process can encounter a rare bad result, and a careless process can get lucky. Judge whether the method used relevant evidence, respected constraints, and represented uncertainty honestly.

Ask which error occurred: a missing factor, weak evidence, poor estimate, untested assumption, implementation failure, or random variation. That classification leads to a specific improvement. Simply writing choose better next time creates no reusable learning.

Turn one review into a better rule

Update a checklist, scoring anchor, evidence source, threshold, or trigger only when the review supports the change. Avoid broad rules from one unusual outcome. For repeated decisions, look across several entries for recurring forecast errors or criteria that never affect the choice.

Close the review with one process adjustment and one action on the current decision. The current action may be continue, repair, exit, or gather a named piece of evidence. A journal becomes valuable when it changes future behavior, not when it becomes a collection of polished retrospectives.

Before a high-commitment choice, use a premortem to define warning signs worth reviewing later.

The rule for changing the decision process

Change the decision process only when the original record shows a correctable flaw in evidence, assumptions, method, or execution, not merely because the outcome was disappointing.

Create a copyable decision record

Create and review the decision record

Snapshot
Record options, owner, evidence, unknowns, and rule before commitment.
Forecasts
Define observable outcomes, ranges, and dates.
Execution
Assign actions whose completion affects the result.
Review
Compare observations with the original record and classify the gap.
Learning
Choose one justified rule change and one current action.

Sensitive information that does not belong in the journal

A journal can contain sensitive personal, employment, health, or commercial information. Store only what is necessary, control access, and follow applicable retention and privacy obligations.