How Microsoft Established Its Power BI COE - Lessons for Australian Organisations

Most Australian organisations I talk to don't have a Power BI problem. They have a "we have 1,400 reports and nobody knows which ones are right" problem. Somebody in finance built a margin report in 2021. Someone in sales built a different margin report in 2022. Both are still being emailed around, and the numbers don't match.

The usual answer to this is a Center of Excellence, or COE. It's a phrase that makes some people roll their eyes, and fair enough, because I've seen plenty of COEs that were really just a SharePoint page and a monthly meeting nobody attended. But Microsoft has published a useful account of how they set up their own internal Power BI COE, and it's worth reading because it's honest about the fact that they had the same mess everyone else has. You can find it in the Power BI guidance docs under How Microsoft established a COE.

I want to walk through the main ideas from that article and add what we've seen on the ground with clients here.

Microsoft started with sprawl, just like you

The part of Microsoft's story I find most reassuring is that their starting point was ordinary. Business units across the company had adopted Power BI on their own. Teams built their own datasets, their own reports, their own definitions of revenue and customer and pipeline. There was a lot of good work happening, and a lot of duplicated effort, and a lot of reports that disagreed with each other.

That's the pattern almost everywhere. Power BI is easy to start with, which is the whole point of it. The cost of that ease is that you end up with dozens of slightly different versions of the truth.

What Microsoft didn't do was shut it all down and centralise everything into one IT-owned reporting team. That approach fails, and I've watched it fail at a few large Australian organisations. The central team becomes a bottleneck, the backlog grows to six months, and the business goes back to Excel or spins up shadow workspaces. You've made the problem worse and now it's hidden.

The model they landed on

Microsoft describes a model where the COE owns the shared, trusted foundation and the business units own their own reporting on top of it. Roughly:

• A central team defines and maintains certified semantic models for core business data, things like finance, sales and product usage.
• Business units build their own reports against those certified models, with freedom to create content that suits their needs.
• The COE sets standards, runs training and support, and looks after the tenant settings and governance.

People call this "managed self-service" and it's the model I'd recommend for nearly every client above a couple of hundred staff. The central team doesn't try to build every report. It builds the parts that need to be consistent, like how revenue is calculated, and then gets out of the way.

The thing that makes it work is certification. Microsoft leaned hard on endorsement, meaning promoted and certified content, so that when someone in a business unit goes looking for data, the official version is easy to find and clearly marked. If your certified model is hard to find or hard to use, people will build their own. Simple as that.

Executive sponsorship was not optional

One point Microsoft makes that I'd push even harder: they had executive backing. The COE had a mandate.

In our experience this is the single biggest predictor of whether a COE survives past its first year. When a COE is a side project for a BI manager with no authority, it produces some nice documentation and then quietly dies when that person moves on. When it has a sponsor at CFO or COO level who will say "the board pack comes from the certified finance model, full stop", things change fast.

I worked with a mid-sized Queensland organisation (I won't name them) where the data team had tried to set up a COE twice. Both times it fizzled. The third time, the CFO made one decision: from the next quarter, any number presented at the executive meeting had to come from a certified dataset. Within about eight weeks the business units were asking the data team to help them get their reports onto certified models. Same people, same tools. The only difference was that someone senior made it matter.

Community matters more than you'd think

Microsoft put a lot of effort into building an internal community of practice. Champions in business units, an internal forum, regular sessions where people showed what they'd built, office hours with the COE.

I'll be honest, when I first saw this kind of thing in COE guidance years ago I thought it was a bit soft. Fluffy stuff. I've changed my mind. The community is how standards actually spread. Nobody reads the 40-page governance document. People do copy the report their colleague showed off at the last community session, and if that report follows the standards, you've won.

What we've seen work:

• A small number of named champions. One or two per business unit, people who already enjoy Power BI and are already the person others ask. Give them early access to new features and a direct line to the COE.
• Short, regular show-and-tell sessions. Thirty minutes, monthly, recorded. Real reports from real teams.
• A Teams channel that someone from the COE actually monitors. If questions sit unanswered for a week, people stop asking.

What doesn't work is a champions program where the champions have no time allocated and no recognition. They burn out or drift away.

Start small, grow based on demand

Microsoft didn't launch with every subject area certified. They started with the high-value, high-use data and expanded. That sounds obvious, but I regularly see COE plans that try to model the entire organisation's data before releasing anything. Eighteen months later there's still nothing in production.

My advice to clients is to pick one subject area where the pain is obvious and the audience is senior. Finance is usually the right first pick because inconsistent numbers there cause real embarrassment. Build one certified model properly, get one or two critical reports running on it, and use that as the proof point. Then move to the next area.

What's still rough

A few honest observations about where this model gets hard.

Microsoft has resources most organisations don't. Their COE had dedicated staff. A 300-person Australian business might have one and a half data people. You can still run a COE at that size, but it looks very different: more about standards and a couple of certified models, less about formal programs and community events. Don't try to copy Microsoft's org chart.

Tenant settings are a constant moving target. Power BI and now Fabric add new admin settings regularly. Someone has to watch the release notes and decide what to enable. This is boring work and it often falls through the cracks. If you're on Fabric, the COE scope gets bigger, because now you're governing lakehouses, notebooks and pipelines as well as reports. We've written separately about structuring a Fabric COE.

Measuring success is hard. Microsoft talks about tracking adoption, and you should, using the activity log and the admin monitoring workspace. But "number of reports" is a terrible metric. More reports is often worse. I'd rather track things like the percentage of executive-facing reports built on certified models, or the number of duplicate semantic models retired.

Retiring old content is politically painful. Every report has an owner who thinks it's important. You need a clear process for flagging unused content, notifying owners and archiving it. Without this, sprawl creeps back in.

A practical starting checklist

If you're thinking about setting up a Power BI COE, here's roughly the order I'd go in:

1. Get an executive sponsor who will make at least one binding decision about certified data.
2. Audit what you have. Pull the tenant inventory, find the most used semantic models, and find the duplicates.
3. Pick one subject area and build a certified semantic model for it.
4. Write a short standards document. Two or three pages. Naming, workspace structure, who can certify, how to request access.
5. Name your first few champions.
6. Turn on endorsement and make certified content easy to find.
7. Set up a monthly review of usage and a retirement process for stale content.

That's it for the first quarter. Resist the urge to build the full operating model before you've delivered anything.

Where we fit in

We help Australian organisations set up this kind of operating model, usually starting with an audit of the existing tenant and a first certified model. If you want to talk it through, our Power BI consultants do this work regularly, and if your reporting is moving onto Fabric, our Microsoft Fabric consultants can help plan the broader platform governance. We're also seeing more clients layer AI on top of a clean semantic model, which only works if the model is trustworthy in the first place. That's covered on our AI for business intelligence page.

The main lesson from Microsoft's story is that a COE isn't really a team or a document. It's a set of habits: certify the important data, make it easy to find, support the people building on it, and clean up after yourself. Get those right and the tooling mostly takes care of itself.