Part 4. The Process and framework pillar
This is part 4 of my Power BI Governance series. You can read previous parts here:
Process and framework pillar
The second of the five pillars of Power BI Governance is the Process and frameworks pillar. The order of the pillars is not important, so all the pillars are equally important.
Processes and frameworks are the backbone of a good governance strategy. They are used to guide administrators and users how to use Power BI in a compliant manner and using best practices.
In my opinion, when it comes to governance, a framework is just a collection of processes. Therefore, I will only talk about processes in this blog.
It´s important to say at this point that we are just talking about documents to help people use Power BI correctly. If you prefer to call them something else than processes, there is no reason not to. Many of my customers prefer to call these documents best practices documents, while others don´t mind the name process. The important thing to remember is that you make it clear to the users which parts of the documents are required, and which are optional best practices. In my experience people tend to take processes more seriously than best practices but also dread them more. You need to find the best way in your organization to keep people interested and make sure they take the documents seriously.
There are many different processes you could create in an organization. It all depends on your governance strategy and how much you want to split up topics. For instance you might create a development process that covers everything from Power BI Desktop development to publish and share or you might have one development process and another process for publish etc.
When I work with customers on Power BI governance, I will suggest that we cover at a minimum:
- Power BI Development guide
- Power BI publish / deployment guide
- Power BI sharing guide
- Power BI Administration guide
- Power BI Tenant settings documentation
There are others that could be done separately such as a security process or a naming standard but that depends on the customer and the users (their skill, tolerance to documentation and usage scenarios)
Normally I will create the documents with my customer by first running workshops to better understand what they want and need. Normally, I will do one for each document or audience depending on how the customer wants to proceed. The important thing here is to listen to the stakeholders.
For the admin docs, you need to talk to current Admins on how they are administrating the system and balance that on best practices and the governance strategy (what do we allow of settings, separation of duties etc.). I will often use the tenant setting documentation to make sure everyone understands each setting and set it appropriately. In my opinion it´s very important to understand them well and challenge each decision to turn off settings that might make life easier to the user. Preferably you will write in the tenant settings documentation why the setting is sat in the documented manner.
For the development docs you will need to talk to representation of developers, both IT and business to understand how they are developing and want to develop and balance that against the governance strategy. You might end up with one process for IT and another for business users. For example, you might decide that it shouldn’t be a problem requiring IT to use source control, but it might be too much for business users. They might be comfortable with OneDrive version control instead.
For the publish and sharing docs the audience for the workshop depends on how it works in your organization. Do you have a deployment process in place or does everyone publish from Power BI Desktop? Do you allow users access to all workspace, or do you have separation of duties on some (production) workspaces? Does the same person do both publish and share? How you proceed with the publish and sharing docs will always depend on your environment.
If you figure out that the governance requirements would fundamentally change how the users work with Power BI or turn off settings that are crucial to the way, they work you have a huge communication task ahead of you and need strong management backing.
This concluded part 4, Process and framework pillar. Part 5 will cover pillar 3 Training and support