Data Culture and Digital Transformation

One of the key success factors for organizations to thrive today is adopting modern self-service business intelligence tools and transforming their businesses to become more agile, more automated, and more data driven. For years technology vendors and industry analysts have thrown around the term “digital transformation” to broadly describe this phenomenon, and technology has matured to catch up with the hype.

Cheesy graphic of zeroes and ones - Image by Gerd Altmann from Pixabay

I use the term “hype” here deliberately. In my experience the term “digital transformation” has been thrown around in the same way as the terms “cloud” and “big data” were thrown around, just a few years later. The cynical part of my brain initially categorized it as “marketing bullshit,” but the intervening years have shown me that this wasn’t actually the case. Digital transformation is real, and it’s a key driver for a successful data culture with real executive support.

Over the past few years I’ve had hundreds of conversations with executives, decision-makers, and business and technical leaders from hundreds of enterprise Power BI customer organizations. These are real people working to solve real problems, and they come from a broad range of industries, geographies, and levels of maturity. I learned a lot from these conversations, and have done my best to help Power BI improve based on what I learned[1], but when I step back and look at the bigger picture there’s a significant trend that emerges.

Stakeholders from organizations that adopt Power BI[2] as part of a digital transformation describe more mature data cultures, and a greater return on their investments in data and analytics.

As you can probably imagine, once I saw this correlation[3], I kept seeing it again and again. And I started looking more closely at digital transformation as part of my ongoing work around data culture. Two of the most interesting resources I’ve found are articles from the Harvard Business Review, which may not be the first place you think to look when you’re thinking about Power BI and data culture topics… but these two articles provide important food for thought.

The first article is almost six years old – it’s from 2015, and focuses on The Company Cultures That Help (or Hinder) Digital Transformation. In the article, author Jane McConnell describes five of the most difficult obstacles that prevent organizations from adopting the changes required by a digital transformation:

(Please feel strongly encouraged to click through and read the whole article – it’s well worth your time, and goes into topics I won’t attempt to summarize here.)

I suspect these challenges sound as depressingly familiar to you as they do to me. These obstacles weren’t new in 2015, and they’re not new now – but they’re also not going away.

Jane McConnell goes on to identify what characteristics are shared by organizations that have overcome these obstacles and are succeeding with their digital transformations. The alignment between her conclusions and this blog’s guidance for Building a data culture with Power BI is striking[4]:

  • A strong, shared sense of purpose alleviates many obstacles, especially those of internal politics. When an organization has a clearly defined strategy, it is easier for everyone to align their work towards those strategic goals, and to justify that work in the face of opposition.
  • Freedom to experiment helps people prioritize, make decisions, and rethink how they work. Having a culture where data governance takes the form of guardrails and effective guidance, not roadblocks, is key to driving meaningful positive change.
  • Distributed decision-making gives people at the edges of organizations a voice in digital transformation. Although there is a need for centralized decision-making and control for some aspects of a data culture (data sources, applications, policies, etc.) the real power of managed self-service BI comes from letting IT do what IT does best, and letting business experts make informed business decisions without undue governance.
  • Organizations that are responsive to the influence of the external world are more likely to understand the value digital can bring. My customer engagements don’t provide any insight to share on this specific point, but I suspect this is significant too. Organizations that are not responsive to external factors are unlikely to make it onto my calendar for those strategic conversations.

In her conclusion, Jane McConnell suggests that readers who see these obstacles in their way should “find ways to transform your work culture using digital as a lever.” In the context of the Harvard Business Review’s target audience, this advice makes a lot of sense.[5] If you are a senior business leader, shaping the work culture is something you are empowered and expected to do. If you’re not, this is where having an engaged and committed executive sponsor will come in handy. If you don’t already have that sponsor, framing your conversations using the vocabulary of digital transformation may help in ways that talking about data culture might not.

The second HBR article I found valuable and fascinating in the context of digital transformation and data culture is written by Randy Bean and Thomas H. Davenport and titled Companies Are Failing in Their Efforts to Become Data-Driven. This one is more recent, and focused more closely on the data side of things.

(As with the article discussed above, please feel encouraged to click through and read this one too. Both articles are written by professionals with significant experience, and an informed strategic perspective.)

This article starts off with a excellent statement of fact:

