BEARINGS · E E Engagement.
Phase: A Assess (pre-Gate A)
Engagement starts Assess by making the human system visible. The plan cannot be governed until the people around it are named.
Using Stakeholders as a stakeholder analysis template
Stakeholders is the SAGE answer to a stakeholder analysis template. It gives the program a
clear way to name the people around the work before options, recommendations, and gates start
creating commitment. A program can have a strong problem statement and a defensible goal, but
it will still stall if the sponsor, decision-maker, operator, approver, influencer, and
affected teams are not visible.
A conventional stakeholder analysis template often starts with a power and interest matrix.
That is useful because it tells the team who needs close management, who needs active
consultation, who needs monitoring, and who simply needs clear updates. SAGE keeps that logic
but ties it to the BEARINGS sequence. The point is not to produce a pretty matrix. The point
is to make sure every later decision can be traced to the people who can approve, contest,
operate, or absorb it.
Stakeholders also keeps the program from confusing engagement with ownership. A RACI can say
who is responsible or accountable for an activity. Stakeholder analysis explains the human
system around the work: who has formal authority, who has informal influence, who carries
operational knowledge, who feels the change, and who must be brought in before a gate review.
The Governance artifact can later turn this into
accountability and decision rights, but Engagement is where the people are first made visible.
In SAGE, a stakeholder analysis template should help answer practical questions. Who can say
yes at Gate A? Who will challenge the business case? Who
owns the process after launch? Who can validate the cause from B Baseline? Who cares about the goal in A Aims? Who needs to review the path through A Assess? If the artifact does not answer those questions, it
is probably a contact list, not stakeholder analysis.
A useful Stakeholders record should also distinguish posture from preference. A stakeholder
may support the outcome but resist the path because it adds operational work. Another may
oppose the timing but agree with the recommendation. A third may appear neutral because they
have not seen the evidence yet. Capturing that nuance helps the program choose the right
engagement pattern: executive alignment, working-session design, risk review, adoption
feedback, or simple awareness.
The artifact should not become a political map that only the program lead understands. It
should be concrete enough for the team to act on. Each important stakeholder should have a
role, an engagement need, a cadence, and a reason they matter. If someone is named as an
approver, the approval they own should be clear. If someone is named as an influencer, the
source of influence should be clear. That is what makes the stakeholder analysis template
useful at Gate A.
How to run stakeholder analysis in SAGE
- List candidate stakeholders. Start wide. Include sponsors, functional
leaders, risk and compliance partners, finance, delivery teams, operators, customer-facing
teams, data owners, support teams, and any group affected by adoption.
- Classify power and interest. Use a power and interest view to decide who
requires close involvement, who requires periodic review, who needs targeted consultation,
and who only needs concise updates.
- Name decision-maker, influencer, and informed roles. Do not let the word
"stakeholder" hide authority. A stakeholder analysis template should make explicit who can
approve, who can block, who can shape the recommendation, and who must be informed.
- Agree engagement cadence. Set the forums and communication rhythm before
the program gets busy. Decide which stakeholders need pre-reads, which need working
sessions, and which need gate-ready summaries.
- Record open conflicts. If the sponsor wants speed while operations wants
control, record the conflict directly. That tension belongs in Routes and Scorecard.
- Keep the artifact current. Stakeholder posture changes when scope,
ownership, risk, or operational impact changes. Update Stakeholders when those signals
move, not only at a scheduled checkpoint.
Worked example — cross-functional transformation program
A digital onboarding program touches branch operations, central operations, risk, legal,
product, analytics, engineering, training, and customer support. A weak stakeholder list
would name the department heads and stop. Stakeholders asks for more. The branch
operations director is the operating sponsor because branch behavior must change. Risk
reviews exception handling. Product owns policy choices. Engineering owns queue
automation. Analytics owns baseline and benefit measurement. Store managers carry the
frontline signal because they see adoption friction first.
The power and interest view shows three groups needing close involvement: the accountable
sponsor, the operational owner, and the risk partner. Engineering has high influence but
does not approve the business case. Store managers have lower formal power but high
adoption impact, so they need a feedback cadence. That distinction changes the plan: Gate
A gets a sponsor pre-read, risk gets a focused review of exception assumptions, and store
managers get short weekly feedback loops once delivery starts.
Stakeholder analysis quality checks
Before Stakeholders is used in a gate packet, review it for four gaps. First, check authority:
are the real decision-makers named, or only their departments? Second, check adoption: are
the people who will operate or absorb the change represented? Third, check conflict: are
competing incentives visible, especially between speed, control, cost, and customer impact?
Fourth, check cadence: does the artifact say how each important stakeholder will stay
engaged?
Those checks keep stakeholder analysis connected to program execution. A stakeholder analysis
template that identifies power and interest but never changes the engagement plan is not doing
enough. In SAGE, the artifact should shape pre-reads, gate attendance, working sessions,
communications, decision rights, and TAP Log touchpoints. It should help the team know who
needs to be in the room before the missing voice becomes a delivery risk.
Stakeholders also helps the program decide what not to escalate. Some people need awareness,
not approval. Some groups need consultation on a narrow operational point, not a standing seat
in every forum. A clear stakeholder analysis template lets the team reserve scarce executive
time for decisions while still giving affected teams enough context to prepare for change.
Stakeholder 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.