The Operating Agreement Nobody Wrote Down (And Why Your Hybrid Model Isn’t Working)

The Headache

Tuesday afternoon. A business analyst at a manufacturing company finishes a report her CFO has been asking for. She built it on the certified Sales semantic model, which is exactly what the governance deck says she’s supposed to do. She publishes the report, shares the link, takes the afternoon off feeling accomplished.

Monday morning, 9:00 AM. The report is broken. Two measures have vanished. The CFO is on her calendar at 10:00.

The central BI team, meanwhile, has had a quiet weekend. They tightened up the Sales model on Friday afternoon, renaming a handful of measures to align with a new corporate naming convention. They tested everything in the workspace, the certified reports still worked, they committed the changes and went home.

By 9:30 the analyst is in the BI team’s channel, in caps. By 9:45 the BI team is firing back, in caps, that she shouldn’t be building production reports on a model she doesn’t understand. By 10:15 the CFO is asking why she’s looking at a broken dashboard, and the answer her analyst has to give involves the phrase “the BI team changed something.” Which is true, but unhelpful, and definitely not the answer the CFO wanted to hear before her board prep.

Both of them are right. Both of them are wrong. The actual problem is that nobody wrote down who owes whom what notice when a certified model changes. Most organizations try to solve this by hiring more diplomatic people. We’ve found that hiring more diplomatic people does not, in fact, fix it.

This is Issue Two of a three-part series on the Power BI operating model. Issue One asked you to be honest about which model you’re actually running. This issue is about writing down the agreement that makes hybrid actually work.

The Blueprint: The Four Documents Nobody Has

Hybrid governance fails for one reason: the operating agreement between the central team and the business is unwritten, inconsistent, or fictional. We’ve sat across the table from enough CIOs, BI leads, and frustrated finance directors to know that almost every “governance problem” we get hired to solve is actually four missing documents.

Here is what those four documents are, and how we typically build them in our engagements.

1. The Certification Contract.

What does the central team commit to when it certifies a semantic model? In our engagements we draft this as a one-page document with explicit commitments on both sides. The central team commits to specific refresh SLAs (typically two hours for daily models, longer for weekly), documented business logic for every measure, a defined change notification window, and a named owner. The consumers of the model commit to not modifying the certified version, not building competing models for the same business entity, and reporting issues through a single defined channel rather than DMing the BI lead at 9 PM on a Sunday. Certification is a two-way contract. Most organizations write down only what the central team owes, then wonder why consumers act like there are no rules.

2. The Change Management Protocol.

This is where the manufacturing-company scenario above actually gets solved. The protocol needs to answer four questions in writing. Who gets notified when a certified model changes? (Every report owner with a downstream dependency, identified through lineage view.) How much lead time? (Our default is two weeks for breaking changes, 48 hours for non-breaking, though we adjust by client.) What counts as a breaking change? (Renamed or removed measures, changed data types, modified relationships, altered row-level security: all breaking. New measures, new descriptions, documentation updates: non-breaking.) And what is the rollback story if a change goes wrong? Most organizations cannot answer any of these. Writing them down is half the value of the document.

3. The Ownership Matrix.

A one-page table. Rows are the layers of the stack: source systems, lakehouse or warehouse, certified semantic model, certified report, business-built report, personal report. Columns are: who owns it, who can change it, who reviews changes, who fields the support call when it breaks. The pattern we apply is that ownership shifts as you move up the stack, with the central team owning everything through the certified model and the business owning everything above it. The 9 AM Monday support-call column is the one that ends ten years of arguments, because when the answer is in writing, “whoever picks up first” stops being the de facto policy.

4. The Escalation Path.

When the operating agreement breaks down, who decides? Not “the BI Steering Committee.” Committees are where decisions go to die, and we’ve stopped recommending them for this purpose entirely. Functional hybrid needs a single accountable executive sponsor with the authority to overrule both the central team and the business when the agreement is being violated by either side. Name the person, write down the role, document the escalation path. If the sponsor changes, the document changes. If the document doesn’t change, the sponsor’s successor will pretend the agreement doesn’t apply to them.

The Gotcha

Most organizations try to write the operating agreement during a crisis, usually right after a board-meeting incident like the one in the Headache. That’s the worst possible time. Resentment is high, finger-pointing is the dominant communication mode, and the agreement that emerges will be either punitive or vague. We write these documents during peacetime. When clients don’t have peacetime, we manufacture it by running a structured half-day workshop with the right people in the room and a facilitator who has no skin in the existing fights. That’s usually us. The workshop output is the four documents, drafted in the room, signed by the executive sponsor before anyone leaves.

The Reddit Reality Check

A recent thread, paraphrased: an IT director asks how to handle business users who “go around IT” and build their own datasets despite the existence of a certified central model. Several replies recommend tighter restrictions, more granular permissions, a workspace lockdown.

The reality is that the most common cause of shadow data work is not malice or incompetence. It is an unclear operating agreement combined with a central team that says no by default. Functional hybrid says yes by default, with conditions. The conditions are the operating agreement. When the conditions are written down and reasonable, shadow IT shrinks dramatically because the path of least resistance is now compliance rather than evasion. When the conditions are unwritten or unreasonable, locking the platform down harder just pushes the shadow work into Excel, where you can’t see it at all.

What We’re Watching

Fabric’s Git integration and deployment pipelines have matured significantly over the past year and are now the technical scaffolding that makes the change management protocol enforceable rather than aspirational. Connecting workspaces to Azure DevOps or GitHub gives you commit history, branching, and code review for semantic models, and deployment pipelines let you promote tested changes from dev to test to production without manually rebuilding. The new deployment pipeline UI is in preview as of this spring, with notable improvements in how cross-workspace dependencies are handled, though cross-workspace scenarios still have limitations worth understanding before you commit to a pattern. Worth a look if you’re still doing semantic model changes directly in production. (Yes, people still do this. Yes, including at organizations with eight-figure BI budgets.)

One question for the comments: What’s the unwritten rule on your data team that everyone follows until somebody breaks it and gets blamed?

The Strategist’s Corner

If you read the four documents above and recognized that your organization has zero of them, you’re in the majority. We typically deliver these as part of an Operating Model Workshop: a structured half-day session with your central BI team, two or three business stakeholders, and the executive sponsor, ending with the four documents drafted and signed before anyone leaves the room. The follow-on engagement implements the change management protocol in your Fabric tenant, but the workshop alone usually pays for itself within the first averted board-meeting incident. Book a 30-minute scoping call →

Issue Three closes the series with the third piece: the workspace and domain architecture that makes the operating agreement enforce itself, so the documents don’t just sit in a SharePoint folder. Subscribe to see that one when it comes out!

Measure Twice. #2: Originally Posted on LinkedIn, June 17, 2026