Whether their larger goal is to achieve digital transformation, “compete on analytics,” or become “AI-first,” embracing and successfully managing data in all its forms is an essential prerequisite.

It then goes on to inventory some of the ways that organizations are failing to deliver on this essential prerequisite, including “72% of survey participants report that they have yet to forge a data culture.”[6]

I’ll let you read the source article for more numbers and details, but there is one more quote I want to share:

93% of respondents identify people and process issues as the obstacle.

If you’ve attended any of my “Building a data culture with Power BI” presentations, you’ll know that I break it down into two main sections: the easy part, and the hard part. Spoiler alert: The easy part is technology. The hard part is people.

The article by Bean and Davenport includes a lot of insights and ideas, but not a lot of hope. They’ve talked to senior data leaders who are trying various approaches to build data cultures within their enterprise organizations, but they all see a long march ahead, with hard work and few quick wins. Technology is a vital part of the transformation, but people and culture is necessary as well.

Building a successful data culture requires top-down and bottom-up change. If you’re in a position of authority where you can directly influence your organization’s culture, it’s time to roll up your sleeves and get to work. If you’re not, it’s time to start thinking about the changes your can make yourself – but it’s also time to start thinking about how using the vocabulary of digital transformation might help you reach the senior leaders whose support you need.


[1] This is your periodic reminder that although I am a member of the Power BI Customer Advisory Team at Microsoft, and although I regularly blog about topics related to Power BI, this is my personal blog and everything I write is my personal perspective and does not necessarily represent the views of my employer or anyone other than me.

[2] I assume that this holds true for other modern BI tools, but since I’m only talking to Power BI customers I can’t really say. And since Power BI continues to increase its lead over the competition…

[3] Not causation.

[4] The bolded text in this list is taken from the HBR article; the rest of the text is from me.

[5] Even if the use of “digital” is sooooo 2015.

[6] Now I wish that I had found this article before I started my data culture series, because I definitely would have used “forge” instead of “build” as the verb everywhere.

The Blind Men and the Data Elephant

Are you familiar with the parable of the blind men and the elephant?

elephant-skin-245071_640
Would you have known this was an elephant, just from this picture?

Sometimes it seems to me that the world of business intelligence – and self-service business intelligence in particular – is made up of blind men feeling their way around a elephant made up of technology and people, each of them feeling something different but none of them able to effectively communicate to the others what they are experiencing.

This blog post was inspired by this email, sent by a technical job recruiter:

Data leader recruiter email
What does this email tell you about the role and the company?

More specifically this blog post was inspired by a tweet[1] from Power BI consultant Jeff Weir, in which he shared this recruiter’s email:

2020-01-18-14-16-43-964--msedge

In this conversation Jeff and I each took the role of a blind man, with this data analytics manager position playing the elephant. Jeff and I each reached very different conclusions.

Jeff may have[2] concluded that Power BI as a tool wasn’t ready for the job, or that that this company wasn’t fully committed to doing what it takes to build a successful data culture, including the right training for their Power BI creators and consumers.

I reached a different conclusion, and I the more I read and re-read the recruiter’s email the more I believed that my initial conclusion is correct: this is an organization that is stepping back from solutions to ensure that they’re focused on the right problems. This is an organization that already has tactics, but is willing to admit that those tactics aren’t getting them where they need to go without the right strategy. This is an organization that seems ready to make significant, substantive change.

Why did I reach this conclusion?

The first sentence: “Ultimately Power BI while being a tool they are currently using it is not the only tool they will consider.”[3]

Wow. As an organization they are avoiding the sunk cost fallacy and explicitly stating they’re open to change, even though that change is likely to be disruptive and expensive. Switching BI tools is hard, and it is not a change that is taken lightly. The leaders at this organization are willing to take that hit and make that change, and they’re taking the steps to find the right leader to help them make it… if that leader decides the change is necessary.

The second sentence, with my emphasis added: “Here they are really looking for someone with some strong technical ability, but more so strong leadership and strategy skills.[3]

Wow!  The recruiter is explicitly calling out the organization’s priorities: they need a strategic leader. They need someone to help them define the strategy, and to lead them in its execution. Yes, they need someone with the technical chops to help carry out

The third sentence: “there will be an element of helping there and mentoring the staff members currently in the team.”

