Data Governance Operating Model Implementation Guide
Role matrices, forum structures, decision thresholds, escalation mechanics, change control processes, KPI governance templates, and a phased capability roadmap. Everything you need to build a function
This is the paid companion to the Data Governance Operating Model Blueprint. The Blueprint gives you the architecture, five layers, three cross-cutting disciplines, one structural principle. This guide gives you the tools to build it.
The Blueprint explained why most governance operating models fail: they define roles but never define decision rights. This guide fixes that with specific, fill-in-the-blank implementation machinery.
Here is what is inside
Section 1: Role Matrices by Layer
Three complete role matrices covering Layers 1, 2, and 3 of the operating model. Every role has four columns: the role title, who fills it (one named person), what they are responsible for, and critically what decisions they are authorized to make.
Layer 2 is the most important. The matrix distinguishes between Domain Owners (who decide), Data Stewards (who enforce), and Technical Custodians (who implement). Most organizations confuse these three. If your stewards are approving changes, you have a decision authority gap. The matrix makes the boundaries explicit.
Each matrix includes instructions for filling in actual names, circulating for acknowledgment, and reviewing every 90 days.
Section 2: Forum Structure Templates
Three complete forum templates — one per tier.
The Data Council template defines purpose, cadence, membership, quorum rules, decision scope, escalation triggers, unresolved item handling, and output requirements. It specifies that no item persists across two consecutive sessions without resolution or escalation.
The Domain Review template distinguishes between high-volatility domains (bi-weekly) and stable domains (monthly). It defines what a Domain Owner can resolve in the review versus what must escalate.
The Working Group template includes a 90-day maximum lifespan. If work is not complete in 90 days, the group must be re-chartered or the scope reduced. No indefinite working groups.
Every template answers three questions: what decisions can this forum make, what must it escalate, and what happens to unresolved items.
Section 3: Decision Threshold Framework
A ten-row matrix that defines exactly which decisions a Domain Owner can make alone, which require a Domain Review, and which must go to the Data Council.
This covers schema changes (add, remove, rename), access grants (read and write), metric definition changes, source system swaps, retention policy changes, new domain creation, ownership transfers, and AI model input changes.
The default rule: if a decision type is not listed, it requires Domain Review. No decisions happen outside the framework.
Section 4: Escalation Mechanics
Two tables.
The first defines eight specific escalation paths: trigger, source, destination, time limit, and what happens if the escalation itself is not resolved. This covers owner indecision, forum deadlocks, cross-domain disputes, policy violations, stale domains, critical incidents, and AI model drift.
The second defines five automatic time-based escalation rules. These do not require someone to notice a problem. The system enforces them based on elapsed time: stale decisions (10 days), forum carryover (2 sessions), inactive owners (90 days), unacknowledged violations (24 hours), and expired review cycles.
Automatic escalation is the single most important operational mechanism in this guide. It solves the most common failure mode — escalation exists on paper but no one uses it.
Section 5: Change Control Process and Request Form
A seven-step change control process from request submission through verification and close. Each step defines the action, the detail, the responsible party, and the time expectation.
The change request form has fourteen fields covering the full lifecycle: identification, classification, justification, impact assessment, decision routing, decision rationale, implementation, and verification. Fields 1–9 are filled by the requester. Fields 10–14 are completed by governance roles during processing.
Critical requests bypass triage. Changes made outside the process are policy violations that trigger automatic escalation.
Section 6: KPI Governance Template
An eleven-field template that brings KPIs into the same decision authority structure as every other governed domain. Fields cover the KPI name, business definition, technical definition (exact calculation logic), source system, owner, accountable executive, consumers, change control path, review cycle, last review date, and known issues.
The template includes instructions for starting with the ten KPIs that appear in executive reporting, which are the highest risk.
Section 7: Governance KPI Dashboard
Ten metrics that measure whether governance is working. Not activity metrics — effectiveness metrics. Domain coverage, owner activity rate, mean decision time, escalation resolution time, forum decision rate, stale domain count, change control compliance, KPI definition currency, AI input coverage, and ungoverned decisions.
Each metric has a defined target, measurement method, and reporting frequency. The dashboard is designed to be published monthly to the Data Council and quarterly to the Executive Sponsor.
Section 8: Capability Roadmap
A four-phase roadmap from foundation to sustained operation. Each phase has a timeline, specific deliverables, and measurable success criteria that must be met before advancing.
Phase 1 (Foundation, 30–45 days): sponsor confirmed, top 5 domains governed, first Data Council held. Phase 2 (Operationalize, 60–90 days): domain reviews running, change control live, KPI governance for top 10 KPIs. Phase 3 (Scale, 6 months): 25 domains, steward network, AI inputs mapped, tooling implemented. Phase 4 (Sustain, 12 months): full coverage, effectiveness metrics published, annual review cycle.
How to Use This Guide
The guide ends with a week-by-week implementation sequence for organizations starting from zero:
Weeks 1–2: Role matrices for Layers 1 and 2. Name the sponsor. Name the owners.
Weeks 2–3: Decision thresholds and escalation mechanics.
Weeks 3–4: Forum structures. Schedule the first Data Council.
Weeks 4–5: Change control. Process the first request through the formal path.
Weeks 5–6: KPI governance for top 10 executive KPIs.
Weeks 6–8: Launch the dashboard. Start measuring.
Month 3+: Begin Phase 2 of the capability roadmap.
Download the Implementation Guide
The full guide is attached below as a formatted document. It is designed to be used, not read. Print the sections relevant to your current phase. Fill in the templates with real names, real thresholds, and real dates.
Download: Operating Model Implementation Guide (tools and templates)
This is the work I do inside organizations during governance execution sprints. The guide gives you everything you need to do it yourself. If you want help implementing it in your specific environment navigating the politics, filling the matrices with the right names, and standing up the forums with the right people in the room — that is what the sprint is for.
Governance is about decision authority, not documentation. If your operating model defines roles but not rights, it will produce activity but not outcomes. The fix is structural, not cultural.
Solid operating model.
The real test comes at the binding event — when authority must be enforced at execution time.