Welcome back to the conclusion of our two-part series on Agile/Self-Service BI Governance!  In part one, Agile BI Governance is a Human Problem, I explained why a “tech-first” approach to Governance is doomed to fail, and introduced the critical role played by partnership with the Business. This month, I’ll explain WHO those partners are, how to find them, and how to responsibly empower them.

In part one, we touched on the crucial role of humans, as well as the importance of partnership with key individuals within the business. To put this in visual perspective, we often use the following diagram:

In “the Three P’s,” the first and third are the ones everyone generally recognizes: of course, we need to Plan our deployment, and subsequently Police “bad” behavior. It’s the middle “P”, Partnership, that is neglected by default. Helping you avoid that omission, and the inevitable failure it leads to, is the whole purpose of these articles. So, let’s zoom in on Partnering to gain some additional clarity.

In part one, we touched on the role played by Excel: the only tool previously capable of providing the Business with sufficiently-nimble reporting and analysis. I’m now going to explain how to turn that previously-frustrating dynamic into a major win for your organization.

First, we must dispense with the idea that “the Business” uses Excel. When stated that way, we assume that Excel skill is smoothly distributed across individuals in the Business, as illustrated here:

Since there’s traditionally been little reason or ROI for IT to closely engage with the Business’s usage of Excel, we find that default perception (of smooth skill distribution) to be relatively common. It’s an understandable perception, but it’s quite divergent from the on-the-ground reality.

Instead, Excel expertise is very cleanly divided into two camps: a small cadre of highly-capable Producers and a large majority of “read-only” Consumers, with very little middle ground:

This concentration of skill, in a relatively small population, represents a tremendous opportunity for us in a Governance initiative! Indeed, this skill distribution reflects something far more important, which is a sharp division of roles within the Business’s usage of Excel (aka “Black Market BI.”)

While their job titles tell one story, the Producers’ actual day-to-day roles are very much like those of an IT professional. Their tools and terminology differ from their IT equivalents, but they are all-too-familiar with decidedly IT tasks like ETL, Joins, Group By’s, and Master Data Management – tasks they’ve been forced to perform, until recently, with inferior toolsets.

The Producers represent the only successful “attach point” for IT in an Agile BI adoption program, for several reasons:

  • They already understand and sympathize with IT-style concerns such as quality, accuracy, and maintainability
  • They similarly understand how the majority of the Business – the Consumers – do NOT sufficiently understand or appreciate the work required to deliver good results
  • They already grasp many of the difficult technical concepts required in order to deliver quality BI – they just understand them using different terminology than IT uses
  • Their jobs - and even their overall quality of LIFE – can be improved dramatically via better tools, AND via closer cooperation with IT
  • The combination of all of these make them both capable and motivated partners for IT, both of which are crucial prerequisites

Once we understand the Producers as crucially important and valuable, we immediately face two more questions:  1) how do we identify them? And 2) what do we do with them once we’ve found them?

Finding them is not terribly difficult. Ultimately, VLOOKUP and PivotTables are the “genetic markers” for identifying Producers. If you find someone who can confidently write VLOOKUP formulas (or their more advanced cousin, INDEX/MATCH) and create PivotTables from scratch, you have found a Producer. We’ve seen success, therefore, with non-anonymous internal surveys asking precisely those questions, with the caveat that care must be taken to phrase the questions in a manner that doesn’t invite inflated self-report of skill. And in cases where a survey methodology is impractical, you can work backwards by identifying the important spreadsheets consumed by managers within a specific business unit, identifying which of those spreadsheets utilize one or both of the “markers” (VLOOKUP and Pivot), and then tracking them back to their authors.

Once found, your two most obvious goals are to transition the Producers from using Excel to using Power BI Desktop as their production tool, and using the Power BI Service (or Power BI Report Server) as the distribution mechanism (as opposed to email and file shares):

 

In order to make that transition, the Producers will of course need training. First on Power BI Desktop, which primarily means DAX, M, and data modeling – concepts we’ve repeatedly proven they are capable of learning during our eight years of working in this space. But, they also require training on the Service (or PBI Report Server) – in terms of publishing, scheduled refresh and gateways, and security, primarily. And if that sounds daunting – remember, not only do they already face parallels of these concepts and problems, but their existing tools are so poor in these roles that they are also highly motivated to adopt a better way. All we have to do is show them that better way. They are ready – and hungry – for it.

A successful, well-governed rollout of Power BI is often the focus of a multi-month engagement between us and a client, so unsurprisingly, not all of the detail can fit into a short series of web articles like this. For space considerations, I’ll leave you with the following six additional points of advice on how to get the most out of your partnership with the Producers:

  1. Don’t be afraid to deploy Power BI one department at a time!  Identifying and developing partners takes time to do it right, so don’t rush it.
  2. It’s important to train the Producers from their perspective. You obviously need trainers who understand DAX, M, and modeling, but they also need to understand how Producers work today in Excel. You can’t just dump tech knowledge on them; you have to show them how Power BI offers a superior parallel to the things they’ve been doing, and then transition them from the old to the new.
  3. "Co-development” is even better than training. Training is great, and we certainly deliver a lot of it for our clients, but if you have the opportunity to go one step further, and work side-by-side with the Producers to develop a production-level data model and reports, teaching them as you build, the learnings will be more relevant and durable than what they’d get from training. When feasible, we steer our clients in the direction of co-development, which dovetails nicely with the “one department at a time” approach.
  4. The Producers are the first line of defense. All requests for new reports and analysis, within a given department, should be routed to the Producer first. This is actually what’s happening today already in most cases, so this is merely formalizing a well-known Business routine. (But when a report experiences an outage or other problem, the Producers should also be the first tier of support.)
  5. You need recurring standing meetings with the Producers. You don’t want them to hear from you only when something goes wrong. You need to know what they’re working on, what they’re struggling with, and what would help them. So, a recurring, “stand-up” style meeting is critically important. Sometimes they won’t even know to ask for help, even when it’s something that is easy for IT to provide; and you’ll spot future problems before they arrive.
  6. If it’s not published, you can’t see it. Monitoring is a crucial component of the Third “P” (Policing) and Power BI Desktop offers no monitoring mechanisms, only the Service (or Server) does. For that reason, we do NOT want Power BI desktop to take root as a sharing mechanism. By default, Producers will gravitate toward precisely that: sharing PBIX files via traditional means of email and/or file shares, with Consumers viewing them in PBI Desktop. You want to head off this habit before it takes root, and fortunately there are multiple “pressure points” we can leverage in this cause: by restricting access to PBI Desktop, by emphasizing the benefits of auto-refresh, and/or by emphasizing the benefits of Mobile consumption. Make these a focus of your earliest rollout strategies and training.