Decision criteria: how to define what makes an option better

Decision criteria are the factors you use to judge whether one option serves your purpose better than another. Useful criteria connect to the outcome you want, have a clear meaning, and can be assessed using relevant evidence. Define them before comparing the options in detail, then make any later changes visible.

“Choose the best approach” is not yet a decision rule. Best might mean the fastest start, the lowest ongoing effort, the easiest reversal or the strongest fit with a particular need. A team can agree on the word while disagreeing about every factor underneath it.

This explainer shows how to turn a discussion into a workable set of criteria, distinguish mandatory requirements from preferences, and use a simple example without pretending a score removes judgement. It is for ordinary project, product and operational decisions; formal procurement and other consequential decisions may require a more rigorous process.

What counts as a decision criterion?

A criterion identifies something that matters when comparing alternatives. It is not the alternative itself, the evidence used to assess it, or the final recommendation.

For example, a team choosing how to onboard new clients might compare the staff effort required per client. An estimate of three staff-hours is a piece of performance evidence. A preference for reducing that effort is a judgement about what matters. “Use a guided onboarding session” is an option, and “pilot guided sessions with the next cohort” is a possible recommendation.

Keeping these parts separate helps people challenge the right thing. Someone may accept the criterion but question the estimate. Another person may trust the estimate but think client understanding matters more than staff effort.

Decision-analysis practitioner 1000minds describes criteria as the things that matter when choosing between alternatives and distinguishes numerical measures from qualitative assessments. Its guidance also highlights unclear wording and overlapping criteria as sources of difficulty. 1000minds: identifying decision criteria

A practical working record for each criterion can contain its name, what it means for this decision, what evidence you need, and how you will interpret that evidence. The point is shared understanding, not a long form for its own sake.

Start with the decision and its owner

Before listing criteria, write one sentence describing the choice. Include the scope and the person or group authorised to decide.

For example: “The operations lead will choose which onboarding approach to pilot with the next small client cohort.” That is narrower than “improve onboarding”. It tells you that the immediate decision concerns a pilot, not a permanent company-wide rollout.

Then identify the desired outcome. Perhaps clients need to complete a first useful task with fewer avoidable support exchanges. Criteria should help assess that outcome and the practical consequences of each approach.

Ask who will experience those consequences. The person approving the pilot may not be the person delivering it or using the result. Invite relevant perspectives before fixing the criteria. A recording of one stakeholder’s preferences does not establish agreement across the whole team.

Finally, state what is outside the decision. If a contractual requirement or existing organisational rule is fixed, record it. If a boundary is merely assumed, label it as an assumption and identify who can confirm it. The distinction between project assumptions and risks is useful when uncertainty is being mistaken for a firm constraint.

Separate requirements from preferences

A mandatory requirement determines whether an option is eligible. A preference helps compare eligible options. Treating them as interchangeable can produce a misleading result.

If the pilot must run within an approved environment, an option that cannot meet that requirement should not become acceptable because it scores well on convenience. Conversely, a team may prefer a short preparation time without making one particular deadline an absolute exclusion rule.

Think of a requirement as a gate and a preference as a scale. For each proposed gate, ask:

• Who has authority to make it mandatory?

• What would demonstrate that an option passes?

• Is the requirement genuinely fixed, or could the decision owner reconsider it?

• What happens if the evidence is missing?

“Unknown” is an important state. It should not silently become either “passes” or “fails”. If eligibility depends on an unanswered question, assign a check before treating the option as ready for selection.

The UK Government Analysis Function’s introductory MCDA guide explains that some numerical methods allow strong performance on one criterion to compensate for weak performance on another. It discusses minimum thresholds as one way to eliminate unsuitable options before such comparison. That is a useful reason to make non-negotiable requirements explicit. Introductory guide to MCDA

Turn vague labels into assessable criteria

Words such as “quality”, “simple” and “strategic” are starting points for discussion. On their own, they give reviewers too much room to apply different meanings.

Try completing this sentence: “For this decision, by this criterion we mean …” Then describe the evidence that would change your assessment.

These are illustrative criteria, not universal definitions. A different decision may need different evidence. “Easy to use” for an experienced administrator is not necessarily the same as “easy to use” for a first-time client.

For qualitative criteria, describe what stronger and weaker performance would look like. If you use labels such as low, medium and high, give them meaning in context. A number from one to five does not fix ambiguity if reviewers still disagree about what the numbers represent.

Avoid counting the same benefit more than once

A long list can create an appearance of completeness while repeating one preference under several names. “Quick to set up”, “short implementation time” and “rapid launch” may all describe substantially the same advantage.

Check each pair of related criteria. Ask whether a change in the underlying evidence would move both assessments for the same reason. If so, consider combining them or tightening their definitions. Do not automatically combine everything that is related: preparation effort and ongoing delivery effort can matter separately when they create different consequences.

Write a short reason for keeping any distinction that looks similar. For example: “Preparation effort concerns the one-off pilot setup; delivery effort concerns repeated staff time for each client.” That makes later discussion more precise.