Maybe not exactly wow on this one, but it’s clear that the organization knows that they need to build the skills of their current BI team, and they want someone able to help. Something missing here that I would prefer to see[4] is additional information about the size and skill levels of the team today, and what other learning resources the organization makes available.

The third sentence, again: “it is more about getting a grip on the current landscape of the data and what can be done with it, setting a vision and a strategy aligned with product development and then going from there…”

WOW! This sounds like an organization that knows their current path isn’t leading them to success. It sounds like an organization that acknowledges its challenges and is proactively looking for a strategic solution to root causes, not just a band-aid.

But… it also sounds like an organization that needs a Chief Data Officer, not just an Insights and Data Analytics Manager, and based on Jeff’s Twitter comment it sounds like they’re not willing to pay a competitive rate for the less senior position, much less the more senior one. They seem to want parts of a data culture, but don’t  appear willing to invest in what it will actually take to make it a reality

I was originally planning to structure this post around the theme of 1 Corinthians 13:11, but the more I thought about it the more I realized that describing a technical solutions focus as being “childish ways” that you then grow out of really didn’t match up with what I was trying to say.[5] Although to be fair, this post has traveled far afield from what I intended when I started writing, and I’m honestly not certain I ended up making a particularly strong point despite all the words.

Maybe if I’d had more time I could have just said “different people see different things in shared situations because of differences in context, experience, and priorities, and it’s important to take multiple perspectives into consideration when making important decisions.” Maybe not. Brevity has never been my forte.


[1] Please feel encouraged to read the whole thread, as it went in a few different directions that this post doesn’t touch on directly. I also did explicitly ask Jeff’s permission to reference the conversation and image in a blog post… although I doubt either one of us expect it to arrive quite as late as it did.

[2] I qualify my summary of Jeff’s conclusion because I’m only working with the information available to me in the Twitter conversation, and I do not know that this is a complete or accurate summary. I suspect it is at least accurate, but only Jeff can say for sure.

[3] Please pause for a moment to reflect on how difficult it was to type in that sentence without editing it for clarity and grammar.

[4] Yes, I understand that this is an excerpt from one email that shows only the most narrow slice into what is likely a complex environment, and that it is not realistic to expect every aspect of that complexity to be included in three sentences – no matter how long that final sentence might be.

[5] Thanks to everyone who shared their thoughts on Twitter about the wisdom of using a Bible verse in a technical blog post.

Power BI, PowerPoint, and the importance of shared goals

Do you ever get the feeling that you you’re participating in a completely different conversation than the person you’re talking to?

Maybe you are.

Image by Arek Socha from Pixabay
An actual photograph of Matthew’s brain most of the time.

Back in December[1], Power BI MVP Lars Schreiber shared this tweet:

I’ll bet that was a difficult conversation.

Although I wasn’t in the room with Lars and his client, I’ve been in similar rooms having similar conversations on many occasions where it gradually became obvious that my understanding of the meeting’s goals were not shared by the other participants.

Without a shared understanding of goals and priorities, collaboration quickly breaks down.

Without a shared understanding of goals and priorities, activity are falsely equated with progress – for how can you make progress without a chosen destination?[3]

Without a shared understanding of goals and priorities at the beginning, much of what is done will need to be undone and/or redone once the disconnect is identified and rectified. Often it’s not just a matter of going back to the start – it’s worse. The parties that argued against the project[4] the first time will be empowered and emboldened by any delays and false starts, and the greater the impact of the misunderstanding, the more difficult it will be to get things back on track.

In my experience the best thing to do in situations like this is to immediately step back, stop focusing on implementing a solution to a problem, and focus instead on clearly defining the problem that needs to be solved. Once you know not everyone is working on the same thing, ask the questions no one thought to ask before, or which were asked without the right people involved.

The best case scenario is that everyone can quickly get aligned on common goals and priorities – the disconnect was a bump, not a crash.

Even in the worst case scenario, it’s better to ask the hard questions and to avoid pressure to “just keep working” before your strategic goals are reestablished and validated. The sunk cost fallacy will work against you, but it’s important to remember that it is a fallacy.

If you’re six months into a year-long project, it’s hard to admit that you might need to throw away two or three months worth of work, and end up coming in over schedule and over budget. That’s hard, but it’s better than delivering something no one needs at the end of the year having consumed the entire schedule and the entire budget with nothing useful to show for it.

