Program governance is the standing structure that turns a roadmap and a risk register from documents into a decision-making system, and it is best built as an explicit three-tier cadence. The PMO (Program Management Office) or Transformation Office is the connective tissue running continuously (daily to weekly) and its job is administrative, and it is also the single keeper of the roadmap, the cascade, and the risk register in one version-controlled place, so that the steering committee is never handed three different decks with three different numbers for the same program, an entirely avoidable failure that destroys credibility in the room faster than almost any single bad decision would. The Working Group (workstream leads, meeting weekly) makes the operational, tactical calls the program needs day to day: re-sequencing a task within a workstream, resolving a resourcing conflict inside a single team, unblocking a stuck analysis. The Steering Committee (the sponsor and the senior stakeholders whose organizations the transformation touches, meeting monthly or at defined milestones) makes the decisions that only that level has the authority or the perspective to make: approving a scope change, reallocating budget across workstreams, accepting a risk that crosses a materiality threshold, or resolving a genuine disagreement the Working Group could not settle on its own.
Advertisement
How do you stop governance theater?
Which decisions belong at which tier is not a matter of taste; it is exactly the kind of recurring decision-rights question CN7.01's RACI tool exists to answer, applied here to governance rather than to the organization chart it was originally built for, reminder, not re-derivation: Responsible does the work, Accountable is the single named person whose sign-off actually counts, Consulted is asked before a decision is final, Informed only after. A governance cadence without an explicit RACI for its own recurring decisions (who has the "A" on a scope change over a stated size, who merely gets consulted, who is only informed) drifts, in practice, toward whoever is loudest or most senior in the room deciding everything informally, which is exactly the failure this module calls governance theater: a steering committee that meets on schedule, reviews a deck, and changes nothing, because the real decisions were already made in a hallway conversation before the meeting started, or because no one in the room actually has the authority the org chart implies they do. It is the delivery-stage sibling of the "boxes-and-lines trap" CN7.01 names for organization design: a governance structure that exists on paper and does no real work is not a lesser version of good governance, it is a specific, recognizable failure with its own fix, which is to make the RACI for the program's own recurring decisions explicit, published, and actually followed.
{
"skill": "Drafting a first-pass risk register template and a governance RACI for a program's recurring decisions",
"use": "Use AI to generate a starting risk-register template (columns for probability, impact, expected value, RAG, owner, response type, trigger) pre-populated with commonly-seen transformation risk categories for a given program type, and a first-pass RACI table for the program's recurring governance decisions -- both scaffolds a real PMO lead then edits with the program's actual risks and actual people.",
"tools": ["Chat assistants -- Claude, ChatGPT, Gemini", "Spreadsheet tools for the live, maintained register"],
"prompt": "For a <PROGRAM TYPE> transformation in <INDUSTRY>, draft: (1) a risk-register template with columns for probability, impact, expected value, RAG status, response type (mitigation/contingency/acceptance), owner, and escalation trigger, pre-populated with 6-8 commonly-seen risk categories for this kind of program (do not invent our program's real probabilities or impacts -- leave those blank); (2) a RACI table for five recurring governance decisions this kind of program typically needs to make (e.g., scope change above a threshold, budget reallocation, risk acceptance above a threshold), with role placeholders instead of real names.",
"verify": "Every pre-populated risk category is a generic starting hypothesis, not a finding -- your own program's actual risks, probabilities, and impacts must be sourced from your own workstream leads and diligence, never accepted from the tool's default list. Recompute every expected-value number yourself once real inputs replace placeholders, and confirm the RACI's role assignments against who actually holds the authority in your organization, not a generic assumption (Guardrail 1-5).",
"diy": "You must already be able to score a risk's expected value, apply a RAG rule, and choose correctly among mitigation/contingency/acceptance (this section) before you can tell a genuinely useful AI-drafted register from a generic checklist that happens to look thorough. AI proposes categories and structure; you own every number and every owner assignment.",
"market": "US"
}