Also watch for criteria that merely restate a preferred option. “Uses our favourite platform” may conceal a legitimate need such as compatibility or training effort, but the platform name itself can predetermine the answer. Name the underlying outcome and assess every viable option against it.

A worked example: choosing an onboarding pilot

Consider a fictional small team choosing between two approaches: a live guided session and a self-paced walkthrough. The team has already agreed that either approach must use its approved tools and fit within the authorised pilot scope. Those are gates; the example does not assume that every option has passed without checking.

For the eligible options, the team proposes three criteria:

1. Client understanding: how well the approach helps clients complete the first agreed task and recognise what to do next.

2. Recurring staff effort: the work required for each additional client, including predictable follow-up.

3. Ease of revision: how readily the team can correct confusing material during the pilot.

Before comparing, the team defines what it knows and what it still needs to learn.

Notice what this table does not do. It does not assign a winner from attractive descriptions. It keeps untested performance visible and identifies checks that could alter the choice.

The next action may be a smaller comparison or a limited trial, rather than an immediate permanent selection. If the decision must be made before all checks are possible, record the assumptions being accepted and the conditions that would trigger a review.

After the pilot, new evidence may justify changing the assessment. Keep the original criteria and the reason for any revision so the team can distinguish learning from moving the goalposts.

When should you use weights and scores?

Weights and scores can help structure a discussion when several criteria compete. They can also conceal disagreement behind a precise-looking total. Use them only when the team understands the scales, the trade-offs and the limits of the evidence.

Start by asking what improvement actually matters. A small improvement in an already satisfactory area may be less valuable than resolving a serious weakness elsewhere. Simply saying that “quality is twice as important as speed” leaves the relevant performance ranges undefined.

For a low-consequence choice, a transparent qualitative comparison may be enough. If you use a simple scoring sheet, label it as a discussion aid and record the reasoning alongside each score. Missing evidence needs an explicit treatment; do not give an unknown a neutral-looking middle score and forget that it is unknown.

For decisions requiring greater rigour, use an appropriate method and someone qualified to apply it. The Government Analysis Function guide distinguishes simpler and more demanding approaches and stresses that decision analysis supports judgement rather than capturing every nuance. It also includes sensitivity analysis in reviewing the output. MCDA methods and review guidance

A practical sensitivity question is: “Would a plausible change in this assumption or preference change our recommendation?” If the answer is yes, show that dependency to the decision owner. Do not report a close or fragile result as an obvious winner.

Use meeting evidence without turning it into approval

Stakeholder conversations can help identify desired outcomes, concerns, requirements and disagreements. A transcript preserves wording, but it does not decide which comments should become agreed criteria.

When reviewing a recording, separate statements into useful working categories: a proposed preference, a confirmed requirement, an estimate, an assumption, or an unresolved disagreement. Keep the source and surrounding context. A remark such as “we probably need this ready next week” is not equivalent to an authorised deadline.

In Weeve, you can ask Chat to draft candidate criteria from relevant recording material and then open the cited sources to check the wording. Use a bounded request such as:

From the selected discussion, list proposed decision criteria and their supporting passages. Separate explicit requirements, preferences, estimates and unresolved disagreements. Do not invent weights, treat suggestions as approvals, or fill missing evidence with assumptions.

The screenshot shows a source reference in a synthetic demonstration conversation. It illustrates the route back to a recording source, not an actual criteria analysis or a claim that the software verified a decision.

Check whether each cited passage supports the proposed criterion and whether another part of the discussion qualifies it. A citation is a route for review, not a guarantee that the interpretation is correct or that every relevant conversation was considered. Compare the draft against the material you intended to review and ask people to resolve ambiguities.

Local Chat processes the task on your Mac. Choosing an optional external provider sends relevant messages and source text to that provider; anonymisation can miss identifying details. Choose the processing route appropriate to the material you are reviewing. The team remains responsible for agreeing criteria, confirming evidence and making the decision.

Keep a short record of changes and disagreement

Criteria may change for good reasons: a newly confirmed constraint, a better understanding of the problem or a missing stakeholder perspective. Record what changed, why, who agreed it and whether all options were reassessed consistently.

If people disagree about priorities, make the disagreement explicit. You may need separate comparisons under different priorities, more evidence, a narrower decision or a decision owner’s judgement. Averaging everyone’s numbers can hide a disagreement that the final approver needs to understand.

Once a recommendation is ready, explain it in a decision memo: the choice, evidence, trade-offs and remaining uncertainty. After approval, use a decision log to record what was actually agreed. The criteria help explain the reasoning; they are not themselves an approval record.

A final review before comparing options

A useful set of criteria should let two reviewers discuss the same question using recognisable evidence. Check that every criterion connects to the desired outcome, mandatory requirements are separate, terms and scales are clear, overlapping benefits are not counted repeatedly, and unknowns remain visible.

Then ask one final question: “Could evidence change our recommendation?” If no plausible finding could change it, be clear whether you are still evaluating alternatives or documenting a choice already made. Honest purpose makes the resulting record more useful than a scoring exercise that only confirms a predetermined answer.