WHAT FEATURES SHOULD
YOUR POWER BI SOLUTION HAVE?
As Jakob Nielsen said, a wonderful interface to the wrong features will fail! Download a tried and tested requirements gathering template at the bottom.
By FLAVIO MENESES ★ 3 min read
25 May 2021
Why gather requirements
Before embarking on your next data analytics project, you should give yourself the best chances of success even before opening up Power BI, no matter how tempting it might be to just get started in that next report or dashboard!
By having a standard procedure you take end-users and stakeholders through, asking the difficult questions upfront and properly gathering the requirements for the solution you make an investment that will start paying dividends as soon as you start work.
Benefits vs Features
At this stage, you need to be discussing benefits not features. A feature is something your report has or does (e.g. a chart that breaks down sales by month) whereas a benefit is the impact the solution has to the users or stakeholder (e.g. allowing the company to automate KPI monitoring and achieve sales targets).
During requirements gathering, you need to understand the context and drivers for the requests; as a BI analyst, it’s your job to listen and challenge (in a cooperative manner!) user requirements until you’re left with the proposition that will solve a real business problem.
You need to distinguish what the user really needs (the benefit) from what the user asks you to develop (the feature). You’ll find that, in the end, the features you agree upon might be different!
Structure the sessions
There are benefits to conducting both group interviews and one-to-one sessions with the users and stakeholders as both have pros and cons; a group session with the wider stakeholders is beneficial to hear from different quadrants of the business and allow cross-pollination of ideas but has downsides like powerful stakeholders taking over the meeting or group thinking setting in; meeting one-on-one with Subject Mater Experts is fundamental to get the solution right but it’s also time consuming and you’ll be limited to how many you’ll be able to conduct under time pressure and juggling people’s availability.
Whatever the method used, it’s important to have a consistent criteria to evaluate and record the requirements. At the bottom you can download the template I use with some examples already filled in.
Prioritise
As you gather requirements from all the different stakeholders you’ll soon realise there’s more to do that time & budget to do it. This is where the MoSCoW method comes in. This is a prioritisation technique used to reach a consensus with stakeholders regarding what features should take precedence over others (see image below). This suits very well an Agile delivery, as you focus on incrementally delivering work and updating the backlog as new requirements emerge and others subside.
Download template
Hopefully you’ve seen how gathering requirements early, engaging with stakeholders and distinguishing between benefits and features can put your BI solution on the path to success. Below you can find the template I use to do this. Feel free to use it as is or tweak it to suit your own needs.
Download Requirements gathering template