Strategies to Improve Your Requirement Gathering Process

When projects fail _ or worse, when completed projects don’t actually achieve the desired end state _ you can sometimes look all the way back to your Business Requirements Gathering process. I’ve been a project manager for more than 20 years, yet I don’t know many people who wake up each day excited about this stage. You can almost hear the chorus of inner groans. No wonder: It can be tedious, it can be time-consuming, and worse of all, it can be ineffective.

But when done correctly, Requirements Gathering can mean a home run for your project. When it’s done really well (aka strategically), that’s when a Business Analyst becomes the hero that just hit the home run with the bases loaded at the bottom of the 9^th in October.

Now that’s exciting!

So what’s the difference? Recently, I had a discussion with my colleagues on this subject. I’m teaching a Business Analysis Boot Camp, and as we were reviewing content, we began to map out what became a “BR philosophy,” of sorts. How do you “peel back the onion” to make sure your project is off to the very best start?

How to Improve Your Requirement Gathering Process

1. Start with an agenda, then be willing to throw it out the window

An agenda and thorough framework are essential for successful requirements gathering sessions – your meetings with stakeholders are unlikely to get anywhere unless you start with an idea of where you want to go. That said, great business analysts remain open to throwing the agenda out the window to explore a new idea. The challenge is having a deep enough understanding of your organization’s goals and challenges to know which rabbit holes are worth exploring, and which aren’t.

2. Be relentless in your pursuit of requirements

A common mistake in the requirement gathering process is limiting input to the core individuals and stakeholders for a given project. Limited inputs lead to limited success. Take the extra time to gather information from every department, team, and individual that will touch your project or be affected by the outcome. Corner the people who stayed quiet through a discovery session during the coffee breaks – you’ll be surprised how many times you’ll come back to the table with information you would have otherwise missed. Focus on any interfaces that are mentioned, including implied or explicitly stated “inputs.”

3. Get ruthless with your red pen

Gathering an exhaustive amount of information at the beginning of a project decreases the risk of hearing the phrase “wouldn’t it be great if we added…” when you’re in the home stretch. It also increases the chances you’ll get distracted by unnecessary requirements – building a Swiss army knife when all you needed was a corkscrew. Once you’ve exhausted your avenues for gathering information, get ruthless with your red pen, separating the “need to have” from the “nice to have.”

4. Take the road less traveled

The “happy path” is a phrase used to describe how a project would progress under ideal conditions, and many of us are guilty of planning our projects according to the happy path.

One of the most common reasons projects fail is the inability to adapt to change, the result of inadequate requirements gathering. That’s why it’s important to leave the happy path for the road less traveled – push to discover how project requirements will change when things don’t happen the way they’re supposed to happen.

Listen for words that indicate assumptions: typically, usually, should, etc. Challenge those assumptions by asking questions and presenting alternative scenarios for every step of a project. At each node of the process, ask “Are there exceptions? What is x? It is always blank who does blank?”

5. Prototype as you go

Visualize and attack – as you hold discovery meetings with your stakeholders, try drawing out the project framework as you go, even if you know it won’t work as-is. Capturing what they’re saying can help the individuals in the room see what they’re missing, and can help them think constructively about project requirements. By the end of the requirement gathering process, you may have an almost-workable solution.