Going back to that tweet, I have every reason to assume that Lars and his client were successful. Even though Power BI and PowerPoint are very different tools, there are many use cases where either one could be applied to great effect… and at the risk of Abraham Maslow rolling over in his grave, if the only tool you have is PowerPoint, every problem starts to look like a presentation.

I suspect that Lars used this shocking statement as an opportunity to start a new conversation, and to explore the problems his client was using PowerPoint to solve. The next time you find yourself in a similar situation… maybe you will too.


[1] Which is also when I started this post. Life has been busy forever.[2]

[2] I added the previous footnote over a year before I added this one. Life has indeed been busy forever.

[3] This makes me think of one my favorite Sun Tzu quotes.

[4] Or other type of effort, but in my experience it’s usually a project.

Free Power BI Intro Training From Microsoft

As anyone who is familiar with my series on building a data culture knows, training is an absolutely vital success factor for a community of practice. This isn’t limited to developers, administrators, and content creators – you need to empower every user for your data culture to truly thrive.

Although Microsoft has long offered a variety of training resources such as the “in a day” courses[1], until now these offerings were focused on more technical personas and topics, not on the business users who are consuming reports and dashboards.

Guess what this blog post is about.

That’s right! Starting this month any Power BI user can sign up for free online introductory training delivered by Microsoft instructors.

These are synchronous online classes with expert instructors who guide Power BI consumers through some of the most common and most important parts of the Power BI experience. Classes are scheduled for multiple days and multiple times of the day[2], and I expect more to be scheduled on an ongoing basis. Click the link above for the current schedule.

But it gets even better!

If you’re working for an organization with lots of Power BI users[3], Microsoft offers “closed classes” on your schedule, for your users. I don’t have a link to share for this one, but your Microsoft account team wants to help get you started. Talk to your customer success account manager (CSAM) or another member of your account team, and ask about the Microsoft Store Events training for Power BI.

Why wait? Sign up for a course or talk to your account team today!


[1] Take a look here for a list of courses including Dashboard in a Day, Administrator in a Day, Developer in a Day, and other training courses that sadly do not include the phrase “in a day” in their names.

[2] There’s even one course being delivered as I type this post!

[3] We’ve been making this training available for enterprise customers for the past few months, and have already reached tens of thousands of learners while receiving great feedback along the way.

Never underestimate the voice of the customer

Most of what I do in my day job involves listening.

A sculpture of men with ears pressed to a brick wall - Image by Couleur from Pixabay
It’s better to put your ear up to the wall than it is to bang your head against it.

Specifically, I spend a lot of time listening to people who use Power BI[1] talk about why they use it, how they use it, and where they struggle along the way. I ask a few questions to get them started, and then I ask a few follow-up questions to help them along as they tell their story – but mainly I listen.

I listen, and then I use what I hear to help make Power BI a better tool for these people and their organizations’ needs.

I listen for patterns and trends, and for a signal to emerge from the noise of hundreds of conversations. When it does, I make sure that the right decision-makers and leaders hear it and understand it, so they can take it into account as they decide where to invest and how to prioritize those investments.[2]

I listen with an informed ear. I spent almost 15 years building software and data solutions, so I understand a lot of the technical and organizational challenges these people face. I spent the next decade or so building data products and services as a program manager at Microsoft, so I understand a lot of the challenges involved in prioritizing and building product features. And perhaps most importantly, I am genuinely interested in listening to and learning from the people with whom I talk. I truly want to hear their stories.

Of course there’s only one of me, and I can’t spend my whole workday listening to people tell their stories… so I’ve helped build a team to listen[3], and it’s making a difference. The next time you see an announcement about new capabilities in Power BI that will improve the lives of large enterprise customers, odds are this team had a hand in making those capabilities a reality.

Why am I telling you all this? This is my personal blog, and I’m not looking for a job, so who cares, right?

You care.

You care because this type of listening is a thing that you can do to make better software. You can do this whether you’re building commercial software or if you’re part of a BI team that needs to build solutions for larger user populations.[4]

You care because letting the people who use your software – or the people you want to use your software – talk about what what’s important to them… will let you know what’s important to them. And if you’re really listening, you can use what you learn to make better decisions and deliver better products and features.

