BEARINGS · R R Routes.
Phase: A Assess (pre-Gate A)
Routes keeps the program from backing into a preferred answer. It makes the viable options and the recommendation logic visible.
Using Options & scoring for structured options analysis
Routes is where SAGE makes options visible. The artifact functions as an options analysis
template: it names credible paths, compares them against a shared lens, and prepares the
recommendation for Scorecard. Without Routes, a program can look decisive while quietly
choosing the first attractive answer. With Routes, Gate A can see that the recommendation
was compared against alternatives and the cost of doing nothing.
Options analysis is broader than a pros-and-cons list. A useful comparison names the path,
the assumption behind it, the benefit it can deliver, the risk it carries, the constraints it
depends on, and the trade-offs it creates for stakeholders. That can include a technology
route, a process route, a policy route, a staffing route, a sequencing route, or a hybrid.
The artifact should be concrete enough that Instrument can turn the comparison into criteria and weighted scores.
Classic tools can still help. SWOT can expose strengths, weaknesses, opportunities, and
threats for a route. A BCG-style portfolio view can help when options compete for investment
across lines of business. Routes does not replace those tools; it gives SAGE a stable place
to record their output. The page identity stays Options & scoring because the point is not
the tool. The point is that the program can explain which options were considered, why some
were rejected, and why the selected path deserves Gate A attention.
Routes should include options that are meaningfully different from each other. Comparing three
versions of the same preferred answer is not options analysis; it is packaging. A credible
options analysis template should show at least one alternative path, the cost of doing
nothing, and the reason weaker options were removed from consideration. That keeps the
recommendation honest before Scorecard applies weights and evidence.
How to compare options in SAGE
- Enumerate candidate solutions. Start from the causes in Baseline and the measurable outcome in Aims. List real alternatives, including "do nothing" when
it remains a viable choice.
- Define a shared evaluation lens. Decide what matters before scoring:
value, speed, cost, risk, customer impact, operational load, compliance fit, and ability
to sustain the change.
- Apply a consistent scoring framework. A simple low-medium-high or
one-to-five scale is often enough at this stage. The scale should be easy to carry into a
decision matrix template in Scorecard.
- Surface trade-offs explicitly. Write down what each option improves and
what it makes harder. A route that is fast but risky may still be right, but the trade-off
should not be hidden.
- Prepare the recommendation path. Routes does not need to make the final
decision alone. It should narrow the field and make the remaining comparison clean enough
for Instrument and Gate A.
Worked example — three delivery paths for a customer data platform
A customer data platform program has three plausible routes. Option one is to build a new
internal service. It gives the organization control but requires more architecture and
delivery capacity. Option two is to buy a vendor platform. It moves faster but creates
integration, data-governance, and operating-cost questions. Option three is to partner
with an enterprise data team that already owns adjacent tooling. It may deliver a smaller
first release but reduces governance and support risk.
Routes records each option against value speed, risk, cost, operating ownership, and data
control. The comparison shows that the vendor route is strongest on speed, the internal
build is strongest on control, and the partnership route is strongest on balance. That
does not make the decision automatic. It gives Scorecard the evidence needed to build a
weighted comparison and gives Gate A a transparent record of the trade-off analysis.
What good options analysis avoids
Good options analysis avoids false precision, false choice, and hidden constraints. False
precision appears when the team assigns detailed numbers without evidence. False choice
appears when the options are not truly different. Hidden constraints appear when a path is
impossible for policy, funding, architecture, or operating reasons but remains in the table as
if it were viable. Routes should expose those issues before the recommendation reaches Gate A.
The output should be short enough to compare and specific enough to challenge. If an option
cannot be explained in plain language, the team probably has more shaping to do before it can
be scored.
Options analysis template (download)
Use the downloadable template as a working canvas for this BEARINGS artifact. It is
intended for drafting, review, and gate-readiness conversations before the record is
captured in SagePM.
The PDF is deliberately lightweight. Use it to structure the conversation, capture
the first pass, and expose gaps. The durable record should still point back to
evidence, owners, assumptions, and related BEARINGS artifacts so the download does
not become a detached side document.
In review, treat the completed template as a prompt for questions rather than a
finished approval packet. Ask what evidence supports the claim, which stakeholder
has validated it, what uncertainty remains, and which downstream artifact depends
on the answer. If the template exposes missing proof, unclear ownership, or a weak
decision path, keep working the artifact before carrying it into a gate conversation.
That discipline is what lets the BEARINGS page act as a template target without
changing the artifact's canonical SAGE name.
For teams using the PDF outside the SagePM app, keep the completed file near the
program record and link it from the relevant TAP Log thread or gate packet. The
template should make review easier, but it should never become the only place where
a decision, assumption, or owner is known.
When in doubt, use the template to ask one more evidence question before asking for
approval. If the answer changes the recommendation, the artifact is still doing
useful work; if it does not, the team has a stronger record for the gate.
Either outcome is better than treating the artifact as a checklist.