The SAGE methodology.

What SAGE is

SAGE is a program management methodology for taking work from intake through benefit verification without losing the problem, the approval trail, or the evidence behind the plan. It is built for teams that need more than a task tracker: PMO teams, digital enablement teams, operations teams, and cross-functional program leads who must show why work is funded, who owns it, how it will be governed, and how value will be measured.

The methodology has five visible stages when P0 Intake is included: P0 Intake, Scope, Assess, Generate, and Embed. The four SAGE phases are Scope, Assess, Generate, and Embed. BEARINGS supplies the artifact sequence inside Scope and Assess. Gates A, B, and C make approval explicit. The TAP Log keeps touchpoints, alignments, problems, actions, and decisions connected across the lifecycle.

The four phases

1. P0

   Intake

   Requests arrive as problem statements, get scored, and either move into Scope or receive a documented no. Intake protects program capacity by asking whether the request belongs in SAGE before the organization starts planning delivery.

   Work: Request, scoring, and prioritization

2. S

   Scope

   Define the problem with evidence and identify the causes that must change before planning starts. Scope keeps the team from approving a solution until the current condition, impact, evidence, and causal chain are clear.

   Work: B Baseline: Scope, Roots

3. A

   Assess

   Turn the problem into a governed plan through BEARINGS artifacts, Gate A business approval, and Gate B delivery approval. Assess is where stakeholder context, goals, options, recommendation logic, strategy, ownership, and measurement become reviewable.

   Work: E/A/R/I before Gate A; N/G/S before Gate B

4. G

   Generate

   Build, test, and prepare for launch with Gate C as the go-live approval. Generate turns the approved plan into delivery work while keeping readiness, risks, decisions, and evidence connected to the approved business case.

   Work: Blueprint, Sprint 0, delivery sprints, cutover readiness

5. E

   Embed

   Stabilize the change and verify the claimed benefits with evidence. Embed keeps the program accountable after launch by checking whether the measurable claim from Assess appears in operations.

   Work: Hypercare, KPI and QBA reviews, benefit verification

BEARINGS artifacts

BEARINGS gives Scope and Assess a fixed sequence of artifacts. B Baseline belongs to Scope. E/A/R/I create the business case before Gate A. N/G/S complete the delivery plan before Gate B. The sequence matters because each artifact supports a specific decision. Baseline defines the problem and causes. Engagement names the people around the work. Aims defines the measurable outcome. Routes compares possible paths. Instrument makes the recommendation defensible. Navigation sequences the approved path. Governance names ownership and authority. Signals defines benefit evidence.

• B Baseline Scope · Roots
• E Engagement Stakeholders
• A Aims Goals
• R Routes Options & scoring
• I Instrument Scorecard
• N Navigation Strategy
• G Governance Accountability · Decision rights
• S Signals Measurement plan

How the artifacts create governance

SAGE treats artifacts as decision infrastructure. Each artifact answers a question that a gate reviewer, sponsor, delivery lead, or operator will eventually ask. Scope answers what is happening and why it matters. Roots answers why it is happening. Stakeholders answers who can approve, influence, operate, or absorb the change. Goals answers what measurable outcome the program claims. Options & scoring answers which paths were considered. Scorecard answers why one path is recommended.

After Gate A, the artifact sequence changes from business case to delivery readiness. Strategy answers how the approved route will be sequenced. Accountability answers who owns the work and handoffs. Decision rights answers who can resolve predictable decisions. Measurement plan answers how the program will know whether the benefit appears. Together, those artifacts make Gate B more than a planning checkpoint. They make it a review of whether the organization is ready to execute.

This is why SAGE is useful for program work. Programs often fail less from missing tasks than from missing decisions, unclear authority, vague value claims, and evidence that never follows the work into operations. BEARINGS gives the program a way to expose those weak points while there is still time to correct them.

Gates A, B, C

