In this article, I discuss 3 common approaches to collecting reporting requirements, arguing in favor of the third approach - working iteratively & collaboratively with business users to make the report.
When creating reports in Power BI, it’s important to fit the tool capabilities to the design so we can maximize the value from the tools we use. In this report, it takes a long time to get insights from the table, and is very overwhelming. Visualization capabilities in Power BI can help users get information more quickly & efficiently than digging through the table.
They say there’s not enough detail, or that the reports are too ‘fancy’. After some time, the report is used mainly by the executive leadership, while most of the user community turn to other tools and data to answer their questions.
The difficulty with requirements documents is they require many assumptions. In reality, these assumptions are rarely - if ever - fully met. For example, a complete requirements document assumes that the stakeholders filling it out…
represent the entire user group that should use the report
…understand what’s possible with their data, the tool & technology
…know & understand what they need
…can adequately describe what they need to the developer / designer
…can anticipate their future needs and how they will use the reports
…etc
Ideally, the process of defining the requirements should be a collaborative exercise.
necessary, but most useful when combined with user discussions. They become problematic if they’re used instead of talking to business users; ‘thrown over the fence’ between report creators & users.
They start by defining who will use the report with the users
Together, they identify several user groups, each having their own needs and perspectives.
They are working together to define the business questions & problems the users are looking to address. To do this, they ask questions about the reports from their own research, and listen as users explain how they use the reports, what they look for and what they do with the data.
After only 4 hours of workshops, Bink had a much clearer understanding of the users and the report. Bink realized the Flash Report was focused
They drew some ideas on a whiteboard and Bink set to work creating first prototypes.
questions more effectively; users spent less time getting what they needed and had a clearer picture of their situation. Because the developer better understood the business needs, she made better design decisions like selection of chart types, or what metrics to highlight.
it’s feasible, discussing with users can be the single most valuable action you take in a reporting project
and observing the actions users take with their information
There co-creation can bring value, too. Arguably, effective co-creation is a sign of a very healthy community of practice, where self-service creators are focused on answering questions instead of collecting data points.
Some examples:
What actions do we take with the data? What do we do with the insights we get from the report?
What questions are we trying to answer? How do we answer those questions, today?
What do we need to take action?
What isn’t working in the existing reports; what’s difficult, missing or frustrating?
Gathering reporting requirements is a challenging but important exercise. Without the right understanding of business needs, reports will not answer the right questions, and will not deliver the right insights.
Technically, Bink has done exactly what was requested.
power platform
power query
dax
visualizations
service