G Governance.

Using Accountability and Decision rights as a project governance framework

Governance is the SAGE BEARINGS letter for ownership and authority. It works as a project governance framework by answering two separate questions: who owns the work, and who decides when pressure creates a choice. Those questions often get collapsed into a single steering committee slide. SAGE separates them because accountability without decision rights creates blocked owners, and decision rights without accountability creates approvals nobody can execute.

The first artifact, Accountability, names ownership for workstreams, reviews, inputs, approvals, and operational handoffs. It can include RACI-style responsibility where that is useful, but the artifact is broader than a RACI grid. It asks whether named people have accepted the work, whether handoffs are owned, and whether operational owners know what they are expected to absorb after launch.

The second artifact, Decision rights, names authority. It defines which person or forum can approve scope changes, resolve policy questions, accept risk, alter benefit targets, approve cutover, or escalate cross-functional conflict. A clear project governance model should make those rights visible before the program enters delivery. If the first time the team asks "who can decide this?" is during a release crisis, governance has arrived too late.

SAGE places Governance after Gate A because the program now has an approved direction and needs an operating model for delivery planning. It also links Governance to the TAP Log, where decisions and alignments are recorded against durable problem threads. That connection is what keeps the governance framework from being a static document.

Project governance also needs to distinguish approval authority from advisory input. A risk partner may be consulted on a control question without owning the business decision. A sponsor may own the value trade-off without owning the technical implementation. A delivery lead may be responsible for execution without authority to change the benefit target. SAGE keeps those distinctions visible because ambiguity tends to appear at the worst time: when a scope change, risk exception, or cutover decision needs a fast answer.

A strong Governance record should be usable by someone who missed the meeting. It should say who owns each major activity, which forum handles each decision type, what service target applies to urgent decisions, and how escalation works when the normal forum cannot resolve a conflict. That is the difference between a governance model and a list of names.

How to establish project governance in SAGE

1. Name the accountable sponsor. Confirm who owns the value claim, who can resolve trade-offs, and who is accountable when benefit or scope pressure appears.
2. Identify decision rights at each gate. Gate A, Gate B, and Gate C require clear approval authority. So do scope changes, risk exceptions, funding questions, policy changes, and benefit-target changes.
3. Draft accountability for major work. Use a RACI where it helps, but do not stop at letters in boxes. Name owners for reviews, inputs, handoffs, and operational readiness.
4. Validate with stakeholders. Review the model with the people named in Engagement. Governance that surprises the people it governs will not survive delivery.
5. Commit to Accountability and Decision rights. Capture owners, forums, service targets, escalation paths, and evidence links in the artifacts before Gate B.
6. Use the TAP Log to enforce the model. Decisions and alignments should reference their authority path. That makes governance searchable and reviewable after the meeting ends.

Worked example — governance for a regulated data migration

Governance quality checks before Gate B

Before the program reaches Gate B, Governance should pass a practical review. Can the team name the accountable sponsor? Are workstream owners named as people rather than departments? Are approval forums clear? Are decision rights connected to the types of decisions the program will actually face? Is the escalation path written down? Does the TAP Log have a way to capture alignments against those forums?

If those answers are missing, delivery may still begin, but every difficult question will create delay. Governance is not meant to slow the program down. It is meant to prevent the same decision from being remade in every meeting. A project governance template is valuable when it helps the team know where authority lives before pressure arrives.

The last check is whether the model survives a realistic scenario. Pick a likely problem: scope pressure from a sponsor, a compliance exception, a release-date conflict, or a benefit target change. The Governance artifacts should show who owns the work, who decides, which forum is used, how quickly the answer is needed, and where the alignment will be recorded. If the scenario exposes confusion, fix the model before Gate B. The review should be concrete, not theoretical.