What Does Success Look Like?
I challenge Business Analysts to view requestors’ requirements as an opportunity to define success. Too often, teams fall into a trap focused on requestors’ prescriptive requirements that are meant to serve as roadmaps for developers and testers. When you limit your view of requirements to this prescriptive lens, you lose sight of the overall objective and stifle the natural creativity that comes from marrying old problems to new, fresh solutions.
Why Do We Need Requirements?
Requirements unite the customer and the solution; they define expectations and how to meet them. Requirements illustrated through user stories or waterfall documentation play a critical role in shaping technical solutions and implementation steps. They also lay out acceptance criteria and use-cases for said requested change. This leads to test scenario creation and the team signing off, saying, “Yes, this is what I requested; it checks all the boxes.” Pretty standard.
But what if we offered more with our requirements? What if we connected those requirements to broader objectives the customer’s trying to solve? What if requirements solved problems customers never realized they had? These solutions ultimately lead to increases in productivity, profits and/or customer satisfaction. When you shift away from the mindset that requirement-gathering sessions are order-taking sessions for technical specifications and move toward the mindset they’re an opportunity to learn about a problem and bring it back to the group for creative solutions, meaningful technical solutions emerge. This process creates solutions that are readily (and enthusiastically) adopted by users and integrated into their processes.
How Do I Get More Out Of Requirements Sessions?
Early in my Business Analyst career, I’d leave requirements-gathering sessions thinking, “How am I supposed to do this when requestors don’t even know what they want?” These thoughts came from requirements-gathering sessions that generally went like this:
BA: “So let’s talk about what ‘xyz’ will look like and what it will do.”
Requestor: “Well, we don’t really know what it can do until you build it.”
Sound familiar? There came a point where I realized it isn’t the customer’s job to know how to give me requirements; it was my job to ask the right questions to find the problem they’re trying to solve and generate solutions. Requestors are hired to be the best accountant, lawyer, analyst, etc.; BA’s are hired to ask the right questions that drive solutions to problems, and sometimes this requires creative, well-placed questions that make the most of requirements-gathering sessions.
Eliciting Requirements
The best questions to use in a requirement-gathering session are those that create dialogue and conversation centered around problem-solving. The more people talk about a requested change, the more information can be gathered by the Business Analyst, bringing everything back to developers/testers for a solution.
Even better than a rousing conversation is a moment of contemplative silence. If you ask a question that causes customers to pause for a beat and say something like, “I hadn’t thought of that before.” you’ve asked a well-placed, creative question. These questions require customers to think through what they’re looking for, how it’ll look if it’s successful and how they’ll ultimately adopt the solution.
Here’s a list of some well-placed, creative questions that drive sound requirements, which lead to technical solutions that are readily (and enthusiastically) adopted:
- What are the top problems/challenges your business faces? Why?
- Why do we need “xyz”? How did we get here?
- What have you tried in the past?
- If this system/change looked exactly how you picture it, what would it look like?
- What’s your best measure of success?
- Is there anything in this process/system you wouldn’t change?
- If this project/enhancement doesn’t happen, what’ll be the impact?
Finding the right time to ask any number of these well-placed, creative questions takes practice, and there’s no better time than now to start.