I Instrument.

Using the Scorecard as a decision matrix template

Scorecard is the SAGE decision matrix template. It turns the options from Routes into a defendable recommendation by comparing them against shared criteria, weights, scores, and evidence. Without that structure, the program can drift toward whichever option has the loudest advocate, the newest technology, or the cleanest slide. Scorecard makes the decision visible enough for Gate A to approve, challenge, or condition.

A standard decision matrix template helps teams compare options on common dimensions. SAGE adds two important controls. First, the criteria must trace back to the goal, constraints, risks, stakeholder needs, and root causes already captured in BEARINGS. Second, the artifact must preserve the rationale. A weighted total can guide the discussion, but it does not replace judgement. If leadership chooses the second-highest score because it has lower rollout risk, Scorecard should explain that choice in plain language.

The useful part of a weighted decision matrix is not the spreadsheet math. It is the discipline of naming what matters before the options are scored. Criteria might include cycle-time impact, cost, implementation risk, policy complexity, operational disruption, customer experience, compliance exposure, and time to benefit. Weights force the team to say which of those dimensions matter most. Evidence keeps the scoring from becoming opinion disguised as precision.

Scorecard also keeps the recommendation connected to governance. The Initiation Gate does not approve a generic choice; it approves a business case and a recommended route. The decision matrix template should therefore be readable by executives, operators, risk partners, and delivery teams. It should show the options, the scoring logic, the evidence, the unresolved assumptions, and the reason the selected path is worth moving into the post-Gate-A work in Assess.

A decision matrix template becomes much stronger when it separates the score from the evidence. A score of 4 for implementation risk means little unless the reviewer can see why the team chose 4, what assumptions support it, and what would make the score change. SAGE Scorecard treats the evidence note as part of the decision, not a comment field. That makes the matrix easier to review and harder to manipulate.

Scorecard also makes criteria design explicit. Criteria should not duplicate each other, reward the same feature twice, or hide a non-negotiable constraint as if it were only a preference. If compliance fit is mandatory, it may be a pass/fail screen before scoring. If customer impact and cycle-time impact are strongly related, the team should decide whether both belong in the decision matrix or whether one is enough. Clean criteria make the weighted decision matrix easier to defend.

How to build a weighted decision matrix in SAGE

1. Define options from Routes. Start with the options that survived the Routes discussion. Include "do nothing" when it is a credible alternative, because it carries cost and risk too.
2. Define criteria. Use the goal, root causes, stakeholder needs, constraints, and risks to name the decision lens. Each criterion should be clear enough that different reviewers understand what a high or low score means.
3. Weight criteria. Weight before scoring. If cycle-time reduction matters twice as much as implementation speed, the matrix should say that before any option gets a score.
4. Score with evidence. Assign scores and document the basis. Evidence may be data, vendor input, operational experience, architecture review, policy analysis, or a clear assumption that still needs validation.
5. Review weighted totals. Totals are a guide, not a command. Use them to find disagreements, weak evidence, and criteria that may be overweighted or unclear.
6. Document recommendation rationale. Explain the selected path. If the recommendation is not the top numeric score, explain the leadership judgement and trade-off.
7. Route the decision to Gate A. Carry the Scorecard into the BRD and Gate A record so approvers can see how the recommendation was made.

Worked example — build vs buy vs partner

Common Scorecard failure modes

The most common failure is scoring after the recommendation has already been chosen. The second is changing weights until the preferred option wins. The third is using criteria that are too vague to challenge, such as "strategic fit" without a definition. The fourth is leaving out "do nothing" because the team assumes action is required. Scorecard exists to make those shortcuts visible before Gate A.

A healthy decision matrix template invites disagreement. If stakeholders score the same option differently, the difference can reveal missing evidence or a hidden trade-off. The program lead should not smooth that disagreement away too quickly. Capture it, resolve what can be resolved, and carry material judgement calls into the recommendation rationale. Gate A approvers need to see where the team had evidence and where leadership judgement is being requested.

The Scorecard is ready when a reviewer can understand the decision without replaying the workshop. The criteria should be defined, weights should be visible, scoring should have evidence, and the recommendation should explain the trade-off leadership is being asked to accept. That is what turns a decision matrix template into a governance artifact rather than a spreadsheet.