The Operating Model has five components. Each one answers a specific question about how the program will run, and each one addresses a coordination failure that occurs when the component is missing. This article walks through all five: what they contain, how they are built, and what separates a useful version from a decorative one.
Component 1: Role Definitions
What it contains
For each key role on the program, the definition specifies: the seat (the role’s position in the program structure), the outcomes owned (the results the person in this role is accountable for), and the accountability expectations (how success is measured and what happens when outcomes are not met).
How it is built
Role definitions build on the Architecture Blueprint’s ownership model. The architecture assigned owners to workstreams and defined the governance hierarchy. The Operating Model extends this by specifying what each owner is on the hook for and how they will know if they are succeeding. The consultants work with each role holder to define their outcomes. The test is whether the outcomes are specific enough to create accountability. “Responsible for stakeholder communication” is an activity. “Accountable for stakeholder alignment, measured by issue resolution within five business days and quarterly stakeholder confidence scores above threshold” is an outcome.
What good looks like
Outcome-focused, not activity-focused. Every role can answer two questions: what am I accountable for, and how will I know if I am succeeding? If either question has a vague answer, the role definition is not done. The Role Charters sub-artifact captures these definitions for every key seat on the program. The architecture nobody builds describes the upstream dependency. Without architecture that defines ownership and structure, role definitions are built on organizational convention rather than program need.
Component 2: The Outputs Catalogue
What it contains
A list of the artifacts the program will produce during execution: status reports, risk logs, decision records, milestone assessments, financial summaries. For each output: what it is, who produces it, who consumes it, the cadence (weekly, biweekly, monthly), and the format.
How it is built
The consultants start from the decisions that need to be made during execution and work backward to the information those decisions require. A steering committee that meets monthly to review program health needs a monthly program health report. That report needs inputs from each workstream’s weekly status update. The outputs catalogue connects the decision-making cadence to the information supply chain. The discipline is in restraint. Every output costs time to produce. The consultants apply a ruthless test: if the program stopped producing this artifact, what would break? If the answer is nothing, the artifact is cut.
What good looks like
Minimal and connected. Every output exists because a specific decision-maker needs it to make a specific type of decision. No output exists because “it seems like we should track this.” The total output burden is sustainable: the team that produces the artifacts can do so without it consuming more than a defined percentage of their time. The roadmap that tells you nothing describes the failure mode when outputs are disconnected from decisions: the program produces reports that no one reads, while the information decision-makers actually need is not being captured.
Component 3: Governance Design
What it contains
Decision rights by type: which decisions are made at the workstream level (execution decisions), which require cross-workstream coordination (integration decisions), which need program leadership input (strategic trade-offs), and which need executive committee approval (scope, budget, or timeline changes). For each type: who has authority, what information is required, and what the expected turnaround time is. Escalation pathways specifying when and how a decision moves from one level to the next. Tie-break rules defining who makes the call when consensus cannot be reached.
How it is built
Governance design extends the Architecture Blueprint’s governance model. The architecture defined the hierarchy. The Operating Model specifies the process. The consultants identify the five to seven most common decision types the program will face and design the pathway for each: who initiates, who decides, what information is required, and how long the process should take.
What good looks like
Governance distinguishes between decision types. Day-to-day execution decisions are fast and local. Strategic trade-offs involve the right stakeholders. The team can look at a decision and immediately know which pathway applies. One-size-fits-all governance creates friction by routing simple decisions through complex processes. Programs that failed with good plans documents decision stalls caused by governance that was either too complex (every decision required committee approval) or too vague (no one knew who had authority for cross-functional trade-offs).
Component 4: The Cadence Calendar
What it contains
The program’s meeting rhythm across four time horizons: weekly (operational alignment), biweekly (cross-workstream coordination), monthly (strategic review and course correction), and quarterly (executive assessment and priority setting). For each meeting: purpose (what decisions it enables), owner (who prepares and facilitates), attendees, duration, and connection to the outputs catalogue (what information feeds in and what decisions feed out).
How it is built
The consultants design the cadence top-down: starting with the quarterly executive reviews (which define the strategic questions), then monthly program reviews (which provide the strategic inputs), then biweekly coordination meetings (which reveal the cross-workstream issues), and finally weekly operational meetings (which track execution progress). The connection between levels matters. Weekly meetings should identify issues that biweekly meetings resolve. Biweekly meetings should reveal patterns that monthly meetings address. Monthly meetings should produce the consolidated view that quarterly reviews assess.
What good looks like
Ruthless about purpose. Every meeting can justify its existence by naming the decisions it enables or the information it identifies. No meeting exists because “it seems like we should meet.” The total meeting burden leaves the team enough time to do the actual work. Why programs fail identifies meeting proliferation as a coordination failure. Programs without a designed cadence generate ad hoc meetings until the calendar is full and execution time disappears.
Component 5: The Enablers Pack
What it contains
The templates, tools, norms, and collaboration standards that make execution consistent. Status report templates. Risk log templates. Decision record templates. Meeting agenda templates. The project management tool configuration. Naming conventions. File structure. Communication channel rules (what goes in email, what goes in the collaboration tool, what gets escalated to a meeting).
How it is built
The consultants design the enablers pack to match the outputs catalogue and the cadence calendar. The status report template matches the information the outputs catalogue requires. The meeting agenda template matches the cadence calendar’s purpose definitions. The tools are configured to support the governance design’s decision pathways. The discipline is in adoption. The consultants do not just design the pack; they drive initial adoption by running the first two to three cycles using the templates and tools, coaching the team through the transition from their existing practices.
What good looks like
Adopted, not just documented. People use the templates. People follow the naming conventions. People know which communication channel to use for which type of message. The enablers pack reduces friction: it makes the common tasks faster and the uncommon tasks clearer. The test: observe the team two weeks after the model is launched. If they are using the pack without prompting, it works. If they have reverted to their old practices, the pack needs redesign or the adoption process was insufficient. The Enablement Stack sub-artifact specifies the templates, tools, and standards that comprise this pack. Programs that failed with good plans documents the formality trap: operating model artifacts that were beautifully designed and never used. Adoption is the measure of success, not documentation quality.
How the Five Components Connect
The components are interdependent. Role definitions define who is accountable. The outputs catalogue defines what those accountable people produce. Governance design defines how their decisions are made. The cadence calendar defines when they connect. The enablers pack defines the tools they use. Remove one component and the others weaken. Role definitions without governance leave accountability undefined. Governance without cadence leaves decisions without a forum. Cadence without enablers leaves meetings without structure. Enablers without role definitions leave tools without owners. The question is whether the team designs this coordination system before execution begins: or whether they discover the gaps one component at a time after each coordination failure.
Keep Reading
Ready to close specific gaps in your Operating Model? These articles show you how: