Requirements Gathering Framework for Power BI Reports

Any Power BI Report development project can be broken into 3 general phases (1) Pre-Development (2) Development & (3) Deployment & Sustainment.

More often than we'd like to admit, we jump straight to development stage leaving behind crucial steps that make or break a development project. We make excuses for ourselves and say 'If only I had more time' or 'If only...' So we rush the report and publish it so that we can tick off that check box, but then what...?

...Well, it goes to the dashboard graveyard. The stakeholders who requested the report aren't satisfied with it because you didn't make the time to listen and understand their needs. And your end users won't use it because your 'solution' is not really that at all.

If the objective of developing a dashboard is to provide valuable insights and inform decision makers to facilitate data driven decision making - then you have failed.

Technically, you might have built a sound product but from a 'value to the business' perspective you have built a non-starter, and probably wasted a lot of time and money as well.

So what's the solution?

It starts with listening and understanding the business problem your stakeholders are attempting to solve. As the developer, its your job to turn their strategic vision into a clear requirements and technical specifications. The primary objective of the stakeholder is to tell you Why & What they are looking for. Its your job, to figure out How to develop a solution.

I know this can be challenging for many developers, I admit this aspect of the job may not be what you went to school for nor was it called out in the job description of your role. This is putting on your business analysis & project management hats - that's not easy, I get it!

This is why I present to you my "Power BI Report Requirements Template" it will help capture the requirements relating to the report. Its designed to cover the key areas of focus without weighing you down in loads of paperwork (because we all hate documentation - eh?)

Outlined below is a brief explanation of how to fill out the "Power BI Report Requirements Template"

Report Overview & Goals

The first section of my template is meant to capture the high level objectives of the report, as well as capture all of the stakeholders that are to be involved in shaping the direction of the report. This helps you later in the process when you are scheduling progress update meetings in the development phase and knowing who to include on your calendar invites. The 'Objective' is meant to capture why this report is being requested. You as the developer need to understand the big picture/strategic aim in order to determine what in your development brings you closer to that objective and what does not contribute to the grand vision. The 'Business Value' is meant to get a more tangible objective articulated by your stakeholder(s), it should not be subjective, rather clear and measurable. If you struggle to get clarity from your stakeholders on their objectives and the business value, you need to raise the question (humbly) as to whether this report request is worth their investment in time & energy. It doesn't mean that you cannot support them, but it does mean that you need to guide them a bit more before you can develop any solution.

The Audience Assessment

This section is about understanding the audience/consumers/end-users that you are developing for. These people are not the same as the Stakeholder, your audience will ultimately use the dashboard your stakeholders have commissioned. Its important to capture the 'number of viewers' - i.e. how big or small is your audience. Often times you will also have different personas within your audience (i.e. they have different needs from the report.) You should capture your primary & secondary audiences. It is also important to ask how the audience will be consuming the report - via Power BI Service, on a PPT, in a PDF, or on Mobile or Desktop. All of these display modes & formats will determine the development decisions you will later have to make.

“You've got to keep your finger on the pulse of what your audience is thinking and know what they'll accept from you.” – Dwayne Johnson

The Data Assessment

Now we can get to the data part, what data will be included in the report as well as a high level assessment of the quality of the data. This section is vital for estimating timeframes - i.e. how long will the report will take to develop. This question is really important for stakeholders to understand and thus you need to clearly provide rough time estimations. You need to articulate whether this is a 3, 6 , 9+ month project. One of the biggest mistakes I see developers make is that they don't give this and then have unrealistic timeframes imposed on them. Instead of them managing their time, they are being managed - not a healthy relationship for the developer or the stakeholder.

In this section I ask you to fill in all of the data sources you will need to query in your report. Most often, your stakeholders will not be able to provide you this degree of detail but ask them for data subject matter expert(s) (SME(s)) that can provide that level of detail. Once you identify the data sources, you need to at a high level determine the data availability, accessibility, quality and recency.

Data availability means whether there is sufficient data to support the type of reporting your stakeholders are requesting. Data accessibility means how accessible is the data, do you have the permissions to access this data, if not, how hard and how long will it take for you to get access. Data quality is to determine how 'clean' the data is and how much transformation it requires before it is report ready. Data recency is meant to capture how recent is the data, is it outdated and do we need a higher frequency of refreshed data to support the report development. Any limitations you identify, you capture the free text limitations section.

