Standard Work, The Way Forward with Power BI

I had a really nice conversation with Kellan Danielson earlier this week. Kellan is right at the nerve center at PowerPivotPro, helping navigate the next, best way to deliver analytics. When we talk, we tend to talk about what's going on in the BI market, what's working for people and what's not. This week we got on the topic of Standard Work.

I've had this Standard Work idea on my mind ever since Tom Phelan pointed me toward Toyota Kata, and unprompted Kellan brought it up. Let me see if I can do the idea any more justice than the above picture does.

Standard Work is an organization's best, current understanding of the way to run a process.

Maybe it's best if I run through a situation that I've experienced many times, to highlight the need and benefits of adopting standard work.

Publishing a Power BI File is Simple Right?

The Scenario. What's the right way to publish (and share) a Power BI file on the Power BI Service? This scenario is in the context of a team of people working on developing and sharing Power BI in a large organization. Here are a few of the things that need to be figured out.

Take a deep breath and try to read all of this in one breath ... (breath) ...

Where are the .pbix files saved (do we use OneDrive or not, SharePoint?), do we do a core/thin approach, do we publish to personal workspace/analytics team workspace/user workspace, how do we name the reports, how do we add sources to our gateway (who's managing the gateway?), should the dataset go on Power BI premium or regular, what are our sharing policies (Are they aligned with IT), is row-level security required, how do we determine the best refresh schedule, how do we monitor refreshes, how do people become aware of and start using the reports (do we have a push or pull plan), do we need to setup alerts, how do we monitor adoption, should we develop an app/content pack, do all the right people have licenses, are the reports mobile optimized (do they need to be?), do all of the visuals that worked on my Desktop work in the Service, should Q&A be turned on (and have I optimized Q&A), etc.

Lots of Questions, Tip of the Iceberg

For everyone who's been following the Power BI and Power Pivot story closely, you might notice there's not single mention of DAX, Data Modeling, or M in all of that. Before any of this publishing has happened we've had to make another 200+ decisions about requirements, platform, data sources, ETL (Power Query/M), modeling, writing calculations (DAX, business logic, syntax), report design, and performance. After publishing we have another 20+ decisions around maintenance, monitoring, and continuous improvement.

Side note: I hope everyone reading this realizes just how valuable an experienced Power BI professional is. A person that has dealt with this process (end to end dozens of times for many clients in diverse industries) has started to form really good instincts around what the standards should be. We'll come back to that.

Back to the scenario. In just this one small area of how to publish and share a Power BI file there are easily 20-30 questions that need to be figured out. Maybe I'm over thinking this, and I'm happy to field that criticism, but based on my observations of organizations struggling to get the full value from these tools, I think not.

Are You Producing Quality, Consistently?

The inertia of this situation in every organization is that everyone on the team does their own thing, with greater or lesser degrees of variation, depending on some random variables - length of time on the job, random conversations with other team members, personal preferences, articles/books read. Here's why this is a problem.

As a Power BI creator, you are producing something for a customer. Your customer could be an internal or external person. That customer has expectations of quality for what you're delivering. And here's my big assumption ... As a team you want to meet those expectations of quality as consistently as possible, with the smallest amount of variation.

To produce quality consistently, you have to think about your process. The more standard work in your process, the less variation in your outcomes.

And here's the takeaway ... you drive continuous improvement around a process by noticing variations in quality, identifying where in the standard work the process is breaking down, and then updating the standard work accordingly. Look at the image at the beginning of this article. It's standard work that translates small improvements into continuous organizational improvements.

Why the Field Trip Matters.

Rob Collie introduced me to the idea of the "Field Trip" - this idea of getting out of the office and seeing what's really going on in the world.  Experienced consultants have gone on this field trip.

Consultant: "I've done this dozens of times for a diverse set of customers. I've made mistakes, and learned how to address those mistakes. My clients have had success, and I've learned what drives success. You can hire me to get you up the curve faster, so you don't have to experience every bump on bruise along the way"

Lots of variation in experiences, and outcomes, sharpens a good consultant's intuition. And when it comes to developing your first round of standard work, it's helpful to work with someone that's been there before - it's like having a spirit guide (peyote and Mojave desert not included).

So here's a tip to people considering hiring a consultant, ask them about the mistakes they've made for previous clients, sit back and listen. Personally, I've got a list of mistakes I've made and I'm proud to discuss them because those mistakes are what make me worth hiring.

If you're staring at the Consulting Chasm and you're thinking about what valuable service you could provide, think about including Standard Work in your sales pitch.

It's Still Early

On two fronts.

First, organizations generally aren't thinking about analytics as a process to standardize with the goal of producing quality, consistently.

The growth of Power BI has been tremendous, on both the supply and demand side. In the past 12 months, many teams have gone from one person and a few internal customers to large teams and enterprise delivery. It's a situation that we're experiencing for the first time with Power BI. There are currently no obvious standards to adopt.

Second, the technical community that is generally responsible for analytical development is somewhat blind to the people, culture, and processes that drive quality and continuous improvement in analytics. It's 90% not a technical problem. It's also not a problem that people become aware of quickly - it takes a lot of observation to start to see the patterns.

What's Next?

I was thrilled in talking to Kellan to hear that PowerPivotPro is working on this problem. If you want to discuss the idea of standard work more, feel free to reach out. If you're interested in doing some work in this area I'm gonna recommend you reach out to Rob, Kellan, and crew at P3.

For a future post: It's my intention to develop a simple Wikipedia style reference for Power BI Standards. Much of this important knowledge is scattered throughout the community - in the mind of consultants, in articles, videos, and books. A little bit of work here could go a long way. Ping me if you have something to contribute.