Step 08

Authorize and Transition

In Brief — Approval and readiness are not the same thing. This step confirms — before work begins — that seven conditions are in place: an engaged sponsor, a named outcome owner, accessible funding, clear delivery ownership, mapped dependencies, confirmed capacity, and a first decision date. Approved work that starts without these seven confirmed is work that starts on a foundation that has not been checked.

What’s Actually Happening

The project was approved three weeks ago. Nobody has started.

The sponsor is waiting for a kickoff meeting that nobody has scheduled. The delivery team found out about the approval by accident. The resources that were nominally “available” for this work are currently committed to two other projects at capacity. The first decision the new project needs to make is waiting on a conversation that has not been identified as a conversation yet.

This is not exceptional. It is routine in organizations where approval and authorization are treated as the same moment rather than two distinct steps. The governance forum said proceed. The organization interpreted “proceed” as “figure out how to start.” Those are different instructions and they produce different outcomes.

Why This Step Exists

Because approval grants permission. Readiness determines timing.

A project can be correctly prioritized, thoroughly evaluated, and appropriately approved — and still fail in its first thirty days because the conditions for responsible launch were never confirmed. The resources assumed available were already committed. The dependency that needed to resolve first did not resolve on schedule. The first decision needed a meeting with three people who had not been told the project existed.

These failures do not happen at the tollgate. They happen in the gap between the tollgate decision and the first day of real work — a gap that most governance models do not manage because they treat it as someone else’s problem. Nobody is accountable for the gap. The governance forum approved the work and considers it transitioned. The delivery team is waiting for direction. The sponsor is not sure what they own.

What Good Looks Like

Before work formally begins, seven things are confirmed. Not assumed — confirmed:

Sponsor

The executive sponsor is named, has been briefed on what they approved, and understands what sponsorship requires of them during delivery. Not the person whose name was on the intake form months ago — the active, engaged sponsor for this specific project at this specific moment.

Outcome Owner

The person in the operating business who is accountable for confirming the intended outcome materialized. Often a different person than the sponsor. They need to be named and need to know they are named.

Funding

The budget is confirmed and accessible. Not in a planning document — actually available in the right cost center with the right approvals. Approved projects that stall because funding was approved in principle but not allocated is a more common problem than it should be.

Delivery Ownership

The person or team responsible for execution is identified, available, and confirmed. Not tentatively planned — actually available. If named resources are currently committed elsewhere, that conflict is surfaced here, not discovered mid-project.

Dependencies

Every dependency required before work can begin is mapped. What needs to be true, or in place, or completed before this project can make its first real decision? Those dependencies need owners and dates.

Capacity

The impact of this approval on the rest of the portfolio is assessed. Adding a new project to a delivery environment already at capacity does not add a project — it distributes the same capacity across more work.

First Decision Date

When does the new project team need to make its first consequential decision? Who needs to be in the room? Is that meeting scheduled? If it requires three senior leaders and a thirty-day notice period, that clock starts the moment authorization is granted.

How to Do It

The authorization step is a structured handoff. It connects the governance decision to the delivery environment. The EPMO owns it, the delivery team inherits it, and the sponsor confirms it.

Create an authorization checklist completed for every approved project before the project is formally started. Every item has a named owner and a confirmed date. Items that cannot be confirmed push the start date, not the governance decision.

Conduct a brief authorization meeting with the sponsor, the delivery lead, and the outcome owner. The purpose is not to present the approved proposal — everyone has read it. The purpose is to align on what each party owns in the next thirty days, what the first decision points are, and what the escalation path is when something blocks progress. This meeting takes thirty to sixty minutes. It prevents weeks of confusion.

What Breaks When You Skip It

Projects start before they are ready, which means they stumble through the early weeks consuming time and goodwill while they figure out the basics that authorization would have confirmed.

Sponsors who are not briefed make decisions based on their understanding of the intake proposal from months ago. Delivery teams who receive no formal briefing make assumptions about scope, timeline, and authority that conflict with what the governance forum actually approved. The cumulative effect is a project that arrives at its first real milestone carrying assumptions that were never aligned, made by parties who were never in the same room to confirm them.

The Gotchas

Authorization becomes a second tollgate. The authorization step is not a re-examination of the approval decision. That decision was made. Authorization is about confirming the conditions for responsible execution.

Approved equals started. The delivery team begins work the day they hear about the approval. When authorization is formally completed weeks later, the project is already in motion with unconfirmed assumptions and no formal handoff. The sequence matters: authorization before execution.

The sponsor does not show up. When sponsors are not available for the authorization meeting, distinguish between a sponsor who is engaged but overcommitted (recoverable) and a project that has no functional sponsor at all (not recoverable through better scheduling). Authorization should not proceed until a functional sponsor is named.

Dependencies are listed but not owned. A dependency without an owner is a risk with no one managing it. Every dependency in the authorization process needs a person accountable for resolving it and a date by which resolution is expected.

Where the Disciplines Show Up

→ Decision Discipline: Authorization is a decision: this project is ready to start. That decision should be made explicitly, with the checklist complete, not assumed because the tollgate approved it. Who has the authority to grant authorization, and what happens if the checklist cannot be completed?

→ Change & Absorption: Authorization is the last checkpoint before the change lands in the organization. Confirm that the change management plan has a named owner, that stakeholders know the change is coming, and that the receiving organization’s readiness has been assessed — not assumed.

→ Enterprise Fit: Confirm that architecture, integration, and security reviews are complete — not “in progress.” If these were conditions of the tollgate approval, authorization is where compliance with those conditions is confirmed before the green light is given.

→ Evidence: The authorization step creates the project’s operating baseline — the reference point for every subsequent decision. Document scope, budget, timeline, sponsor, outcome owner, and success criteria as they exist at the moment of authorization. Everything that follows is measured against this baseline.

→ Political: Authorization is the moment when political commitment becomes visible. Design the authorization step so that the sponsor’s commitment is witnessed and documented — not extracted in a one-on-one conversation that can later be walked back. Sponsors who understand what they are committing to, in front of the people who will hold them to it, are significantly more likely to remain active through delivery.

The Key
Approval grants permission. Readiness determines timing. The governance forum’s job is to approve the right work. The authorization step’s job is to confirm that the approved work can actually begin. These are not the same job and they do not happen at the same moment.

You know this step is working when projects that start, start clean — sponsor briefed, team assembled, funding accessible, dependencies mapped, first decision on the calendar. No first-week scramble.

The Artifacts

T3 — Authorization Checklist

A structured list of the seven items that must be confirmed before a project is authorized to begin. Each has a named owner, a confirmation method, and a required date. Signed off by the EPMO, delivery lead, and sponsor.

T24 — Sponsor Briefing Template

Brings the active sponsor up to date: what was approved, what the outcome commitment is, what sponsorship requires during delivery, what the first thirty days look like. Brief enough to read in ten minutes. Specific enough to create alignment.

T25 — Capacity Impact Summary

A snapshot of the portfolio capacity view before and after this authorization. Shows the effect of this approval on the delivery environment: which teams are affected, current utilization, and whether any capacity conflicts are created.