This chapter is from the book
This chapter is from the book
This chapter is from the book
Break the Reporting Routine
- "Habit and routine have an unbelievable power to waste and destroy."
- —Henri de Lubac
You're ready to shift your focus to Actionland, but is your organization ready? Many organizations are ensnared and entranced by the rhythm of reporting. Each day, week, or month different reports arrive in people's email boxes waiting to be consumed. It may be reassuring to your company that these reports are being distributed, but few people actually question if those reports are even being used. In many cases, they just gather electronic dust. From my experience, I think everyone—analysts, executives, and entire teams—assumes or hopes somebody else is leveraging and getting value from the reporting. At one company I was working with, an executive admitted she never used her monthly executive dashboard, but she sincerely hoped her team was actively using it. However, her team was too busy updating reports and creating dashboards each month to even look at it.
The reporting rut can be taxing for both business users and web analysts. On one hand, your business users are having their minds and senses dulled by a never-ending flow of reports. Meanwhile, different individuals and groups keep bombarding your web analytics team with more and more reporting requests. Even though you want more time in Actionland, your organization's reporting rhythm has you handcuffed.
You need to somehow disrupt your organization's reporting routine, which may have cast a spell over different individuals and teams within your company. You're not necessarily going to switch off reporting or stage a reporting rebellion, but you will apply more scrutiny to what's being requested. Rather than just taking their long list of requirements for a particular report or analysis, you're going ask more questions:
- What are you trying to achieve?
- What business question are you trying to answer?
- How are you going to use this report or analysis?
- What actions will you take from this report or analysis?
- With what frequency will you be using the data (real-time, daily, weekly, or monthly)?
- Who are you taking this information to?
- What are you trying to convince them to do?
- What is your theory or hypothesis?
By asking these questions, it's another important step away from being just a reporting robot and a step toward awakening your organization from its self-inflicted, report-induced stupor. Web analytics expert Avinash Kaushik noted this type of approach plays to the strengths of each side of the conversation. Business users provide what they know best—the context, business priorities, and problem framing. Meanwhile, the web analysts can better apply their knowledge of the data, tools, and analytical approaches.1 You're going to know better than the business users how to find the right information or insights they're seeking, but only the business users can define what they really need. Working together will result in a better solution whether it's a report, an analysis, or just a conversation.
Insider Insights
Jennifer Frigault is the director of business analytics for Gannett Digital where she leads the Audience Analytics and Revenue Analytics teams.
What brought you to the conclusion that data discussions are important?
For years I said yes every time a request for a new report or dashboard came to my department, whether it was a basic request from the sports editor or a new dashboard request from executives. We had so many reports running on auto delivery that we created rules in Outlook to automatically file them on arrival. We didn't read or track them, and we never received any questions on them. Then the day came when I said no.
Gannett was embarking on a major redesign of its more than 100 local newspaper and broadcast websites, and the project manager was requesting the same old boring, who-cares metrics, in the same old auto-delivery dashboards. When I thought about the strategic importance of this redesign, something told me page views and time spent weren't going to cut it. So I said no—very calmly, but still no. I told the group that I wasn't going to do another daily dashboard that auto delivered to everyone's email.
What did you propose in place of the dashboards?
I recommended we have daily discussions instead and said I would bring the metrics into the meetings where we'd look at them and discuss them together. My team created a template to pull the requested metrics, but we also focused on other things that we felt contributed to the whole story, such as videos viewed, SEO referrals, and so on. The first two weeks of launch we met every other day and discussed the data, making adjustments to expectations, communications, and design. The product team was able to observe, discuss, and learn from what was happening. The discussions generated both insight and action, which another dashboard couldn't have done as effectively. Saying no doesn't always work, but try it every now and then. Let yourself become an analyst again.
Gathering Business Requirements
As you tactfully push back on requests by asking more questions, you're essentially striving to better understand your company's business needs. Whether you're focusing on implementation, reporting, analysis, or testing, you need to be skilled in gathering business requirements. It's a core skill that's applicable in both Setupland and Actionland. Properly clarifying, defining, understanding, and prioritizing business requirements will ensure there are no major gaps between what's needed and what's provided. When it comes to gathering business requirements, there's a simple formula for achieving alignment (Figure 2.7):
){kind=link}
Figure 2.7 These three focus areas ensure there's alignment between what's needed and what's provided.
- Right people. You want to identify and gain direct access to the people who really matter and care about the initiative. These people typically control the purse strings and are ultimately held accountable for the initiative's success. Some intermediaries like to minimize the involvement of these people thinking they're doing them a favor. In other cases, managers may not believe they need to be involved and just delegate the responsibility to one of their subordinates. The business requirements often degrade with each passing interpretation and re-interpretation, introducing potential imprecision and misalignment. In addition, you want to make sure all of the key stakeholders participate in the process or you will end up with an incomplete picture.
Right preparation. Both sides need to be prepared for the process of gathering the business requirements. If business owners show up at your meetings not knowing why they're there, you've failed. Ideally, they should be asked to put some thought into the discussion prior to the meeting so that you can maximize everyone's time and effort. On your side, you should try to gather and review as much material beforehand so that the participants don't feel like you're starting from zero. Showing you've prepared can give you an instant shot of credibility with a new team.
- "If you do not know how to ask the right question, you discover nothing."
- —W. Edwards Deming
-
Right questions. Drilling down into the bottom-line needs of the business team or executive requires the skilled use of thought-provoking, open-ended questions as well as some intuition as to when you've struck the bottom and don't need to keep drilling. Frequently, you'll need to try a few variations of a particular question until you unlock the right answer. Remember you're primarily focused on understanding "what" they want to achieve, and then you dig into the "how" part. Along the way you need to determine what the business priorities are. You also never want to assume you know what the business requirements are, and therefore, you'll want to create your own set of "go-to" interview questions. Here are some basic examples:
- What are your key pain points?
- What business challenges are you trying to solve?
- What is the expected outcome?
- How do you define success?
An important side benefit from the business requirements gathering process is that different stakeholders, groups, and other individuals will feel as though they've been given a voice during the process. Simply by involving various people in the approach you're more likely to gain their trust, buy-in, and support during the execution phase. While gathering business requirements is important in Setupland, you'll see how it becomes an invaluable tool when you venture into Actionland and need to prioritize your analysis efforts.