Skip to content
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.

Artifacts

Stakeholders

Purpose

Name the people and groups who sponsor, decide, approve, influence, operate, or are affected by the program.

How to use it

  • Map each stakeholder to their role in the decision and delivery path.
  • Record influence, expected posture, and engagement cadence.
  • Flag gaps where a required approver or operator is not yet named.

Example

The branch operations director approves process change, risk reviews exception handling, and store managers provide weekly adoption feedback.

Owner

The program lead maintains it with sponsor input; accountable leaders confirm named roles before Gate A.

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Record open conflicts. If the sponsor wants speed while operations wants control, record the conflict directly. That tension belongs in Routes and Scorecard.
  6. 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.

FAQ

What is stakeholder analysis?

Stakeholder analysis identifies the people and groups that can affect, approve, use, block, operate, or benefit from a program. In SAGE, Stakeholders captures that analysis before options and recommendations go to Gate A.

What is the difference between stakeholders and sponsors in a program?

A sponsor owns the value claim and has authority to fund or approve the program. Stakeholders are broader: they may decide, influence, operate, review, or be affected by the work without owning the full value claim.

How often should stakeholder analysis be updated?

Update stakeholder analysis whenever scope, ownership, operating impact, or approval authority changes. At minimum, review Stakeholders before Gate A, before Gate B, and during major delivery or adoption changes.

Do you need a RACI if you have a stakeholder analysis?

Usually yes, but they answer different questions. Stakeholder analysis explains influence, interest, posture, and engagement. A RACI clarifies responsibility and accountability for specific activities, which SAGE captures in Governance.

How does SAGE Stakeholders relate to a standard stakeholder matrix?

A standard stakeholder matrix often maps people by power and interest. SAGE Stakeholders can include that view, then extends it with decision roles, engagement cadence, conflicts, and links into Governance and the TAP Log.