“According to IBM, poor requirements management is one of the leading causes of project failure” — Source: IBM

After nearly seven years in the analytics space, I’ve come to realise a not-so-secret truth that many data professionals will recognise: the long-term success of any project often hinges on one critical factor: effective requirements gathering.

As our soft skills, such as communication, evolve, we learn to ask more probing and insightful questions, reducing the need for countless meetings, endless iterations and the dreaded scope creep.

However, no matter how refined your approach to requirements gathering becomes, the real challenge is creating a process that’s seamless, consistent and efficient, not just for your team, but also for stakeholders with diverse and wide-ranging needs.

In this blog, I’ll walk you through a streamlined, automated approach to requirements gathering, ensuring your communication skills are embedded into a framework that is both scalable and adaptable.

Is a Report or Dashboard the Right Solution?

Let’s start with a document designed to determine whether a report or dashboard is the right path forward. With experience, you will learn to differentiate between an ad hoc request, where a quick Excel pivot table suffices and a justified need for a report that displays historical trends, refreshes data and empowers senior stakeholders to make informed decisions.

Introducing the Triage Document

I call this document a ‘triage,’ evoking the gravitas of its medical counterpart. Its goal is to guide stakeholders through structured questions while providing report builders with clarity, ensuring deliverables are transparent and aligned with the bigger picture.

The Right Questions Matter

The selection of questions is fundamental to eliciting the required level of detail from stakeholders. There is no universal template here, so use these questions as a guide and adapt them to your specific industry.

Soliciting input from long-serving colleagues and subject matter experts can uncover insights you might overlook while focused on automation.

Start with the Problem Statement

Focus on understanding the problem before exploring solutions:

• Who is impacted?

• When and where is the problem occurring?

• Why did the problem occur?

• How is the process currently done and where are the failure points?

• How often is the problem occurring?

Note: It is critical to focus on the problem, not potential solutions.

It is not uncommon for this exercise to reveal that a solution already exists but remains siloed and inaccessible across the business. This highlights the importance of asking these foundational questions and ensuring the right people are in the room to identify whether the work could be redundant.

Articulating the Business Need

In the data world, context is king. This section allows the report commissioner to explain why the report or dashboard is necessary and what business challenge it aims to address.

By clearly defining the value and purpose of the deliverable, this step ensures the request aligns with broader organisational goals and justifies the need for the work.

Defining the Type of Support

What kind of support is needed? It could range from:

• General advice on how to approach a problem

• A one-off analysis

• A new dashboard or report

• Support for a third-party application

This step helps establish resource allocation and an estimated timeline. For larger pieces of work, upfront communication ensures expectations are clear and realistic.

Granularity and Purpose

Granularity is a critical consideration for reports and dashboards, as it defines the level of detail in the data presented. The required granularity often depends on the specific audience or use case. For instance:

• Operational teams may require highly granular data, such as 15-minute intervals, which falls under near real-time data, to monitor performance effectively.

• Internal management might rely on monthly summaries to assess business trends.

• Regulatory bodies often require quarterly or end-of-year reports for compliance purposes.

It is also crucial to decide the purpose of the report or dashboard:

• Is it for exploration or decision-making?

• Who is the end consumer?

Understanding the audience and their data needs ensures the report provides value without introducing unnecessary complexity. Additionally, discussing the transition to business as usual (BAU) is profoundly important.

The colleagues who will support the report after delivery must have sufficient knowledge to maintain it. Without this, the project never truly concludes.

Device Considerations

Understanding the primary device your audience will use to view the report or dashboard is critical for ensuring usability and accessibility. Whether it’s a laptop, tablet, or mobile device, the design, layout and user experience must be optimised for the target platform.

For instance:

• Laptops: Allow for complex visualisations and detailed data tables due to larger screens.

• Tablets: Require simplified layouts and touch-friendly interfaces.

• Mobile Devices: Demand highly summarised visuals and responsive designs to accommodate smaller screens.

Tailoring the report or dashboard to the primary device ensures that the end user can interact with it effectively, regardless of their working environment.

Let's Talk About Data

Now, moving on to everyone’s favourite topic: data. The questions you ask here are critical to ensuring the success of any report or dashboard. While there are many possible avenues to explore, here are several I’ve found to be the most effective:

• Does the required data exist?

• Is the data in a form suitable for analysis?

• What is the volume of data?

• How often is the data updated (frequency and timing)?

• What are the data constraints or quality risks?

• What are the data sources? (Include links to reports, required fields, etc.)

• What level of granularity is required? (e.g., weekly, monthly, quarterly)

• Are there existing applications providing similar information? (What are their shortcomings?)

Alternative Method of Resolution

At this stage, it is worth exploring whether alternative solutions exist before committing to building something new. The aim here is to identify other avenues that could resolve the issue without requiring significant resource investment.

Key questions to ask include:

• Are there existing reports, dashboards, or tools that could meet the current need with slight adjustments?

• Could a manual process, such as a one-off analysis or pivot table, suffice?

• Have previous attempts to resolve this problem been made and what were the outcomes?

This step prevents duplication of work and helps identify more efficient ways to meet stakeholder requirements.

Critical Milestones

Defining critical milestones ensures the project stays on track and stakeholders remain aligned. This section breaks down the key phases of delivery, allowing for realistic expectations around timelines. Consider asking:

• What are the key dates or deadlines?

• Are there dependencies on other projects or teams?

• What are the phased deliverables? For example, a prototype first, followed by testing and final deployment.

Setting milestones helps establish a clear roadmap and provides checkpoints to ensure progress stays visible and measurable.

Financial and Non-Financial Benefits

No project is complete without a clear understanding of the value it delivers. In this section, stakeholders outline the benefits, both measurable and intangible, of the proposed solution. Key areas to address include:

Financial Benefits: Will this reduce costs, increase revenue, or improve operational efficiency? For example, a projected 10% reduction in inventory costs.

When evaluating resource allocation, it is crucial to prioritise projects that deliver the greatest return on investment. A solution that saves millions should take precedence over one with a negligible return. This ensures time and effort are channelled into initiatives that provide the most value.

Non-Financial Benefits: What qualitative gains will be achieved? These could include improved decision-making, greater transparency, or increased stakeholder trust.

Long-term Impact: How does this solution align with broader organisational goals?

By quantifying benefits where possible, you justify the time and resources invested while demonstrating the solution’s value to stakeholders.

Getting Started with Microsoft Forms

After reading this seemingly exhaustive list, I know at least one reader (if I am lucky) is exclaiming, “this will never fly with my stakeholders!” I completely agree.

Initially, all these questions existed in Excel, but through an iterative process with my team, we distilled them down to around eleven key questions. This brings us to the perfect segue into Microsoft Forms and the beginning of the automation process.

For me, Excel and Microsoft Forms were the applications of choice due to my employer’s current tech stack. However, Google Sheets and Google Forms are excellent alternatives depending on the tools available in your organisation.

To access Microsoft Forms within Teams:

1. Locate the Teams icon in the left toolbar

2. From here, select Forms Survey

This will automatically take you to Microsoft Forms, where you can insert your questions, customise the background and add images to align with your organisation’s branding or colour palette. I recommend spending some time exploring Microsoft Forms to familiarise yourself with the various customisation options, it’s more flexible than it might initially seem.

To save you time, I have listed all the questions I used in the Microsoft Form below. These were carefully designed to elicit the right level of detail for both stakeholders and report builders:

• Who is the commissioner (person identifying the problem)?

• Who will apply the solution? (person(s) to use solution and their roles)

• What is the problem needing solved? (include explanation of business need, frequency, timing and location of the problem)

• Type of support required: Advice, one-off analysis, new report, support third party applications, other

• Dashboard/report purpose (e.g., data exploration or decision making — include decision to be made and decision maker)

• Does the required data exist?

• Data source(s) & granularity required (link reports, name required fields, e.g. hourly)

• Existing application(s) providing similar information (and shortcomings)

• Critical milestones

• Financial benefit(s) and non-financial benefit(s)

• Who will take ownership of the analysis/report upon completion?

Once the form is submitted for the first time, the results are automatically recorded in an Excel file. This file is accessible within the Files section of Teams. You can also preview it on SharePoint by clicking the ellipsis (…) and selecting Open in SharePoint.

Centralising Requests with a Dedicated Outlook Inbox

Next, create a dedicated Outlook inbox to centralise stakeholder requests. To guide you, here is a short, informative article on setting up automatic replies for a shared Outlook mailbox:

How to Set Automatic Replies from a Shared Outlook Mailbox | Breakwater IT

This new inbox serves two purposes: it ensures all stakeholder requests are directed to a single location and subtly signals a shift away from relying on single points of contact.

To reinforce this behaviour, consider adding clickable envelope icons with pre-populated email addresses to your reports and dashboards. This small addition makes it easy for stakeholders to engage and aligns with your streamlined process.

Once your team agrees on the correct wording for the auto-reply, the next step is simple. Copy the URL from your completed Microsoft Form and paste it into your auto-reply text.

Here’s an example of how this can look in practice:

Hi,

To streamline our process and ensure efficient handling of requests, we have set up a new dedicated mailbox for stakeholders to submit their requests.

New Dedicated Mailbox: [INSERT NEW MAILBOX HERE]

Please complete the attached form when submitting your request. This will help us capture all the necessary information and respond to your needs effectively.

[INSERT MICROSOFT FORMS URL HERE]

We will review your submission and be back in contact in due course.

Thank you for your cooperation.

Best regards,

[INSERT TEAM NAME]

Completing the Automation Process

This essentially completes the automated part of the process. To drive user adoption of the new mailbox, you could consider options such as a mass email announcement or including it in the Any Other Business (AOB) agenda of team or inter-departmental meetings.

As mentioned earlier, embedding icons within your reports that pre-populate email addresses is another simple yet effective way to reinforce this behaviour within your company culture with minimal effort.

User Enhancements

Consistency of Feedback: To ensure stakeholders provide detailed and consistent responses in the Microsoft Form, I recommend creating a “blueprint” document in Word. This document should outline ideal responses to all questions, be saved on SharePoint and embedded at the top of your form. Make it clear that stakeholders should read this before completing the form.

Increased Visibility: To make the Excel file collecting responses more visible to your wider team, add it as a new tab in Teams. Click on the (+) icon next to Posts, Files and Lists, search for Excel and navigate to your Triage.xlsx file to pin it.

Bringing It All Together

To summarise, the entire workflow begins when a stakeholder submits a request to the new dedicated Outlook inbox. They receive an auto-reply with a link to the Microsoft Form, which includes a “blueprint” document outlining the level of detail expected.

Stakeholders review the document and proceed to answer the questions in the form. Their responses are automatically captured in the Triage.xlsx file, which is pinned as a tab in Teams and accessible to the entire team. From here, the team can hold appropriate meetings to review the responses and determine the next steps for the project.

Final Thoughts

This article has walked you through a structured, automated approach to gathering stakeholder requirements, one that not only simplifies the process but ensures clarity and alignment for both stakeholders and your team.

By implementing these steps, you’ll create a workflow that saves time, reduces miscommunication and empowers everyone involved to focus on delivering meaningful results.

Now it’s your turn: explore these tools, adapt the process to your organisation’s needs and see how it transforms your requirements gathering. If you have any questions or insights to share, I’d love to hear them.