Lastly, it is important to identify whether an original report exists, even if it isn't a Power BI report. In the subsequent sections, we will circle back to this.

Stakeholder Interviews

Now that we have this baseline knowledge of what the report is meant to achieve as well as the data needed for the report, it is time to do more in depth interviews with your stakeholders. Interviews should be focused and intentional and a good use of stakeholders' time. They often are very important people in your organization and their time is very valuable. The primary purpose of these interviews are to make the stakeholders feel understood and that they can trust you with their data needs. You want your stakeholders to be your allies. And for them to be that, they need to see that you respect their perspectives and that their knowledge is crucial. Even if they do not posses technical/data knowledge, that does not make them any less important. Your SMEs can help fill in the data gaps that your stakeholders might have detailed knowledge of.

Tom Greever in his book 'Articulating Design Decisions: Communicate with Stakeholders, Keep your Sanity, and Deliver the Best User Experience' talks about the importance of letting your stakeholders talk.

"As people talk, they naturally repeat themselves and rephrase what they mean in an effort to communicate clearly, its critical that you give them the space they need to describe them" ..."You want your stakeholders to know that they communicated effectively so that they can't blame a misunderstanding on their inability to communicate (or [more importantly] your ability to listen"..."Allowing stakeholders to talk as much as they want communicates to them that you appreciate what they're saying ad you're listening to every word. When you make them feel that way, it builds trust and they'll be more likely to agree with you later knowing that they've been heard"

If you connect at a human level with your stakeholders, even if you hit unexpected roadblocks in your development process they will support you and provide you the space you need to problem solve. The questions I provide are useful for understanding the pain points and what specifically they are looking for.

Tom Greever in his book 'Articulating Design Decisions: Communicate with Stakeholders, Keep your Sanity, and Deliver the Best User Experience' provides a great framework for forming great relationships with your stakeholders, he shares this advice "See them as human, Ask good questions and Develop Empathy" I completely echo his statement "Communication is easier in good relationships"

End User Interviews

Your end users are the individuals who will most often use the dashboard and will often push your report to its limits, slicing, drilling down and drilling through on your data. Their voices are also an important aspect to consider in your report. If you build something that your end users don't like, they will complain to your stakeholders. Their dissatisfaction will also reflect in their lukewarm or cold adoption of the report.

Development Considerations

Now that you have understood the needs of your audience and stakeholder, as well as the data you are at a good place to start some high level planning. Remember, this will be one of the top questions your stakeholders will expect you to answer. Loose timelines are better than no timelines at all. And it is completely reasonable to provide a lower and upper bound to your estimates (i.e. 6 months +/- 2.) Your stakeholders are reasonable and understand that shit happens, and sometimes it means deadlines are pushed.

I usually call out key milestones in report project plan, I don't need to provide detailed tasks (stakeholders quite frankly don't care that you have to append, group and unpivot your data for it to work - for their purpose - data transformation is sufficient) Zoom out!

Tom Greever in his book 'Articulating Design Decisons: Communicate with Stakeholders, Keep your Sanity, and Deliver the Best User Experience' suggests using horizontal timeline visuals to show where you are in the process and set the context of your project.

I also think its important to setup a recurring meeting with your stakeholders to keep them updated and informed on the progress being made. Ultimately they are accountable to higher ups in the organization, so they need to be able to provide accurate information to their superiors. Also, having the cadence defined allows you to lean on your stakeholders should you hit any snags - like data permissions issues, or provide clarity on some 'odd' data you are seeing.

I then plan out my next steps like Wireframes, Mockups, Data Transformation, Modeling etc. I will expand upon these steps in a future article.

Conclusion

My goal in this article is to provide you an easy-to-use template that can help remove some of the ambiguity in your requirements gathering. Please feel free to download the template and use it!

If you'd like to read a bit more about the topics I mentioned, go ahead and grab these 2 books.

I've quoted Tom Greever's book 'Articulating Design Decisions: Communicate with Stakeholders, Keep your Sanity, and Deliver the Best User Experience' although it is not a Power BI specific book, I think it provides a lot of great advice that you can adapt to your BI development.

"Delivering Data Analytics" by Nicholas Kelly also has some great examples of stakeholder & end user interview questions as well great templates for project planning your development.