You are on page 1of 4

Using Adaptability as a Guide to Navigate the Uneven Terrain of Require...











View By Author View By Month View By Popular Tag Comment Wall

Monday, 18 June 2012 04:00

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

Written by Josh Jones
font size Print Email Add new comment

Rate this item

(1 Vote)

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 doesnt go as planned (because all good BAs always have a plan) then youre 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.

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 youre walking into is to focus your senses to the pulse of the project. Is the projects health good? I.e., is the project teams 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 styleif necessaryto be supportive in that environment so you can grow your knowledge and help promote the positive vibe. And it could be that you dont 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 essentialalmost imperativefor 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 questionsbut 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 dont want to make an already hostile environment worse by asking questions that are rhetorical (unless when proving a point or trying to get someones light to come on for their ah ha moment) or questions that could make you lose credibility. Steer clear of questions like, Why didnt 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 customers 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.

1 of 4

6/23/2012 3:45 PM

Using Adaptability as a Guide to Navigate the Uneven Terrain of Require...

The reason for this can be chalked up to the old adage that its 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 doesnt play nicely in the sandbox. Is it possible? Yes. But its not easy. Trust me, Ive been on both sides of that fence. The Making of a Business Analyst Agile Mistakes Part 2: A Failed Conversion to Agile Using Adaptability as a Guide to Navigate the Uneven Terrain of Requirements Elicitation Being Authentic Doesnt Give One License To Be 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 its 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: youre 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, its 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 510 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 its 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 theyve 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 Ive 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 dont be afraid to challenge yourself to adapt to your surroundings; thats how good BAs become great BAs. Don't forget to leave your comments below. Read 442 times Last modified on Tuesday, 19 June 2012 12:22 Popular Tags An Ass Recent Popular Comments







community competency customer

development documentation

elicitation enterprise facilitator leadership learning


maturity mentor modeling motivation

performance planning processes professional

software stakeholder success

risk scrum senior skills


technical techniques

technology tips training use case waterfall


Published in Articles Tagged under Requirements management elicitation

Josh Jones
Josh Jones is a seasoned BA with over 9 years of experience in the BA and PM space. Josh has successfully applied project and analysis leadership expertise to deliver project initiatives in a wide variety of

2 of 4

6/23/2012 3:45 PM

Using Adaptability as a Guide to Navigate the Uneven Terrain of Require...

industries (including product fulfillment and distribution, insurance, broker dealer management, Life and Annuities products, information technology, network services, financial services, investment/retirement products, and agriculture). As a mentor and BA coach, Joshs hands-on, create a solid partnership approach blends his desire to share his business analysis expertise with his passion for helping others improve.

Latest from Josh Jones

The Business Analyst: When Not Knowing the Answer is OK The Business Analyst: When Not Knowing the Answer is OK

Related items
The Lighter Side of Project Issues and BA Actions Resistance as a Major Source for Requirements Risk The Top 5 Mistakes in Requirements Practices and Documentation Demystifying Lean Six Sigma Methods for Eliciting - Not Gathering - Requirements More in this category: Being Authentic Doesnt Give One License To Be An Ass Agile

Mistakes Part 2: A Failed Conversion to Agile

Add comment
Name (required) E-mail

Notify me of follow-up comments


back to top

3 of 4

6/23/2012 3:45 PM

Using Adaptability as a Guide to Navigate the Uneven Terrain of Require...

BA 2012 | Sitemap | Terms of Use and Privacy Policy Business Analyst Articles | Business Analyst Webinars and Training | Business Analyst Jobs | Business Analyst Books | Business Analyst Events

4 of 4

6/23/2012 3:45 PM