Skip to main content

Using Adaptability as a Guide to Navigate the Uneven Terrain of Requirements Elicitation

Adaptability is a word that is not used enough in the context of business analysis and collecting requirements. Though it is used in the project world, “adaptability” is more synonymous with project methodology or project teams as a whole than it is with requirements elicitation or requirements management. Being adaptive to your surroundings is what can save you from the perils of uncertain environments, non-engaged subject matter experts or the dreaded “analysis paralysis” effect. When it comes to adaptability, one things is certain: if you, as a BA, cannot adapt your approach for gathering requirements when something doesn’t go as planned (because all good BAs always have a plan) then you’re greatly reducing your chances of delivering top-quality requirements. Two of the more prominent areas that lend themselves to easy adaptability of BA styles are environment and facilitation.

Environment

As soon as an assignment or project starts, one of the first things BAs can do is figure out what kind of environment they are in. Not just figuring out the project environment, but more importantly, the requirements-gathering environment. Is it hostile? Is it new? Is it “friendly”? Or is it something completely different? One of the quickest ways you can establish what kind of environment you’re walking into is to focus your senses to the pulse of the project. Is the project’s health good? I.e., is the project team’s moral good/positive? Is the project status green? Are deliverables being met? If the project environment is healthy (good or green), then you, as the BA, should be able to easily adjust your style—if necessary—to be supportive in that environment so you can grow your knowledge and help promote the positive vibe. And it could be that you don’t have to adapt anything at this point. You could find yourself in a situation where everything is running smoothly and all you have to do is join in the fun and perpetuate the positive environment.

Conversely, if the environment is hostile (or bad) then it is essential—almost imperative—for BAs to adapt their style so they can be successful in that environment. Some signs to look for to determine if you could be in a hostile project environment are: project team member morale is low, people (stakeholders, SME’, IT, QA, etc.) do not get along due to project-induced stress, deliverables are not being met or the project is in a red status. One of the simplest, easiest things BAs can do to adapt their style to be successful in a hostile environment is to ask questions—but not just any questions. Be sure the questions you ask are thought-provoking and open-ended. Your goal is to foster insight and feedback from your project peers, not insult them due to a lack of knowledge or their potential ignorance. Additionally, you don’t want to make an already hostile environment worse by asking questions that are rhetorical (unless when proving a point or trying to get someone’s “light” to come on for their “ah ha moment”) or questions that could make you lose credibility. Steer clear of questions like, “Why didn’t we discuss this sooner?” “Why is that in scope?” or, “What are we trying accomplish?” These types of questions can incite frustration and can possibly damage your credibility as the leader of the requirements-gathering session. Try asking questions like, “What can we do from a process and functionality standpoint to fulfill the customer’s needs?” or, “What would the user think if we added this widget?”

Another thing a BA can do to find success in a hostile environment is create partnerships with project team members, SMEs and stakeholders built on credibility, trust and knowledge. Use your skills, strengths and past experiences to bridge gaps with other team members who are generating obstacles or who may be difficult to work with. The sooner you find common ground and create a healthy relationship with these folks, the easier it will be for you to extract requirements from them. The reason for this can be chalked up to the old adage that it’s easier to catch flies with honey than vinegar. Creating a partnership and building trust with project team members, SMEs and stakeholders will make it easier for you to have the conversations necessary to elicit requirements, especially in hostile/challenging situations where it can be difficult to pull information out of a resource that doesn’t play nicely in the sandbox. Is it possible? Yes. But it’s not easy. Trust me, I’ve been on both sides of that fence.

Facilitation

Whether you are in a healthy or hostile project environment, how you adapt your facilitative style is what could make or break your requirements gathering experience. Not only is good facilitation one of the key components for eliciting requirements, but it’s the one adaptive characteristic that a BA can tap into for quickly switching gears, changing directions and altering the landscape of requirements gathering. Picture this: you’re a lead BA facilitating a three-day JAD session with a mix of SMEs, IT resources and a couple project stakeholders. Everything is going smoothly. Your requirements sessions are fruitful (generating requirements), on time and on scope. Then, on day three you hit a snag when trying to drill down a business requirement to capture the desired technical functionality. You find yourself standing at the front of a room full of people who cannot agree on what the requirements should/can be. Something like this can happen at any time during the first session or over the course of a few weeks, depending on how fast your JAD sessions are moving and how much ground you are covering. But no matter when it happens, it’s crucial for the BA to 1) recognize that it has happened, and 2) adapt a facilitative style to get the group to reach a consensus on requirements and resume moving forward.

In my ten years of experience, this has happened to me numerous times and the one quick change I have found that provides an immediate positive effect is to spend 5–10 minutes taking a step back and reminding the group of the problem you are trying to solve (or new functionality you are creating). Often, JAD sessions stall because of a loss of focus. Whether it’s scope, project goals or the requirements themselves, when your audience loses focus, momentum slows and agreement dries up. Remind them of the purpose of why they are in the room to begin with. Doing so will remind everyone that they are on the same team and trying to achieve the same goal. After that, spend a few minutes rewinding the progress you have made to that point to show the group of the teamwork they’ve put forth to get to that point.

The next thing that helps get a JAD session back on track is to verify that the right people are in the room. Maybe your JAD session has run aground because no one in the audience feels comfortable making a decision about the functionality or problem being solved. Or, more realistically, they do not have the power to make the decision. (If you have run aground at the very beginning of your JAD session you might want to escalate to the PM to revisit the project scope with the team. I bring this up because more often than not, stalling out early in requirements-gathering efforts is usually due to unclear scope or a lack of agreement on scope.)Likewise, if you find your JAD sessions going well and you finish up early, take the opportunity to shift gears and adjust your facilitative style to be more thought-provoking by requiring a deeper level of detail in order to cover any extended requirements/functionality/process steps/needs if there is extra time. As a BA facilitating a requirements-gathering sessions, you must always be prepared for the worst- and best-case scenarios. The last thing you want to do is leave time on the table or possibly lose credibility by appearing to not be fully prepared for all scenarios. Though it is unlikely that the audience will see you as the latter, my motto is to over-prepare to keep yourself from under-delivering.

These are a few of the best practices that I’ve used to find successes when adapting my BA style to deliver top-quality requirements. And while there are other key components of adaptive adjustments for the BA space, use those mentioned above to get you started down the path of consciously thinking about adapting your BA style when environmental and/or facilitation conditions change. And don’t be afraid to challenge yourself to adapt to your surroundings; that’s how good BAs become great BAs.

Don’t forget to leave your comments below.

Comment