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 a BA 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 moral good/positive? Is the project status green? Are deliverables being met? And so on. 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 the BA 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’s, 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 a BA 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. I.e. the dreaded “dumb question” that really is a dumb question. 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 “it’s easier to catch flies with honey than vinegar”. Meaning, creating the 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, 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 desired technical functionality. You find yourself standing at the front of a room full of people that 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 his/her facilitative style to get the group to reach consensus on requirements and resume moving forward. In this case, agreeing on the desired technical functionality.
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 to take a step back and remind the group of the problem you are trying to solve (or new functionality you are creating). Often times JAD sessions stall-out because of 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 as to why they are in the room to begin with. Doing so will remind everyone that they are on the same team trying to achieve the same goal. After that, spend a few minutes to rewind 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 for. Or – more realistically – they do not have the power to make the decision. NOTE – 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 do to unclear scope or 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 the requires 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 to 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 these 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.
Author: Josh Jones is a seasoned Business Analyst with over 9 years of experience in the BA and Project Management space. During that time, he has held several different project roles (primarily business analyst). Josh has successfully applied project and analysis leadership expertise to deliver project initiatives in a wide variety of 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, Josh’s hands-on, “create a solid partnership” approach blends his desire to share his business analysis expertise with his passion for helping others improve. As a presenter and trainer, his energetic and engaging style helps make both the art and science of business analysis accessible to those his works with.
Josh is also an exclusive partner with Genesis10 Consulting where he has helped build and is now the co-leader of the Business Analyst Center of Excellence (CoE). In this role, Josh oversees the growth of the CoE and delivers a wide variety of BA-specific training, mentoring, teaching, consulting and presenting to a number of different clients across the Midwest and East Coast.
Josh has been consulting as a Senior Business Analyst and Project Manager for the last eight years in Des Moines, Iowa.
Article image © niesim - Fotolia.com