Was it a bad decision, or a reasonable bet that failed?

Evaluate a failed decision by reconstructing the information, alternatives, and reasoning available when the commitment was made. Review the outcome and the decision process separately. A poor result can expose a weak process, but the result alone cannot establish what the decision maker should have known.

Outcome bias is evaluating a decision through its eventual result rather than the information and reasoning available when it was made, allowing luck to distort judgments of quality. This definition follows Outcome Bias in Decision Evaluation (Jonathan Baron and John C. Hershey (1988), originating experiments). Hindsight bias concerns inflated foreseeability rather than evaluation of decision quality. Apply the distinction to the approval record and the later response separately, so neither hindsight nor uncertainty settles the whole evaluation.

A private moment that makes the issue visible

Composite scenario, not a client case: You discuss a failed project at home and find the warning signs suddenly obvious. At work, the team remembers the earlier choice as unreasonable even though the decision record described uncertainty. The disappointing outcome is changing the account of what was knowable.

State the decision before discussing personalities

The review must assess both learning from the result and the quality of the original process. Do not use uncertainty as an excuse to ignore evidence that should have been checked.

Proposed method: commitment-time decision reconstruction

Recover the original record. Gather the dated recommendation, assumptions, and evidence. Distinguish contemporary records from later recollections. Ask the records owner to preserve the version used for approval. Later revisions belong beside it, with their dates. Do not let the final project account replace the document that informed the initial commitment.
Separate information by timing. Identify what was available then, what reasonably should have been obtained, and what emerged only afterward. Create separate columns for available information and information the process should have sought. Give a reason for each expected check. Avoid treating anything discoverable in hindsight as something every reasonable decision maker necessarily knew.
Evaluate the actual reasoning. Review alternatives, consequences, and relevant objections. Use the original context rather than treating the known result as inevitable. Use the same questions on a successful decision. Explain any difference in the evaluation standard. A favorable outcome should not erase an omitted control that would concern you after a loss.
Learn from the outcome. Check which assumption failed and whether the result supplies new evidence. Keep luck and a process failure available as distinct explanations. Locate the first actionable warning after approval. Ask what response was possible then. Evaluate that response separately from the original bet so one error does not become an unsupported judgment about the whole process.
Choose a process correction. Improve a specific recurring practice. Avoid punishing a reasonable risk merely because it resolved badly or celebrating a weak process because it succeeded. Assign a specific change to the proposal, monitoring, or escalation process. Describe the next decision where it will be used. Stop adding requirements that have no demonstrated connection to the gap found in the review.

Rebuild the meeting before the result was known

Start with the materials the decision maker actually received. Use the original proposal, its version date, the recommendation, and the objections recorded before commitment. Put later information in a separate part of the review. If a participant says everyone knew something, ask where that information appeared and whether it reached the person making the choice. Treat an absent record as a limitation, rather than inventing a confident reconstruction from the current consensus.

Distinguish information that existed somewhere from information a responsible process should have obtained. A supplier warning buried in an unrelated correspondence chain is different from a warning addressed to the project sponsor. Both may expose a process problem, but they require different corrections. Describe the expected search or escalation duty before judging whether the decision maker neglected it. Ask a qualified specialist to assess technical information that the review team cannot evaluate reliably.

Baron and Hershey’s 1988 experiments concern evaluations of decisions when their outcomes are known. They used described medical decisions and monetary gambles, rather than a study of your executive team. The useful application is a disciplined question: would you judge the same reasoning differently if the result had been favorable? This question does not establish that the original choice was good. It helps you examine whether the outcome is doing too much of the evaluative work.

Use the same process standard for wins and losses

Write a short assessment standard before evaluating the individual choice. Include whether the team identified serious alternatives, examined important constraints, and assigned responsibility for monitoring. Apply that standard to a comparable successful decision as well. If a winning project would escape a criticism leveled at the failed one, explain the difference. The point is consistency in evaluation, rather than equal praise or blame for projects with different circumstances.

Ask what made the result possible. A thoughtful decision can encounter an unfavorable event that was recognized but not controllable. A careless decision can benefit from a favorable event no one anticipated. Keep those possibilities available while examining the actual record. Do not label a result luck merely because it inconveniences your preferred explanation. Identify the event, its relevance, and what a reasonable monitoring process could have done when it emerged.

For a hypothetical comparison, consider two launches with similar approval processes. One succeeds after a distributor expands its coverage; the other fails after a distributor withdraws. Inspect what each team knew about those dependencies before launch. If neither team checked capacity or assigned monitoring, the successful launch also deserves a process correction. If one did and the other did not, the difference belongs in the evaluation. The outcome alone cannot supply that missing comparison.

Separate the approval decision from the later response

Use two review periods: before commitment and after warning signs appeared. The first asks whether the decision was defensible with the available information. The second asks whether the organization responded appropriately to new evidence. A reasonable initial bet does not excuse ignoring a later warning. An unsuccessful response also does not prove that the initial decision was irresponsible. Assign each criticism to the period and obligation it concerns.

Have the project owner identify the first point at which the information changed enough to require attention. Then inspect who received the signal and what choices remained available. Avoid asking why the team did not select an option that was no longer feasible by that date. If the monitoring arrangement failed, specify whether the weakness was detection, escalation, authority, or execution. A broad instruction to exercise better judgment leaves those different problems unresolved.

Fischhoff’s hindsight findings support preserving uncertainty in the reconstruction. They do not authorize replacing accountability with a statement that nobody could know the future. Ask what was foreseeable, what was explicitly considered, and what remained unknown. Retain the actual language of the original assumptions where possible. Rewriting a tentative statement as a firm prediction after the fact makes the record less useful for both learning and fair evaluation.

Turn the finding into a limited process change

Choose a correction linked to an observed gap. If a critical dependency had no owner, assign one and describe its escalation trigger. If alternatives were presented unfairly, change the proposal format. If the team had the necessary evidence but lacked authority to pause, repair the decision rights. Avoid requiring every future proposal to include a large new appendix because one review found a specific omission. Explain which kinds of decisions need the added check.

Discuss the result with the person whose decision is being evaluated. Show the record and the standard you applied. Invite them to identify missing contemporary information before finalizing the account. You do not need their agreement with every judgment. You do need a fair opportunity to correct factual errors. Keep employment consequences with the appropriate review process, and avoid representing this proposed reconstruction as a validated performance-rating instrument.

Close the review by recording what future teams should do differently and what they should continue doing. Keep the approved correction beside the original evidence and identify who will check its use. Give the decision maker a copy of the completed account. A record that contains only the lesson from failure can discourage a defensible risk the company still needs to take. Name the boundary: which uncertainty was acceptable, which omission was avoidable, and what information should reopen the decision. At the next comparable choice, inspect whether the correction helps the team decide, rather than whether it guarantees a favorable result.

Put the boundary into words

We will examine the result and reconstruct the decision separately. Show what was known, what should have been checked, and what became known later. Then identify the process change that the evidence supports.

Work through a bounded example

Hypothetical application: A launch fails after an external dependency changes. The record shows that leaders identified the dependency but never assigned monitoring. The review distinguishes uncertainty from the avoidable monitoring gap instead of calling the whole decision either blameless or obviously foolish.

Check the failure mode before scaling

Do not assume every loss is bad luck or every success proves competence. Avoid a retrospective standard no decision maker could have met. Use qualified experts for the actual financial, technical, or legal question.

Review the work, then revise the arrangement

Review whether the chosen correction addresses the failed assumption or information gap. Preserve a record that later teams can learn from without rewriting the original uncertainty.