Steer — Templates

Money already spent gets no vote.

About these templates

The Steer stage makes the chosen mix work together by forcing decisions about dependencies, resource contention, sequencing, duplication, and blockers. Four instruments support it: the portfolio dashboard / health view, the dependency map, the decision and escalation log, and the resource-contention view.

—

E1 — Portfolio dashboard and health view

Purpose: The at-a-glance picture of every running investment — its funding status, health signal, and any active flags. The starting point for every Steer meeting.*

Investment	Sponsor	Funding mode	Period budget	Spend to date	Status	Health	Active flags	Last updated
[Name]	[Name]	Rolling / Periodic / Gated / FtL	[£]	[£]	On track / At risk / Off track / Paused	Green / Amber / Red	[Dependency / Contention / Blocker / Review flagged]	[Date]

Health definitions (apply consistently):

1. Green: Investment is progressing as expected; no material change to forward value or cost-to-complete; no unresolved dependencies affecting the critical path.
2. Amber: A material issue exists that the investment owner is actively managing, with a resolution plan; forward value or cost-to-complete has changed by less than [threshold — set per portfolio]; or a dependency is at risk but has a mitigation.
3. Red: A material issue exists that the investment cannot resolve without portfolio-level intervention; forward value or cost-to-complete has changed by more than [threshold]; or a dependency is blocking progress with no current mitigation.

Rules:

1. Status is set by the portfolio office based on the Steer process — not solely on the investment’s self-report.
2. Any investment at Red for two consecutive Steer cycles must be brought to the Review agenda.
3. An investment whose status has been Amber or Green for more than three cycles without any significant change in the underlying picture should be checked for optimism bias.

—

E2 — Dependency map

Purpose: A live record of the dependencies between running investments — what each investment is waiting for, from whom, by when, and what happens if the dependency is late.*

Dependent investment	Waiting for	From (investment / team)	Required by	If late: impact	Status	Owner of resolution
[Investment A]	[Specific output / decision / capability]	[Investment B / external]	[Date]	[N weeks delay / blocks milestone / blocks funding gate]	Resolved / On track / At risk / Blocking	[Name]

Critical-path flag: Mark any dependency whose failure would delay the dependent investment’s delivery milestone or funding gate with a [CRITICAL] flag. Critical dependencies are reviewed first at every Steer meeting.

Rules:

1. All inter-investment dependencies are recorded here. Bilateral dependency management between teams is permitted but must not substitute for portfolio visibility.
2. A dependency at risk must have a named resolution owner and a resolution date. A dependency with no resolution owner is a blocker waiting to be named.
3. Resolved dependencies are archived, not deleted — they provide a record of the portfolio’s dependency history.

—

E3 — Decision and escalation log

Purpose: The accountability record of the Steer process. Every blocker, portfolio-level decision, and escalation is logged here with an owner and a date. Items are commitments, not observations.*

ID	Date raised	Description	Type	Owner	Resolution required by	Status	Outcome / date resolved
[E001]	[Date]	[Brief description of the blocker, decision, or escalation]	Dependency / Contention / Blocker / Duplication / Escalation	[Name — the person accountable for resolution, not the person who raised it]	[Date]	Open / In progress / Resolved / Escalated	[Outcome and date]

Rules:

1. Every item on the log has a named owner — a specific person, not a team or function — who is accountable for the resolution.
2. An item that is Open with no progress after two Steer cycles is escalated automatically. The escalation owner is the portfolio owner (Lean / Managed) or the governing board (Enterprise).
3. The log is reviewed in full at every Steer meeting. Items are not removed until they are resolved and the resolution is confirmed.
4. The log is the primary input to the Review stage’s assessment of Steer’s hard truths. The pattern of items on the log — types, ages, resolution rates — is information about the portfolio’s health that complements the investment’s self-report.

—

E4 — Resource-contention view

Purpose: Shows where the portfolio’s scarce resources are currently allocated, and where competing demands exist. Used at each Steer meeting to make contention visible and to produce resolution decisions.*

Scarce resource	Total available	Allocated to (investment)	Amount allocated	Period	Contested by (investment)	Contest amount	Status	Resolution
[e.g. Solution architects]	[N FTE]	[Investment A]	[N FTE]	[Period]	[Investment B]	[N FTE]	Uncontested / Contested / Resolved	[Investment A gets N FTE; Investment B deferred to Q3]

Rules:

1. Every scarce resource identified at the capacity-check stage (C4) appears here.
2. Contested resources must be resolved at the Steer meeting at which the contest is identified — not carried forward to the next cycle.
3. The resolution is a portfolio-level decision, not a bilateral negotiation. The portfolio makes the call; the teams implement it.
4. A resource that is persistently contested across multiple cycles is a signal that the portfolio is over-committed on that capability. The Review stage should consider whether the funded set should be reduced.