Requirements Gathering: The Secret to Successful Power BI Projects for FP&A

Summary

In this edition, we will be covering the following items:

1. The pain of not having robust requirements gathering in place

2. Understanding the value of well-structured requirements gathering

3. A framework for organizing your own requirements gathering process

What Development Without Robust Requirements is Like

We’ve all experienced projects that are behind schedule and over-budget. So often, this is because of missing or poorly defined requirements. The reason projects like these continue to be problematic is that no one has a clear understanding of what success looks like:

1. Missed Deadlines: When your team and your tech partners don’t have a clear definition of success it becomes very difficult to reliably achieve your goals within deadlines. One of the most common reasons for missed deadlines in a Power BI project is poorly defined and missing requirements.

2. Poor User Experience: Without clearly stated requirements your team can end up with tools that don’t serve their needs (or do so poorly). This can demoralize the team and makes it difficult to get engagement for future technology projects.

3. Scope Creep: Shifting goal posts can often be a consequence of missing or incomplete requirements.

4. Unhappy Stakeholders: Ultimately, your stakeholders, users, and management will pay the cost of poorly defined requirements for any finance transformation project (Power BI and others).

An Ounce of Requirements Is Worth a Pound of Development

Small investments in gathering, refining, and clarifying requirements can save vast amounts of time, money, and effort in development later. Approaching this exercise with the right frame of mind is critical to success:

1. Requirements Are the Antidote: Just the exercise of sitting with your BI partners and mapping out the desired outcome will be valuable for you and your team. It can act as a forcing function for clear thinking. It will also be invaluable to the success of the project. Well-written requirements can serve as the first building blocks for your Power BI and finance transformation roadmap.

2. Tech Partnership, Not Tech Support: Well developed requirements are almost always the result of a strong partnership with the development team. Developers are highly skilled in the art of the possible. FP&A professionals know their subject intimately. When the two teams partner, and when FP&A teams have a Power BI competency, the results are outstanding.

3. Flexibility, Not Rigidity: Requirements should never constrict the business team to building a solution that isn’t fit-for-use. Well-written requirements build in room to navigate ambiguity and complexity. Often, the act of identifying unknown variables to be solved is the first step to solving them – and a robust requirements document is the first step on that journey.

The Process of Generating Great Power BI Requirements

Great Power BI projects are driven by asking great questions. It may not always be possible to capture every single detail in a requirements document. That’s why your team needs to work backwards from these probing questions, to help guide the development process, whenever there is a complication:

1. Audience and Context: Your first task is to align on the stakeholders who will be using this dashboard. What use case does the dashboard need to solve for? In what context will it be used and by whom? What questions are the users trying to answer? What actions do you want the dashboard to drive?

2. Use Case and Pain Points: What is this dashboard replacing? What are the key pain points with the existing solution? Who will own the dashboard and make use of it on a day-to-day basis? What problem are they trying to solve? How can we engineer the dashboard to solve for that problem specifically?

3. Decision-Making Goals: What decisions need to be made based on this data? What action items and business inputs need to be tracked here? Where will this tool fit into the decision-making process?

4. Data Sources: Where will the data come from? What data do we need? Do we have that in our source systems? How does that data need to join up and be transformed? What data quality measures need to be in place?

5. Calculations, Visuals, and Metrics: What calculations do our users need to see? How do they need this data displayed? What KPIs does the report need to include? How does the team currently perform this analysis? What logical groupings of analytics need to be in place?

6. Users, Security, and Access: Who needs access to the dashboard? What level of access should each user have? How should we protect sensitive data?

In the Next Newsletter

We will learn about creating full FP&A reporting and analytics ecosystem with Power BI Service and Power BI Apps.