Gathering Report Requirements (Simplified)

What is requirement gathering in business intelligence? And how can it be done simply, effectively and efficiently?

A Brief Definition

I would posit the following definition: Requirement gathering, simply put, is the process of obtaining knowledge about the reporting needs in an organization. This can be done a variety of different ways, for a variety of different stakeholders and verticals. But the basic premise is the same – you are trying to obtain information about what’s needed to improve reporting in a certain area.

A Few Challenges

This may seem simple, but it often isn’t. Stakeholders can come with a wealth of experience in their industry or vertical that you don’t possess. What appears obvious to them may not be to you. What appears obvious to you may not be to them.

Stakeholders often have experience with other reporting solutions that pre-condition their understanding of what’s possible (for better or worse). They know what they need but haven’t considered if there are other ways to obtain greater impact. Or they want a solution that will boil the ocean and thereby overwhelm the end user.

A Simple Path Forward

Given these challenges, I would offer the following three principles when approaching requirements gathering. The specific tools used may be different. At our company we use Lucid Chart to map our initial discussions and Excel to gather metric-specific details. However, I believe these few simple principles transcend tools, and can help regardless of the reporting area.

Principle 1: Focus on the Business Impact

Take a lesson from the Backstreet Boys – begin your requirements gathering by gauging the business impact of the reporting. Ask what the user wants to report on, but make sure to also understand the why behind the request.

A recent example from a client I worked with: “I’d like a better understanding of the sales funnel and ability to produce at each plant (the what) in order to improve my ability to optimize processes to meet sales demand (the why)”.

Here we’ve uncovered some important information. The ultimate goal is to understand how operations can keep up with sales – not just, what’s in the sales funnel and what’s being produced at each plant. We’ve uncovered that the pain point appears to be with production, not necessarily with sales. The sales figures are helpful context, but we need to understand where inefficiency in production lies so we can improve it and funnel new sales to those locations.

The difference is subtle, but that one additional phrase can become a north star when making decisions on what to display in a report.

Principle 2: Know Your Audience

Who is going to consume the reports? Executives? Managers? Line-level employees? The intended user greatly affects how you develop the report, in large part because their needs are different. Focus on understanding the who before you uncover additional detail.

Try to identify a primary user and a secondary user (or multiple). This will allow you to make the bulk of the reporting decision based on the needs of the primary user, rather than trying to cater to everyone.

In the example above, the intended audience was an executive team in charge of strategic planning. Knowing this helps ensure that only the appropriate amount of detail is displayed on the reports.

Principle 3: Keep it Minimal

My thinking on this point has evolved greatly over the past 4 years. I used to think the goal of effective requirement gathering was to gather comprehensive knowledge about the reporting area so that I could knock it out of the park the first time and move on to the next project.

After many such projects, I’ve come to the conclusion that this is a pipe dream. While I never want to shortcut the process, business intelligence changes all the time because businesses change all the time. And even when businesses don’t change, the new reports usually spark the imagination and open up a world of other requests that could not have been accounted for in the first place.

What to do, then? I would propose focusing only on the minimum level of requirements. What is the business impact? Who is the intended user? What metrics and slices of data do they need to see? How are those metrics defined? And where does the data come from?

If stakeholders aren’t sure what all is needed, just start with a few metrics and build from there. The focus ought to be on speed of delivery (without sacrificing quality) and flexibility to iterate. This approach keeps you from getting bogged down with details and allows you to be nimble as reports are deployed and the inevitable new requests are received.

Conclusion

I hope these brief thoughts are helpful as you consider effective requirement gathering. How do you lead requirement gathering? Are there other principles you believe are equally important?