Tag: data analytics

Introduction 

Behind every impactful dashboard you’ve ever seen is a well put together plan and an understanding of the objective in creating the tool. It does not matter if the dashboard is being used in a business context or to tell an interesting data story – any successful dashboard requires meticulous planning and an understanding of the underlying data paired with foundational data literacy skills. Regardless of what you’re building and who it is being built for, effective requirements gathering will generally lead to greater efficiency in development and greater user satisfaction. 

Requirements gathering is not a novel concept, but it’s not common either. Individuals and organizations often forgo the process under the misconception that they’re saving time. The reality is that not investing this time upfront leads to inefficiencies down the road, and those inefficiencies can be multitudes greater than the time it would have taken to effectively gather requirements prior to starting development. Multiple rounds of feedback, unsatisfied end users, and dashboards that receive little to no usage after going live are, unfortunately, staples of the analytics world today.  

The good news is that it doesn’t have to be this way. With an understanding of how to gather requirements plus the knowledge of why it is such a crucial step, you’ll be able to gain buy-in from stakeholders and deliver excellent, meaningful analytics products to end users.  

What is Requirements Gathering? 

When aiming to understand what requirements gathering is, it’s important to start by understanding what it is not. There are numerous strategies that attempt to mimic the process of gathering requirements, so let’s address a few of the most common: 

• A single ticket submitted to an IT/analytics team – teams that service multiple parts of the organization often set up a ticketing system to elicit requirements and requests from end users. The problem is that teams often begin development immediately after receiving a ticket that often has limited information. The result is many hours or days that have been sunk into the development of a tool that is built on assumptions and has little chance of exciting users, or even meeting their needs, when it’s released. This is not an indictment of ticketing systems – in fact, ticketing systems are a great way to organize workstreams and manage a high volume of stakeholders, but it’s essential to move into a structured requirements gathering exercise as the first step after receiving a request. 

• Technical requirements without business context – requirements gathering is meant to be a thorough, holistic approach to understanding what is being built and why. A common trap that developers fall into is believing that they only need to elicit the technical aspects of what they’re building. They see themselves as strictly technical resources, their stakeholders as strictly business-focused contributors, and they don’t bridge the gap between the two parties. A collaborative approach with buy-in from both sides to solve the business problem is key in requirements gathering. Empathy, curiosity, and an ability to step outside of the technical development world are essential skills to practice. 

• Defining requirements for others – it should be stated that imagining what others need and developing products for them based on those gut feelings is not an effective way to work with end users. 

So, we know what does not constitute effective requirements gathering, but the real question is: how do we ensure that we go through this process and come out with the necessary information? Requirements gathering can be messy; it can and should result in jumbles of notes, ink smeared whiteboards, and a feeling of renewed energy for the design and development phase of the project. A lot of information will come up during these 1–2-hour sessions, but the following 4 focus areas will help structure your time: 

• Determine the objective – drill into the “why” behind what is being built. It’s perfectly acceptable to start a requirements gathering session by asking the question, “why are we building this?” The idea is to drill into the business problem that we’re hoping to solve, and to understand how we plan to solve that. Ideally, we can create an objective statement that is measurable, then work backwards to understand how a specific tool or technology will accomplish that goal. 

• Define the audience – aside from the overall objective, the most important consideration is the audience. Understanding who will use the tool, how and when they will use it, and their general ability to use analytics products are essential pieces of knowledge when considering design and deployment. The end goal is the ability to create specific user stories that can be used to guide the design and development of the tool in order to drive the greatest adoption. 

• Outline priority questions – this is the time to dive into specific metrics and dimensions related to the data that will be utilized for the project. This information will be used to guide the design of individual visualizations and it is likely that you’ll map specific questions to specific visuals as you move into the design phase. Questions such as “How do each of my sales regions and the salespeople within them rank amongst one another by total volume sold?” represent the level of detail desired when drilling into priority questions. 

• Document dashboard features/other details – lastly, we want to document any special functionality requests. Often times, users will be expecting certain features that they have seen from other tools, or that they have been imagining as valuable for the tool you are building. Think about filters, sorting, data exports, printer-friendly concepts for those paper lovers. These items can be make or break for users; spend time identifying those needs so you can plan to integrate them into the product. 

Final Thoughts 

Remember that requirements gathering is inherently social and requires a deep level of curiosity. It should be collaborative – stakeholders need to be involved and to feel that they’re involved. This isn’t just about soliciting requirements – it’s about gaining buy-in from end users and having them know that they played a crucial role in developing the end product. By defining the objective, audience, priority questions, and key functionality in collaboration with your stakeholders, you will be well equipped to move into the design phase of your project.  

Lastly, it is important to understand when requirements gathering has concluded. In an effort to provide clarity around when we have reached that point, formal documentation is passed to stakeholders and their sign-off is requested. By seeing the requirements formalized and delivered, you and your stakeholders will know that milestone has been completed, and that content will now be used to guide the design of the product. See below for a template that you can use next time you engage in requirements gathering.

---

REQUIREMENTS DOCUMENT TEMPLATE 

<Dashboard Name> 

<Date> 

PROBLEM STATEMENT 

<What are the client’s pain points? Why do they need this dashboard? Why have they come to us?> 

OBJECTIVE OF DASHBOARD 

<What is the business value of the dashboard? Does it help improve revenue? Does it highlight costs that can be reduced? Does it tell the story of an organization’s efforts? Does it increase employee retention?> 

AUDIENCE & USAGE 

<Description of section> 

• Who will use the new dashboard 

• Outline permissions 

• When it will be used 

• How often it will be updated 

• Any subscriptions should be mentioned here 

• Security features 

• How it will be distributed & shared 

BUSINESS QUESTIONS & ACTIONS 

<Description of section> 

Question	Action / Purpose
Business Question 1	What will the answer to this question drive/result in?
Ex. [Which customers have purchased one product, but not the other? What are these customers’ phone numbers?]	Ex. [This allows our sales reps to telephone the customers who are most likely to purchase additional products]

DASHBOARD SPECIFICS 

• Date range of the data 

• Filters 

• Etc. 

QUESTIONS 

• List any outstanding questions here