If you’re genuinely interested in the people who use the software you build, you should consider giving this approach a try.


[1] These people tend to be the business and IT owners of Power BI in large enterprise organizations, but they can be just about anyone involved in implementing, adopting, using, or supporting Power BI.

[2] If you’re interested in learning more about the Power BI product team’s planning process, I cannot recommend highly enough this 2019 presentation from Will Thompson.

[3] As part of building that team we all read and/or re-read Lean Customer Development by Cindy Alvarez. If you have not yet read this awesome book, there’s no time like the present.

[4] I honestly don’t know if this type of rigor is appropriate at a smaller scale, because I haven’t done it and haven’t personally seen it done. I suspect that it would be very valuable, but also suspect that there may be lighter-weight options that would provide a better return on investment.

Data Governance and Self-Service Business Intelligence

When you hear someone say that governance and self-service BI don’t go together, or some variation on the tired old “Power BI doesn’t do data governance” trope, you should immediately be skeptical.

During a recent Guy in a Cube live stream there was a great discussion about self-service BI and data governance, and about how in most larger organizations Power BI is used for self-service and non-self-service BI workloads. The discussion starts around the 27:46 mark in the recording if you’re interested.

As is often the case, this discussion sparked my writing muse and I decided to follow up with a brief Twitter thread to share a few thoughts that didn’t fit into the stream chat. That brief thread turned out to be much larger and quite different than what I expected… big enough to warrant its own blog post. This post.

Please consider this well-known quote: “No plan survives contact with the enemy.”

Please also feel encouraged to read this fascinating history of the quote and its attributions on the Quote Investigator web site.

In his 1871 essay Helmuth von Moltke called out an obvious truth: battle is inherently unpredictable, and once enemy contact is made a successful commander must respond to actual conditions on the ground –  not follow a plan that is more outdated with every passing minute.

At the same time, that commander must have and must adhere to strategic goals for the engagement. Without these goals, how could they react and respond and plan as the reality of the conflict changes constantly and unpredictably?

Implementing managed self-service business intelligence – self-service BI hand-in-hand with data governance – exhibits many of the same characteristics.

Consider a battlefield, where one force has overwhelming superiority: More soldiers, more artillery, more tanks, and a commanding position of the terrain. The commander of that force knows that any enemy who faces him on this field will fail. The enemy knows this too.

And because the enemy knows this, they will not enter the field to face that superior force. They will fade away, withdraw from direct conflict, and strike unexpectedly, seeking out weaknesses and vulnerabilities. This is the nature of asymmetric warfare.

The commander of the more powerful force probably knows this too, and will act accordingly. The smart commander will present opportunities that their enemies will perceive as easily exploitable weaknesses, to draw them in and thus to bring that overwhelming force to bear.

And this brings us naturally back to the topic of data governance, self-service business intelligence, and dead Prussian field marshals.

Seriously.

In many large organizations, the goal of the data governance group is to ensure that data is never used improperly, and to mitigate (often proactively and aggressively mitigate) the risk of improper use.

In many large organizations, the data governance group has an overwhelming battlefield advantage. They make the rules. They define the processes. They grant or deny access to the data. No one gets in without their say-so, and woe unto any business user who enters that field of battle, and tries to get access to data that is under the protection of this superior force.

Of course, the business users know this. They’re outgunned and outmanned, and they know the dire fate that awaits them if they try to run the gauntlet that the data governance team has established. Everyone they know who has ever tried has failed.

So they go around it. They rely on the tried and true asymmetric tactics of self-service BI. The CSV export. The snapshot. The Excel files and SharePoint lists with manually-entered data.

Rather than facing the data governance group and their overwhelming advantages, they build a shadow BI solution.

These veteran business users choose not to join a battle they’re doomed to lose.

They instead seek and find the weak spots. They achieve their goals despite all of the advantages and resources that the data governance group has at their disposal.

Every time. Business users always find a way.

This is where a savvy data governance leader can learn from the battlefield. Just as a military commander can draw in their opponents and then bring their superior forces to bear, the data governance group can present an attractive and irresistible target to draw in business users seeking data.

This is the path to managed self-service business intelligence… and where the whole military analogy starts to break down. Even though data governance and self-service BI have different priorities and goals, these groups should not and must not be enemies. They need to be partners for either to succeed.

