B Baseline.

Using Roots as a root cause analysis template

Roots is the SAGE artifact that turns a visible problem into a set of causes the program can act on. A generic root cause analysis template usually gives a team boxes for problem statement, contributing factors, cause categories, corrective actions, and ownership. Roots keeps that discipline, but it is deliberately narrower: it is not trying to plan the fix yet. It asks the team to prove the condition exists, identify causes that matter, and mark the unknowns that still need validation in Assess.

That distinction matters because many programs start with a preferred answer. A team may believe the answer is automation, training, a new dashboard, a policy change, or another headcount request before anyone has tested the chain of evidence. Roots slows that jump down. It uses root-cause analysis to make sure the program is aimed at a cause rather than a symptom, and it gives Gate A reviewers a cleaner line from problem to recommendation.

Teams can still use familiar RCA techniques inside the artifact. The 5 whys are useful when a problem appears to have one dominant causal path. A fishbone diagram, also called an Ishikawa diagram, is useful when many categories of cause may be interacting. The output of either technique belongs in Roots only when the team can connect it to evidence and say what would have to change. For background on common RCA techniques, see ASQ's root cause analysis overview and the Ishikawa diagram reference.

A strong root cause analysis template also prevents cause language from becoming vague. "Poor communication" is rarely useful by itself. Roots pushes the team to name the communication path, the handoff, the owner, the service target, and the evidence. "Manual identity-check exceptions sit in a shared mailbox with no service target or owner" is a cause that can be owned, scored, and changed. That is the level of specificity SAGE needs before the program enters Engagement, Aims, Routes, and Instrument.

Roots should also protect the team from over-fitting the analysis to the first available data source. Operational metrics, customer complaints, support tickets, interview notes, and process observations each reveal only part of the story. A good root cause analysis template asks what the team knows, how it knows it, and what evidence would change the conclusion. That makes the artifact useful for both skeptical executives and people close to the work, because each cause can be discussed on the basis of proof rather than authority.

The best Roots records are also written in language a gate reviewer can act on. "The team is understaffed" may be true, but it does not yet explain whether the issue is demand shape, manual rework, role design, training, policy friction, system latency, or decision delay. A stronger cause statement names the mechanism: "exception volume exceeds reviewer capacity on Mondays because weekend applications batch into one queue and no triage rule separates standard exceptions from complex cases." That wording can lead to options.

How to run root-cause analysis in SAGE

1. State the evidenced condition. Start in S Scope with the current condition, affected population, impact, baseline, and proof. A root cause analysis template is only as good as the condition it analyzes.
2. Enumerate candidate causes. Name every plausible cause before choosing one. Include process gaps, system behavior, role ambiguity, policy constraints, data quality, operational load, and governance gaps.
3. Test each cause against evidence. For each candidate, ask what data, observation, or stakeholder account supports it. If the evidence is weak, keep the item as an assumption rather than treating it as fact.
4. Identify controllable causes. A cause may be real but outside the program's control. Roots should separate causes the program can influence from constraints that need escalation, acceptance, or a different sponsor decision.
5. Mark unresolved assumptions. Unknowns are not defects in the artifact. They are useful signals for Assess. Mark what must be validated before Gate A and who can validate it.
6. Commit the causal chain to Roots. Capture the chain in plain language with evidence links. The wording should be concrete enough that another reviewer can challenge it without reconstructing the team's discussion.
7. Hand the record to Assess. Stakeholders identifies who can approve and influence the response. Aims turns the problem into a measurable target. Routes and Scorecard compare paths against the causes Roots established.

Worked example — customer onboarding delay

Quality check before Roots leaves Scope

Before Baseline leaves Scope, the program lead should be able to answer six questions. Is the current condition evidenced? Are the named causes connected to that condition? Has the team separated symptoms from causes? Are the causes controllable by the program, the sponsor, or a named authority path? Are assumptions marked clearly? Can the next BEARINGS artifacts use the Roots record without asking the team to restate the whole analysis?

If the answer is no, the artifact is not ready for Assess. That does not mean the team must have perfect certainty. It means the uncertainty must be visible. Gate A can approve a program with known assumptions and named validation work. It should not approve a program where the root cause analysis template was used as a formality and the real recommendation came from preference.

The final test is whether Roots changes the next conversation. If the same solution would be recommended no matter what causes were recorded, the analysis has not done its job. A useful root cause analysis template should narrow options, sharpen stakeholder questions, and make the measurable goal more precise.