Three gates separate approval from execution. Each gate ties a named approver to a specific artifact so the program gets explicit permission to move forward. Gate A approves the BRD Part A business case. Gate B approves the FD Part B delivery plan. Gate C approves go-live readiness. The gates are not status meetings; they are decisions with entry criteria, exit criteria, approvers, and artifacts.

Gate A — Initiation Gate

Approves: BRD (Part A)

Confirm the problem, value claim, options, and recommendation before delivery planning.

Gate B — Planning Gate

Approves: FD (Part B)

Confirm the delivery plan, measurement readiness, and implementation setup before build begins.

Gate C — Execution Gate

Approves: Go-live approval

Confirm cutover readiness before production launch.

The TAP Log

The TAP Log organizes Touchpoints, Alignments, and Problems around durable problem threads. It keeps meetings, decisions, problems, actions, and follow-up visible as the program moves through the lifecycle. That matters because the formal gate record is only part of governance. Day-to-day program reality lives in touchpoints, alignment decisions, risks, issues, assumptions, dependencies, and actions. TAP keeps that running record connected instead of scattering it across meetings and trackers.

BRD vs FD in SAGE

SAGE uses two complementary documents: a BRD (Business Requirements Document, Part A) approved at Gate A, and an FD (Functional Document, Part B) approved at Gate B. The BRD locks the business case. The FD locks the delivery plan. Separating them keeps business decisions and technical commitments from bleeding into each other.

Operating principles

SAGE has a few operating principles that keep the methodology practical. First, start with the problem, not the solution. Intake and Scope should make the current condition and root causes visible before anyone funds a path. Second, separate business approval from delivery approval. Gate A approves the business case; Gate B approves the delivery plan. Third, make ownership and decision rights explicit before delivery pressure arrives.

Fourth, keep evidence attached to the work. The TAP Log, gate records, BEARINGS artifacts, and measurement plan should let a reviewer reconstruct why a decision was made. Fifth, verify benefits in Embed. A program is not complete because a release shipped. It is complete when the organization can see whether the claimed outcome appeared and what still needs attention.

Those principles make SAGE deliberately conservative about commitments. A program should not commit delivery capacity before it understands the problem. It should not treat a recommendation as approved before options are compared. It should not treat a plan as ready before owners and decision rights are named. It should not treat launch as success before the benefit signal is visible. The methodology is built to keep those distinctions intact.

DE vs OPM

Every program in SAGE has a delivery methodology set to either DE (Digital Enablement) or OPM (Operations Program Management). The setting changes work breakdown language and validation, but the SAGE phases, gates, and artifact sequence stay the same.

SAGE vs PRINCE2 vs PMBOK vs Agile

SAGE is not a replacement for every method a team already uses. It is a program management methodology for framing, approving, governing, and verifying cross-functional work. PRINCE2 can provide a formal project control method. PMBOK can provide a broad reference for project management knowledge. Agile can provide the delivery cadence inside Generate. SAGE's distinctive role is to connect the business problem, BEARINGS artifacts, gates, and TAP Log into one decision path.

When to use SAGE

Use SAGE when the work needs a clear business case, visible stakeholder authority, cross-functional ownership, explicit gate approvals, and evidence of benefit after launch. It is especially useful when a program touches several teams, changes operations, requires leadership approval, or has to defend a recommendation before delivery capacity is committed.

SAGE is less necessary for a small task with one owner, a known solution, and little governance risk. In those cases, a lightweight project plan or product backlog may be enough. The method earns its keep when ambiguity, decision rights, stakeholder tension, and benefit accountability would otherwise be hidden in meetings.

SAGE is also useful when leadership needs a shared language across different program types. A digital enablement program and an operations program may have different delivery details, but both need a problem, causes, stakeholders, goals, options, recommendation, strategy, governance, and measurement. The methodology gives those teams a common spine without forcing every program to use the same delivery mechanics.

How SAGE fits with Agile delivery