Managed self-service BI succeeds when it is easier for business users to get access to the data they need by working within the processes and systems established by the data governance group, rather than circumventing them.[1]

Managed self-service BI succeeds when the data governance group enables processes and systems to give business users the access they need to the data they need, while still maintaining the oversight and control required for effective governance.

Managed self-service BI succeeds when the data governance group stops saying “no” by default, and instead says “yes, and” by default.

  • Yes you can get access to this data, and these are the prerequisites you must meet.
  • Yes you can get access to this data, and these are the allowed scenarios for proper use.
  • Yes you can get access to this data, and these are the resources to make it easy for you to succeed.

What business user would choose to build their own shadow BI solution that requires manual processes and maintenance just to have an incomplete and outdated copy when they could instead have access to the real data they need – the complete, trusted, authoritative, current data they need – just by following a few simple rules?[2]

Managed self-service BI succeeds when the data governance group provides business users with the access they need to the data they need to do their jobs, while retaining the oversight and control the data governance group needs to keep their jobs.

This is a difficult balancing act, but there are well-known patterns to help organizations of any size succeed.

At this point you may be asking yourself what this has to do with plans not surviving contact with the enemy. Everything. It has everything to do with this pithy quote.

The successful data governance group will have a plan, and that plan will be informed by well-understood strategic goals. The plan is the plan, but the plan is made to change as the battle ebbs and flows. The strategy does not change moment to moment or day to day.

So as more business users engage, and as the initial governance plan shows its gaps and inadequacies, the data governance group changes the plan, keeping it aligned with the strategy and informed by the reality of the business.

This is a difficult balancing act, but it is being successfully performed by scores of enterprise organizations around the world using Power BI. Each organization finds the approach and the balance that best achieves their goals.

Although this post has used a martial metaphor to help engage the reader, this is not the best mental model to take away. Data governance and self-service business intelligence are not at war, even though they are often in a state of conflict or friction.

The right mental model is of a lasting peace, with shared goals and ongoing tradeoffs and compromises as each side gives and takes, and contributes to those shared goals.

This is what a successful data culture looks like: a lasting peace.

Multiple people replied to the original Twitter thread citing various challenges to succeeding with managed self-service business intelligence, balancing SSBI with effective data governance. Each of those challenges highlights the importance of the effective partnership between parties, and the alignment of business and IT priorities into shared strategic goals and principals that allow everyone to succeed together.

If you want to explore these concepts further and go beyond the highlights in this post, please feel encouraged to check out the full “Building a Data Culture with Power BI” series of posts and videos. Acknowledging the fact that data governance and self-service BI go beautifully together is just the beginning.


[1] This is really important

[2] Yes, yes, we all know that guy. Sometimes the data governance team needs the old stick for people who don’t find the new carrot attractive enough.. but those people tend to be in the minority if you use the right carrot.

 

Problems, not solutions

Imagine walking into a restaurant.

No, not that one. Imagine walking a nicer restaurant than the one you thought of at first. A lot nicer.

restaurant-2697945_640
Even nicer than this.

Imagine walking into a 3-star Michelin-rated best-in-the-world restaurant, the kind of place where you plan international travel around reservations, the kind of place where the chef’s name is whispered in a kind of hushed awe by other chefs around the world.

Now imagine being seated and then insisting that the chef cook a specific dish in a specific way, because that’s what you’re used to eating, because you know what you like and what you want.

knife-1088529_640
I’ll just leave this here for no particular reason.

In this situation, one of three things is likely to happen:

  1. The chef will give you what you ask for, and your dining experience will be diminished because your request was granted.
  2. The chef will ask you to leave.
  3. The chef will instruct someone else to ask you to leave.[1]

Let’s step back from the culinary context of this imaginary scenario, and put it into the context of software development and BI.

Imagine a user emailing a developer or software team[2] and insisting that they need a feature developed that works in some specific way. “Just make it do this!” or maybe “It should be exactly like <legacy software feature> but <implemented in new software>!!”

I can’t really imagine the restaurant scene playing out – who would spend all that money on a meal just to get what they could get anywhere? But I don’t need to imagine the software scene playing out, because I’ve seen it day after day, month after month for decades, despite the fact that even trivial software customization can be more expensive than a world-class meal. I’ve also been on both sides of the conversation – and I probably will be again.

