Introduction
This will be a 3-part blog series inspired by my recent presentations at the Power User Groups in Manchester, Bristol, and the London Business Analytics User Group.
Each part will cover 5 key items to explore, ensuring your reports deliver actionable insights and are embraced by end users. That’s 15 items in total.
From my experience, many assume building a great report or dashboard is straightforward. Typically, the process goes something like this:
- Ask end-users "What do you need?"
- Ask end-users "Where’s the data?"
- Tell end-users "Here’s your report."
Unfortunately, we often rush to develop the report and spend far too little time engaging with end users to truly understand their needs.
It’s also important to highlight that everything we’ll discuss comes directly from hands-on experience with clients over the years. Does it sound like bragging? Maybe a little. But I want to reassure you - these are tried and tested methods. If you follow them, take your time, and do it right, you will see results.
So, let’s dive into Part 1, where we’ll start with the first 5 items you need to nail down to create reports that truly deliver.
1. Find Your Audience!
I’ve talked about this before, but it’s such a key reason why so many reporting projects fail that it has to be on the "creating reports that deliver" list. How can we expect to create a report that actually meets the audience’s needs if we don’t involve the end users in the process?
Imagine this… if I told you I was going to build a product but wouldn’t include the people who will actually use it, you’d look at me like I was crazy. Think about that for a moment. So, why do we think it’s okay to do this when developing reports? Why is leaving end users out of the requirements process treated like it’s normal? It’s not!
Here’s the thing! You will often have a senior leader or representative in the organisation who claims to know everything about the end-users’ requirements. These individuals are usually influential, hold decision-making power or have been with the organisation for a long time. But here’s the problem, they don't understand the day-to-day challenges the end-users face.
The end-users are the best people to tell you their goals and struggles. And there’s an added benefit to gathering requirements directly from them… it builds trust. I’ve had countless conversations recently where people told me their end-users don’t trust the technology, the tool, the data or even the department. When I dig deeper, I find the same story, the end-users weren’t involved in the process.
By the time they saw the report, it was near the end of the journey. They never had a chance to share their input or requirements. And now we are surprised they don’t trust the solution? Of course they don’t!
If for any reason, you cannot include the audience, raise it as a risk. Here are some excuses you will hear:
- Business-critical priorities, end-users are not available.
- Everyone is so busy that we cannot align their calendars.
- They are too new to the business and will not be able to provide the right information.
- They are too junior and will again not be able to provide the right information.
- We have someone who can provide all the information on their behalf.
Whatever the excuse, push back and explain why involving end-users in the process is essential.
Another thing worth discussing, since we are on the topic of audiences, is how many groups we should be collecting requirements from. I have been doing this for over 10+ years now, and I can spot a report that tries to satisfy too many audiences from a mile away. These are the ones that look overly complicated, out of focus, cluttered, no whitespace, full of scroll bars… you get the idea.
Why does this happen so often? Because we are collecting requirements from too many audiences with no shared purpose. So, what does this mean? Before you start gathering requirements, you need to identify the audience. Once that is clear, then you start collecting their specific requirements.
Now, let us say the sales team wants to track individual store and salesperson performance, while the inventory team wants to track stock health and minimise stockouts. Clearly, they have different objectives, challenges… GOALS! Putting them together in one room and trying to gather requirements as a single group will only make the process harder. Separate them.
When I have been pushed to go down this path (even after raising it as a risk), this is what happens… One team, usually the more "influential" one, walks away happy. The other team leaves frustrated, and they will take it out on you and the technology. So, be ready for that!
2. Talk Business
We have identified the true audience of the solution and secured some of their time. Now it is time to start asking questions and gathering requirements. But here is the thing, do not walk into a room/meting with the end-users and simply ask, "What do you want?" That might sound a bit harsh, but to me, it is just lazy work. You are shifting all the responsibility onto the end-users.
As reporting and data experts, it is our job to ask more targeted, thoughtful questions that help users uncover what they truly need. Asking for an existing report as a starting point often leads you down the wrong path. But look, does this always result in failure? No, of course not! But the reality is, many users need guidance and support when it comes to deciding what should go on a canvas.
This is why you sometimes hear, "dashboards are dead." They are not dead! What is dead is the irrelevant information and clutter that ends up on the canvas, pushing end-users away and back to their trusted Excel pivot tables or other tools they previously used.
So, what should you do instead? Ask questions like:
- "What is the purpose of this report?"
- "What keeps you up at night?"
- "What would the ideal report be able to offer?"
It is very likely that many users will freeze when they first hear these questions, and that is okay. They are so used to being asked, "What do you want?" or "Do you have an existing report to show us?". Instead, guide them towards an answer through the way you facilitate your workshops. The key is to uncover a single challenge or objective, in other words, a GOAL!
The reason I like to start from here comes down to a few points, but in this blog, I will mention three.
Firstly, having a goal that is defined, somewhat measurable, and clear helps you understand if the solution you are about to build is genuinely needed. If you cannot derive a goal, that should set off alarm bells. Too often, we are handed a high-level request or vague requirements, and we just run with it. We do not stop to ask and ask… What are we doing? Why are we doing it? What is the value we are meant to deliver? Going back to my earlier point about dashboards being "dead", if we are building dashboards without a clear goal or purpose, it is no surprise they end up "dead" or in the bin.
Secondly, it funnels everything down to the goal. Even with one audience, you will often come across (as I have many times and will continue to do so) the request "We want everything." We want these 30 KPIs! Now, am I saying we should just dismiss KPIs or critical information for the sake of screen estate on a canvas? No! But in my experience, much of what end-users initially request is neither vital or relevant to the GOAL. Having a single goal for a single solution, tailored to a single audience, allows us to deliver something focused, not overly busy or complicated. The biggest pushback I usually hear is… We need a 360-degree view of all our KPIs in the business. Which is fine! I am all for that, but let us approach it differently. We can create a higher-level dashboard for those needs. How does this work? Run focused workshops with a single audience, identify the goal that answers, "Where are we trying to go?" Use that to determine the truly relevant KPIs. Once that is done, we can consolidate these into a single view later, ensuring every piece of information is tied to its purpose.
Lastly, starting with a goal or an agenda to define the goal encourages meaningful discussions about what the business needs, where it is heading, and the ROI. Instead of diving straight into visuals, colour palettes, branding or look and feel. There will always be time for that, the initial conversation should focus on the purpose of the solution. Here is why this is so powerful… if you nail the goal and make it measurable, you can then actually measure the ROI. Think about it. Traditionally, we measured the ROI of a report by looking at usage logs (I always did this)... but is it really about how many views a report gets? No, not at all! It is about what we do with the data. By starting with a challenge or an objective that is measurable, we can understand whether we have moved closer to, further from, or completely achieved it. That is how the ROI of a report should be measured.
3. Measure Success
You have identified the audience, brought them together, and defined a goal for where they are trying to go. Now, it is time to understand the KPIs to determine if we are moving towards that goal or away from it. So, if senior leadership asks for an update on progress, what numbers would we need to see to give them an answer? These are the KPIs, and they are absolutely essential to creating reports that deliver!
It should go without saying, but as Stephen Few highlights, always provide context. For example, if the goal is to increase sales by a certain amount by the end of the financial year, the KPI cannot just be "Sales" or "Conversion". If I tell you sales are £100K for the month and the conversion rate is 23% for the week, what does that actually mean? Without context, such as a benchmark to compare against, we cannot tell if those numbers are good or bad. Context is essential to make KPIs meaningful.
If, for any reason, you are asking various questions to derive the KPIs and the end-users simply cannot provide any… this is a moment to pause and PANIC! Okay, not really… do not panic! But it is definitely time to push back. If the end-users or the business cannot provide their KPIs, it might indicate the need for a higher-level conversation to clarify goals and priorities.
Another thing I want to highlight is the precision of targets I often see being pushed in other places. For example, if you are sitting with a digital marketing team, and one of their KPIs is impressions, do not expect them to derive an exact target for impressions during the workshop. That is just unrealistic. Instead, work with pre-set targets, last year’s comparisons, budgets, forecasts, or similar benchmarks.
Lastly, when collecting KPIs, make sure you do some prep work before facilitating workshops. For example, create a list of 10 questions to ask. A tip that always works for me is using the same questions but phrased differently. This is a key workshop facilitation tip. Many times, you will ask a question to a group of end-users, and it is our responsibility to make it work and ensure everyone engages. Rewording the same question in different ways is an effective method to encourage answers.
That said, I want to point out that what works for me may not work for you. What do I mean by this? Everything I have discussed so far about creating reports that deliver has had no mention of tech, data, features, or capabilities. Why? Because it is all about people… connecting with them and understanding their goals and challenges. It is a people thing, not a tech thing.
Over the last 10+ years, I have been inspired by various experts in the field, such as Stephen Few, Mico Yuk, and many more. I have taken elements from all of them, but following any one method to the letter has never worked for me. Why? Because I am Laz, and I have my own approach to working with people, asking questions, responding to pushback, and connecting. Practice and adapt these methods into your own approach. To be clear, here is an example… I might feel comfortable asking a particular question to uncover the objective, whereas you might not, and that is perfectly fine. Find what works for you.
4. But where is the data?
As I mentioned above, everything I have discussed about creating reports that deliver has deliberately avoided mentioning tech, data, features, or capabilities. This might raise a few questions. However, we often rush to launch our favourite BI or data visualisation tool, whether it is Power BI, Tableau, or Qlik, and fail to spend enough time engaging with the end users. For this reason, I make it part of the agenda in the initial sessions to avoid discussing tech, data, or data availability. This is a practice I adopted from Mico Yuk a few years back, and I still use it today.
By focusing on the business rather than the tech and data, we create solutions that deliver genuine value. Remember, running with a high-level ask without much thought, jumping straight into development, usually leads to solutions that end up in the bin.
Interestingly, this approach often uncovers a few gold nuggets. For instance, I once worked with a marketing team while gathering KPIs. During the session, someone raised a KPI, but another person pointed out that it was impossible to collect due to a lack of data. Instead of dropping the idea, I asked them to continue exploring it, as the focus was not on tech or data at that stage.
We dug deeper and realised the KPI was vital despite the data limitations. After the requirements were gathered, I took the time to sit down with the right people to evaluate what was and was not available. I discovered that although it was previously communicated that this data could not be collected, with some effort, it could actually be included in phase 1. How good is that?
5. Ask Why!
To wrap up part 1 of this blog series, let us talk about the importance of asking "why" to create reports that deliver. This ties back to earlier points, such as avoiding the mistake of running with the initial ask without pausing to think. For example, here are some common requirements that might be thrown at us, and how questioning them, so asking "why", can help refine the solution:
- We need 5 years’ worth of data in this solution. Why? We only need This Year vs Last Year and no trending analysis.
- We need these 26 KPIs displayed in this solution. Why? Only 10 impact the purpose of the report.
- We need to go to the lowest level, which is Product SKU. Why? This is only required by a single person and is not a common query path.
- We need this report to land in our inbox every day. Why? The report is refreshed weekly and can be viewed online with one click.
Hopefully, you see the point. Many times, we shy away from asking "why" because we worry the end-users, customers, clients, colleagues, senior stakeholders, might take it the wrong way. But here is what I believe, if they are good people to work with, they will appreciate you questioning bad practices or flagging something that can be improved. Asking "why" helps you provide a solution that truly addresses their needs. I always tell my clients, "I am not here to simply say yes to everything."
Summary
There you have it, our first five items to ensure you are on the right path to creating reports that deliver. You will have noticed that these points are focused heavily on gathering requirements and understanding both the people and the organisation. In Part 2, we will shift our focus towards the design and usability of reports.