Decision Quality Checklist

A well-framed decision has a clear scope, a specific timeline, and an identified decision maker. In practice, "framing" means writing the decision as one concrete sentence that everyone agrees on. Most decision failures start here: the team thinks they are deciding "which CRM to buy" but half the room is actually debating "whether we need a CRM at all." When the frame is weak, every subsequent step wastes effort because people are solving different problems. Test: can you state the decision in one sentence that every stakeholder would agree with?

At least three genuinely different options prevent the dangerous trap of binary thinking ("do it or don't"). Binary framing eliminates creative solutions that might be better than both options. Good alternatives are realistic (each one could actually be implemented), distinct (not minor variations of the same idea), and include at least one option that challenges assumptions. A team that only considers "AWS vs. staying on-premise" has not genuinely explored alternatives. Azure, Google Cloud, a hybrid approach, and managed hosting are all viable options that change the calculus.

Identify what you know, what you don't know, and what you need to find out before deciding. The goal is not perfect information (which never exists) but sufficient information: enough to differentiate between options on the criteria that matter. What "good" looks like: for each option, you have data on the 3-5 factors that matter most. What goes wrong when this is weak: teams decide based on assumptions they never tested, then discover mid-implementation that a critical assumption was wrong. The cheapest time to gather missing data is before you commit.

Success criteria must be explicit and agreed upon by all decision makers before options are evaluated. "What does good look like?" should have a specific, measurable answer. Without defined values, each person evaluates options against their own private criteria, which leads to the illusion of agreement: everyone votes for Option B, but for completely different reasons. When values are strong, two people evaluating the same options would weight the same criteria similarly. When values are weak, a CFO optimizes for cost while a CTO optimizes for scalability, and nobody realizes they are solving different equations.

The logic connecting your information to your recommendation should be clear enough that a skeptic could follow it and challenge specific links. Good reasoning is documented: "We chose Option B because it scored highest on our three most-weighted criteria (integration, scalability, cost) in the Decision Matrix." Bad reasoning is implicit: "We went with Option B because it felt right." When reasoning is weak, the decision cannot be explained to someone who was not in the room, cannot be audited later, and cannot be improved next time because nobody knows which link in the logic chain was wrong.

The best analysis is worthless without buy-in from the people who will execute. Commitment means the implementers were part of the evaluation (not just informed after the fact), they understand and agree with the rationale, and they have the resources and timeline to execute. A decision that leadership makes without consulting the team who builds it typically fails not because the analysis was wrong but because the team either resists passively or discovers execution barriers that leadership never considered. Test: does everyone who needs to execute this decision agree with it, or are they merely compliant?