When you have a problem, you are the expert on the problem. You know it inside and out, because it’s your problem. You’ve probably tried to solve it – maybe you’ve tried multiple solutions before you asked for help. And while you were trying those ineffective solution approaches, you probably thought of what a “great” solution might look like.

So when you ask for help, you ask for the solution you thought of.

This is bad. Really bad.

“Give me this solution” or “give me this feature” is the worst thing to ask for. Because while you may be the expert on your problem, you’re not an expert on the solution. If you were, you wouldn’t be asking for help in the first place.

And to make matters worse, most of the people on the receiving end aren’t the IT equivalents of 3-star Michelin-rated chefs. They’re line cooks, and they give you what you asked for because they don’t know any better. And because the customer is always right, right?

Yeah, nah.

As a software professional, it’s your job to solve your customers’ problems, and to do so within constraints your customers probably know nothing about, and within an often-complex context your customers do not understand[3]. If you simply deliver what the customer asks for, you’ve missed the point, and missed an opportunity to truly solve the fundamental problem that needs to be solved.

If you’re a BI professional, every project and every feature request brings with it an opportunity. It’s the opportunity to ask questions.

Why do you need this?

When will you use it?

What are you doing today without the thing you’re asking for?

When will this be useful?

Who else will use it?[4]

As a software or BI professional, you’re the expert on the solution, just as your customer is the expert on the problem. You know where logic can be implemented, and the pros and cons of each option. You know where the right data will come from, and how it will need to be transformed. You know what’s a quick fix and what will require a lot of work – and might introduce undesirable side-effects or regressions in other parts of the solution.

With this expertise, you’re in the perfect position to ask the right questions to help you understand the problem that needs to be solved. You’re in the perfect position to take the answers to your questions and to turn them into what your customer really needs… which is often very different from what they’re asking for.

You don’t need to ask these questions every time. You may not even need to ask questions of your customers most of the time[5]. But if you’re asking these questions of yourself each time you’re beginning new work – and asking questions of your customers as necessary – the solutions you deliver will be better for it.

And when you find yourself on the requesting side (for example, when you find yourself typing into ideas.powerbi.com) you’re in the perfect position to provide information about the problem you need solved – not just the solution you think you need. Why not give it a try?

This is a complex topic. I started writing this post almost 100 years ago, way back in February 2020[6]. I have a lot more that I want to say, but instead of waiting another hundred years I’ll wrap up now and save more thoughts for another post or two.

If you’ve made it this far and you’re interested in more actual best practices, please read Lean Customer Development by Cindy Alvarez. This book is very accessible, and although it is targeted more at startups and commercial software teams it contains guidance and practices that can be invaluable for anyone who needs to deliver solutions to someone else’s problems.


 

[1] This seems like the most likely outcome to me.

[2] This could be a commercial software team or “the report guy” in your IT department. Imagine what works for you.

[3] If you’re interested in a fun and accessible look at how the Power BI team decides what features to build, check out this 2019 presentation from Power BI PM Will Thompson. It’s only indirectly related to this post, but it’s a candid look at some of the “often-complex context” in which Power BI is developed.

[4] Please don’t focus too much on these specific questions. They might be a good starting point, but they’re just what leaped to mind as I was typing, not a well-researched list of best practice questions or anything of the sort.

[5] If you’re a BI developer maintaining a Power BI application for your organization, you may have already realized that asking a ton of questions all the time may not be appreciated by the people paying your salary, so please use your own best judgment here.

[6] This probably explains why I so casually mentioned the idea of walking into a restaurant. I literally can’t remember the last time I was in a restaurant. Do restaurants actually exist? Did they ever?

Data Culture Presentation Resources

On Thursday, December 10th I joined the Glasgow Data User Group for their December festivities. Please don’t tell anyone[1] but I’ll be bringing the gift of data culture!

The session recording is now available on YouTube:

If you’re interested, you can also download my session slides here: Glasgow Data UG – Building a Data Culture with Power BI.


[1] I want it to be a surprise! Also this footnote makes even less sense now that the session is in the past…

Data Culture: Strategy is more important than tactics

Even though he lived 2,000 years ago, you’ve probably heard of the Chinese military strategist and general Sun Tzu. He’s known for a lot of things, but these days he’s best known for his work The Art of War[1], which captures military wisdom that is still studied and applied today