SAGE governs the program; Agile can govern delivery inside Generate. The distinction is practical. SAGE asks whether the organization understands the problem, has approved the business case, knows the delivery strategy, has named ownership, and can measure value. Agile helps the delivery team build, test, learn, and adjust within that approved frame.

For example, Gate A can approve the recommended route and value claim. Gate B can approve the delivery plan, backlog readiness, interfaces, test approach, and measurement model. Generate can then use Sprint 0 and delivery sprints to produce increments. Gate C checks cutover readiness before launch, and Embed verifies whether the benefit appears in operation.

Roles in a SAGE program

SAGE does not require a heavy role model, but it does require role clarity. The program lead maintains the artifact sequence, gate readiness, TAP Log hygiene, and cross-functional coordination. The accountable sponsor owns the value claim and major business trade-offs. Business owners validate operations, benefits, and adoption. Delivery leads own delivery planning and execution. Risk, finance, analytics, architecture, and operations contribute evidence where their domains shape the decision.

Those roles become concrete in BEARINGS. Engagement names the people and groups around the program. Governance turns that human map into accountability and decision rights. Signals names measurement owners. Gates make approval authority explicit. The TAP Log then keeps touchpoints, alignments, and problems connected to the people and forums that can act on them.

The program record

SAGE assumes a program needs a durable record, not just a current status view. A status view tells leaders what is happening now. The program record explains why the work exists, which evidence supported the recommendation, who approved each gate, what assumptions were accepted, which problems remain open, and how benefits will be verified. That record is what makes the methodology useful months after a decision is made.

The record is distributed across artifacts rather than trapped in one massive document. BEARINGS holds the core planning evidence. Gate pages hold the approval points. The TAP Log holds touchpoints, alignments, problems, actions, and decisions. Methodology pages give the shared vocabulary. When those pieces are linked, a program manager can answer "why are we doing this?" and "who decided that?" without rebuilding the history from calendars and chats.

This record also improves handoffs. Sponsors change, delivery leads rotate, support teams join late, and benefit reviews often happen after launch energy fades. A clear SAGE record lets each new participant see the problem, value claim, decision path, and measurement model quickly. That continuity is one reason the methodology emphasizes concise artifacts over one-time presentations.

Adopting SAGE without overloading teams

Teams do not need to introduce every SAGE practice at once. A practical adoption path is to start with P0 Intake, B Baseline, Gate A, and the TAP Log. Those pieces immediately improve problem quality, decision clarity, and traceability. The next step is to add the pre-Gate-A BEARINGS artifacts so recommendations are compared and scored before approval. After that, add Navigation, Governance, and Signals to strengthen Gate B readiness.

The goal is consistency, not ceremony. A small program can use concise artifacts. A complex program can use deeper analysis. Both should still answer the same core questions: what problem is worth solving, which causes matter, who is involved, what outcome is claimed, which route is recommended, who owns delivery, who decides, and how benefit will be measured. That shared question set is the heart of the SAGE methodology.

This adoption path also creates quick feedback. If Intake improves request quality, keep it. If Gate A exposes weak recommendations, strengthen Routes and Scorecard. If delivery still stalls, invest in Governance and TAP Log discipline. SAGE can be adopted as a system, but teams learn fastest when each practice is connected to a visible pain point. That keeps rollout focused on better decisions rather than method compliance for its own sake.

Once the core pattern is working, teams can standardize templates, review cadences, and reporting views. The standardization should follow proven practice in the organization, not precede it. That order keeps SAGE pragmatic for small teams and sturdy enough for larger portfolios. It also helps new participants learn the method from real work instead of abstract training. That keeps adoption tied to delivery reality and gives leaders a clear reason to keep using the method across active, visible pilot programs.

Further reading

• BEARINGS overview
• SAGE gates
• Gate A — Initiation Gate
• Gate B — Planning Gate
• Gate C — Execution Gate
• TAP Log
• P0 Intake
• Phase gate process
• Program manager vs project manager
• Deployment options — how SagePM runs and where your data lives
• SAGE glossary