How to Elicit Requirements When Stakeholders Can’t Define What They Want

Disclaimer: The views and opinions expressed in this article are those of the author and may not reflect the perspectives of IIBA.

“They won’t tell us what they want.”
“Leadership can’t define the project.”
“They won’t give us a straight answer that defines success.”

If you work on development projects in the information technology field, you've undoubtedly heard comments like this before. And you’ve probably heard them recently. 

Stakeholders will often tell you what they want, but you need to help them get there proactively. This isn’t as easy as it sounds. And it may be why so many people are quick to conclude that stakeholders can’t define what they want. 

Defining requirements and helping to envision future states is where talented business analysis professionals can add value. This becomes especially true when upfront information from sponsors and key users is thin and/or vague.

Whether eliciting requirements for a smaller change to an existing system or implementing a new system solution, the general approach is similar. In either case, it’s like putting together a puzzle in the sense that only some bits and pieces will be captured at any one time. In most cases, the users have provided some information, however small, and that’s the first piece of the puzzle. 

That first clue will give some direction on where to go next and point to which actions are needed to gather additional puzzle pieces. It's certainly an iterative process, and at some point, the iterations yield enough of a picture that potential solution options can be presented to stakeholders.

Article Strategy Assumptions

This article lists several approaches for eliciting and developing requirements and input when the users are unsure of the end solution they’re seeking. The context and conditions of the specific project must be considered when selecting the approach or approaches that fit best. 

Using the most basic, fundamental strategy, this article positions its solutions approach as defining the current state “as-is,” defining the desired future state “to-be,” analyzing the gaps between them, and then capturing the best solution to bridge those gaps. 

The purpose of this article is to provide some time-tested strategies for defining the to-be state when stakeholders have offered sparse information on requirements and/or solution details. It won’t cover suggestions for specific tools or the full process of solution options analysis for new software.

Start With Outcomes, Not Feature Details

When stakeholders struggle to define what they want, it’s not because they’re being difficult. They may simply not be aware of their solution options. It’s often best to begin with a general approach of asking what problem it is they want to solve or what type of outcome they want to achieve. 

Try asking questions such as: What isn’t working well today? What problem are you trying to solve? What would success look like? These questions are usually relatively easy to answer and will help uncover the details of the core need rather than diving headfirst into design decisions that may be premature.

Once the desired results are understood and agreed upon, potential solution options can be explored and validated with stakeholders using the techniques described below. In many cases, stakeholders may not know what they want, but they frequently know what isn’t working and what they want to improve. 

Our job is to help them get there.

Define the As-Is

Given it exists, define the as-is situation with diagrams and accompanying narratives. What’s more important than the type of tool or technique used is that the artefacts are easy to follow and convey an accurate depiction. Existing documentation may be leveraged and updated if needed or if relevant.

Most people seem to respond best to visual depictions that are simple and easy to understand. If the existing process is large, it works best to break out key components onto separate pages rather than overwhelm the audience with a large, sprawling, and difficult-to-follow diagram.

Visual depictions crafted in this way are a great springboard for generating discussion and ideas.

Use AI, But Don’t Let It Use You

Over the evolution of information technology, there has always been a hot new thing that’s widely seen as essential and the focus of attention and learning. Over the decades, these have included offshoring, codeless, web-based, cloud, and agile, just to name a few. It’s no secret that the hottest new thing today is AI. 

Yes, AI should absolutely be leveraged as an assistant; that is, to facilitate ideas, write suggestions, and do research. However, you should always fact-check information harvested from AI and only ever deliver writing that actually sounds like you. Nothing turns audiences off faster than AI-sounding content. 

Most AI-generated meeting summaries, especially those for larger or more technically focused meetings, miss or misstate the discussion. That said, AI can capture key points that human note-takers might miss, just as human note-takers can catch many points that AI might miss. Blend AI content with your own natural voice, writing, and knowledge to produce meaningful and more valuable content. 

 

Consult With Frontline or Operational Staff

In many situations, these people are often one of the most valuable sources of information. They may be an administrator, someone working on the manufacturing line, or an IT tech providing system support. 

Individuals in this group are frequently experts on the existing system or processes and often offer the benefit of more casual discussion and collaboration. Several or many may need to be interviewed or observed, depending on the process size and number of components. While they may not have the authority to make design decisions, they can provide information about the current process and often have solution ideas. 

Looking past these valuable sources of information can prove costly to project and solution success.

Show Them Something

Visuals nearly always provide a great starting point for discussion. For public-facing websites, this can be as easy as finding the pages from other websites to use as solution examples. However, many of our solutions are internal and may be custom applications that require a bit more effort to generate visual options.

1. Mock-Ups, Wireframes

Options that can be presented in the form of mock-ups or wireframes are a great facilitator for generating ideas and conversation. A tool specifically for this use is nice to have, though typically mock-up images can be generated with standard software.

2. Research Best-in-Class Solutions

For branded enterprise software, research examples of best-in-class solutions to inform your design. Of course, this works for websites and web pages as well. Other organizations’ design features can be presented to stakeholders, so they can cherry-pick what they like best or what suits their organization’s context.

3. Install It, Configure It

This can work well in situations where the enterprise software is already in use and changes are being made, or when a new module or function is being added. If it’s easy to install or configure something in one of the lower-level environments, demonstrating the features to the stakeholders can be a great idea generator and conversation starter.

4. Videos

For new features to existing software, the software company’s standard demonstration videos can often provide information that may be helpful in decision-making. Alternatively, some independent videos can also be very useful. Just be sure to carefully vet such videos before sharing them in a professional setting.

Make It Iterative and Be Flexible

Iterations, regardless of project type, are a simple and valuable method for developing effective products that delight end users. Requirements are never fully known at project start. With iterations, requirements can be discovered and feedback incorporated as the product is developed. 

The caution here is to put some scope around the effort up front to prevent it from becoming an unbounded exercise. Be sure to put requests and ideas into a backlog or suggestion list for future enhancements to show that the suggestions were heard. This also helps reduce the risk of repeated discussions and questions on the same topics or ideas.

Delving a bit into project management, note that iterative doesn’t automatically mean the project effort must be agile. Design iterations can be incorporated into any project, and projects need not be labelled as a particular type of project technique to be successfully executed. All that matters in the end is getting the job done and delivering effective results. 

From Note-Taker to Value Driver

An attendee at a recent IIBA chapter event asked, “How do you communicate your value and be more than just a glorified documenter?” At a simple level, the answer is to be much more than a note-taker.

The ability to elicit requirements and designs when the stakeholders can’t articulate what they want offers a great example of how business analysis professionals can demonstrate their value to the organization. More often than not, stakeholders may only have a rough idea of what they want, making the ability to facilitate their solution definition a key and valued skill.

The solutions in this article may seem obvious, intuitive, or simple to some. However, experience shows that not everyone employs them. The three quotes at the beginning of this article reflect real-world statements from the past two years. Together, they highlight the need to strengthen facilitation in this area. 

For deeper insights and practical tools, explore the full range of resources available to IIBA members.

---

About the Author