Even though Sun Tzu didn’t write about building a data culture[2], there’s still a lot we can learn from his writings. Perhaps the most relevant advice is this:

Building a data culture is hard. Keeping it going, and thriving, as the world and the organization change around you is harder. Perhaps the single most important thing[3] you can do to ensure long-term success is to define the strategic goals for your efforts.

Rather than doing all the other important and valuable tactical things, pause and think about why you’re doing them, and where you want to be once they’re done. This strategic reflection will prove invaluable, as it will help you prioritize, scope, and tune those tactical efforts.

Having a shared strategic vision makes everything else easier. At every step of the journey, any contributor can evaluate their actions against that strategic vision. When conflicts arise – as they inevitably will – your pre-defined strategic north star can help resolve them and to keep your efforts on track.


[1] Or possibly for the Sabaton album of the same name, which has a catchier bass line. And since Sabaton is a metal band led by history geeks, they also have this video that was released just a few weeks ago that looks at some of the history behind the album and song.

[2] Any more than Fiore wrote about business intelligence.

[3] I say “perhaps” because having an engaged executive sponsor is the other side of the strategy coin. Your executive sponsor will play a major role in defining your strategy, and in getting all necessary stakeholders on board with the strategy. Although I didn’t plan it this way, I’m quite pleased with the parallelism of having executive sponsorship be the first non-introductory video in the series, and having this one be the last non-summary video. It feels neat, and right, and satisfying.

Data Culture: Measuring Success

Building a data culture is hard. It involves technology and people, each of which is complicated enough on its own. When you combine them[1] they get even harder together. Building a data culture takes time, effort, and money – and because it takes time, you don’t always know if the effort and money you’re investing will get you to where you need to go.

Measuring the success of your efforts can be as hard as the efforts themselves.

Very often the work involved in building a data culture doesn’t start neatly and cleanly with a clearly defined end state. It often starts messily, with organic bottom-up efforts combining with top-down efforts over a period of change that’s driven as much by external forces as by any single decision to begin. This means that measuring success – and defining what “success” means – happens while the work is being done.

Measuring usage is the easiest approach, but it’s not really measuring success. Does having more reports or more users actually produce more value?

For many organizations[2], success is measured in the bottom line –  is the investment in building a data culture delivering the expected return from a financial perspective?

Having a data culture can make financial sense in two ways: it can reduce costs, and it can increase revenue.

Organizations often reduce costs by simplifying their data estate. This could involve standardizing on a single BI tool, or at least minimizing the number of tools used, migrating from older tools before they’re retired and decommissioned. This reduces costs directly by eliminating licensing expenses, and reduces costs indirectly by reducing the effort required for training, support, and related tasks. Measuring cost reduction can be straightforward – odds are someone is already tracking the IT budget – and measuring the reduction in the utilization of legacy tools can also take advantage of existing usage reporting.

Organizations can increase revenue by building more efficient, data-driven business processes. This is harder to measure. Typically this involves instrumenting the business processes in question, and proactively building the processes to correlate data culture efforts to business process outcomes.

In the video I mention the work of several enterprise Power BI customers who have build Power BI apps for their information workers and salespeople. These apps provide up-to-date data and insights for employees who would otherwise need to rely on days- or weeks-old batch data delivered via email or printout. By tracking which employees are using what aspects of the Power BI apps, the organizations can correlate this usage with the business outcomes of the employees’ work[3]. If a person or team’s efficiency increases as data usage increases, it’s hard to argue with that sort of success.

But.. this post and video assume that you have actually set explicit goals. Have you? If you haven’t defined that strategy, you definitely want to check out next week’s video…


[1] Especially since you usually have organizational politics thrown into the mix for good measure, and that never makes things any simpler.

[2] I originally typed “most organizations” but I don’t have the data to support that assertion. This is true of most of the mature enterprise organizations that I’ve worked with, but I suspect that for a broader population, most organizations don’t actually measure – they just cross their fingers and do what they can.

[3] Odds are someone is already tracking things like sales, so the “business outcomes” part of this approach might be simpler than you might otherwise assume. Getting access to the data and incorporating it in a reporting solution may not be straightforward, but it’s likely the data itself already exists for key business processes.