Artifact Standards 26–36

Opened at project kickoff. Updated continuously through delivery. Reviewed at every governance touchpoint. The RAID log is the primary evidence the governance forum uses to assess whether health is deteriorating before it reaches crisis.

Risks

Assumptions

Issues

Dependencies

I need to prepare a Decision Escalation document to bring a governance concern to the executive level for resolution. Below are the relevant RAID log entries, project status, and a description of the decision that is needed.

Please build the escalation with:
- Escalation header: project name, date submitted, submitted by, escalation type (Risk / Issue / Dependency / Value Concern), and urgency (Decision needed within: X days)
- The Situation: what has happened and when — factual, no editorializing
- Why It Cannot Be Resolved at the Delivery Level: what authority is needed, and why the delivery team alone cannot make this decision
- Options on the Table: 2–4 specific options with what each one requires, what it costs, what risk it accepts, and who it impacts
- Recommended Option: the delivery team’s or EPMO’s recommendation with explicit rationale
- Decision Required: one clear sentence stating exactly what the governance forum or executive needs to decide
- Decision Deadline: by what date a decision is needed, and what happens if the deadline passes without a decision

Keep it to one page. This document is not a project status update. It is a decision request. Every sentence should serve the decision, not the narrative.

[Paste RAID log excerpt, project status, and decision description here]

Produced when a risk, issue, dependency, or value concern cannot be resolved at the delivery level and requires governance or executive intervention. This is a decision request, not a status update.

The Situation — What has happened and when? Factual. No editorializing.

Why It Cannot Be Resolved at the Delivery Level — What authority is needed? Why cannot the delivery team make this decision alone?

Options on the Table

Recommended Option — What does the delivery team or EPMO recommend, and why?

Decision Required — One sentence. Exactly what does the governance forum or executive need to decide?

Decision Deadline — By what date is a decision needed? What happens if no decision is made by then?

Cross-project view of dependencies across the active portfolio. Updated each governance cycle. Purpose: identify shared dependencies before they become conflicts, surface broken dependencies before they become issues, and give the governance forum a visual of which projects are load-bearing for others.

Portfolio Dependency Summary

High-Risk Dependencies This Cycle

Portfolio-level snapshot of resource demand versus available capacity. Updated each governance cycle. Required input to the authorization decision (T25). The governance forum cannot make sound authorization decisions without this view.

Resource Utilization by Team / Role

Shared Resources (allocated to more than one project)

I need to produce a Portfolio Tradeoff Summary following a portfolio governance session. Below are my session notes, the current portfolio state, and the decisions made.

Please build the summary with:
- Session header: governance cycle, session date, participants, active projects reviewed, total portfolio budget committed, and portfolio utilization %
- Decisions Made This Cycle: a table with decision type (Authorize / Defer / Reprioritize / Stop / Override), the item name, outcome, rationale, and who approved it
- Portfolio Tradeoffs Accepted: explicit statements of what the portfolio is NOT doing as a result of these decisions — what was deferred or declined and why; this is the organizational cost of each authorization
- Capacity Impact: whether the portfolio is now at risk, at capacity, or has available headroom after this session’s decisions
- Open Items Requiring Resolution: anything escalated to the next session, with owner and deadline
- Cycle Summary: 2–3 sentences on what this cycle revealed about the portfolio’s health, capacity, or strategic alignment

This is the governance forum’s portfolio record — not a project status digest. Every section should serve the question: "What did we decide and what did we give up to get there?" Work only from my materials — do not invent details; label any inference or estimate as such, and list anything missing as a gap.

[Paste session notes, portfolio state, and decisions here]

Produced after each portfolio governance session. Documents what was decided, what was traded away, and the portfolio-level consequence of those decisions. One document per cycle.

Decisions Made This Cycle

Portfolio Tradeoffs Accepted — What is the portfolio explicitly NOT doing as a result of these decisions? What was deferred or declined, and why?

Capacity Impact — After this session, is the portfolio at risk, at capacity, or does it have available headroom?

Open Items Requiring Resolution

Cycle Summary — 2–3 sentences. What did this cycle reveal about the portfolio’s health, capacity, or strategic alignment?

Built during delivery before go-live. Defines how adoption will be measured from day one through outcome confirmation. Maintained alongside the benefit owner register. Updated as adoption data becomes available.

Leading Indicators (adoption signals — visible early)

Lagging Indicators (outcome confirmation — visible at or after confirmation date)

I need to produce a Post-Investment Review at the benefits confirmation date for a completed project. Below are the benefits register, adoption measurement data, and outcome owner confirmation notes.

Please build the review with:
- Investment summary: project name, investment close date, review date, authorized budget, actual spend, reviewer(s), and outcome owner
- Outcome confirmed (yes/no/partially): what was committed and what was confirmed, in direct comparison
- Benefits Realization table: for each projected benefit from the register, show the projected value, confirmed value, variance, and confirmation method
- What Worked: 2–4 specific observations about what the delivery or adoption approach did well — concrete, not general
- What Didn’t Work: 2–4 specific observations about what failed, fell short, or was wrong about the original assumptions — factual, no blame
- Lessons for the Next Investment: 2–4 direct recommendations for how this type of project should be handled differently — actionable, not advisory
- EPMO Process Gaps Surfaced: what the governance process failed to catch or create visibility for — if none, say so explicitly
- Decision on the Benefits Register: Closed as confirmed / Closed with partial confirmation / Held open for [reason]

Keep observations direct and specific. A review that says "communication could have been better" is worthless. Name what was communicated, to whom, and what the actual failure was.

[Paste benefits register, adoption measurement data, and outcome owner confirmation notes here]

Completed at the benefits confirmation date. Closes the investment record. Feeds back into the scoring model calibration and framework improvement backlog. Not a project close-out report — a governance learning record.

Outcome Confirmed — What was committed? What was confirmed? Direct comparison.

Benefits Realization

What Worked

What Didn’t Work

Lessons for the Next Investment — Actionable recommendations, not advisory observations.

EPMO Process Gaps Surfaced — What did the governance process fail to catch or create visibility for? If none, say so explicitly.

Run annually or at the end of each major cycle. Assesses whether governance behaviors are consistent and evidenced — not whether the framework exists on paper. A maturity assessment is only credible if it is calibrated against real artifacts and real behaviors, not self-report.

Intake & Clarification (Steps 1–4)

Investment Decision (Steps 5–8)

In-Delivery Governance (Steps 9–10)

Benefits & Standardization (Steps 11–12)

Overall Assessment

Living document. Updated at the close of each governance cycle and after every post-investment review. The backlog closes the loop: what the governance process learns from every investment should feed back into the standards, the scoring model, and the onboarding approach. If post-investment reviews are not generating backlog items, the reviews are not being done honestly.

Backlog Grooming Record

Change saturation is a portfolio risk, not a project risk. It starts at intake and does not end at go-live. This register makes that risk visible at the governance level, where decisions can actually be made about sequencing, deferral, and organizational bandwidth.

Portfolio Saturation Summary (by team / function)

Change Load by Project (cross-reference)

Authorization Record

Assumptions Accepted at Authorization

Assumption vs. Actual — completed at Step 11 Benefits Review