Skip to main content

Author: Josh Jones

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.

The Business Analyst: When Not Knowing the Answer is OK

Dont_Know_Fotolia_27158559_XSA new project has spun up and you’ve been assigned as the Business Analyst (the same scenario outlined below could happen if you are added to a project that was already in flight). You’ve done your diligence preparing; you’ve read the scope, reviewed the charter document and called your first requirements gathering meeting with the business partners and IT representatives. Your meeting is underway and while you’re attentively listening to the business SME explain the detailed process for transferring a policy from one agency to another, you find yourself feverishly jotting down notes as the nuggets of information being thrown out are too juicy not to capture. Then it hits you: you have no idea what the business SME is talking about!

Though your notes are word-for-word with what the business SME is saying, they might as well be a foreign language that you don’t speak. The fear of looking foolish or not wanting to lose creditability in the eyes of the project team, you do your best to keep writing while desperately trying to grasp the concepts that the SME is laying out in front of you. When first assigned to a project, this is where most BAs get tripped up.

In my experience (ten years in the BA and PM space), I’ve been there many times. And it wasn’t until a few years ago that I finally figured out how to handle the situation described above successfully. No matter how seasoned of a Business Analyst you are, a situation like the one above will happen. It’s inevitable. It’s very rare for a BA — no matter how much experience they have — to start every project with knowledge that will allow them to know what’s going on at all times for all scenarios.

The hardest parts of when you don’t know the answer is:

  1. trying not to look dumb in the eyes of fellow project team members
  2. knowing how to make sense of what is being said and 
  3. being able to take the information given to you — at a time when it makes no sense whatsoever — and produce relevant (and accurate!) requirements.

There are four simple tricks you can use to get you out of the jam of not knowing the subject matter yet still get something out of the meeting.

First, use your “Veil of Unfamiliarity.” As a contracting BA, I have many clients. And most of the time, when I work with a client, I know very little about the interworkings of their internal process, knowledge workflow and system-to-system linkage. But that doesn’t stop me from quickly picking up the things I don’t know. When I find myself new to a client, I often stand behind my “veil of unfamiliarity.” What I mean is even though you have all the best analysis skillsets in your toolbox, they are useless unless you know how to use them on a project. When I find myself on a brand new project that I know very little about, I will often say (out loud), “Since I’m new to this subject matter, I’m going to step behind my veil of unfamiliarity for a moment, could you explain that in more detail?” This is similar to asking the client, “Would you mind putting what you just said into easier-to-understand terms/language?” The reason you want to use your veil is so you can understand the unfamiliar topic at a higher level (less detail) before later diving into the weeds of that particular process flow or UI functionality or whatever it is that you’re trying to understand. In other words, you are openly admitting that you aren’t familiar with the details of the subject matter…yet. Being open and honest by asking the client to make the topic easier for you to understand will further strengthen that trust relationship with the project team and business partners. Using your “Veil of Unfamiliarity” is another way of saying, “I don’t know what you’re talking about yet, but I will soon,” all the while saving face (protecting your integrity) with the project team.  


Second
, look for action items — even if they aren’t for the BA — and insert yourself into them (when it makes sense, of course). Another trick I’ve found to work well is to associate myself to follow-up action items that come out of a meeting even if they don’t directly involve me. Take the opportunity early in a new project to absorb and learn as much as you possibly can. It doesn’t matter where the source is either; just immerse yourself in anything topical to the project. Of course, it goes without saying that you should take care of your BA responsibilities first, but if you have the chance to sit in on a meeting with IT as they review a design document or sit with the business partners as they figure out how they want to incorporate their needs into deliverables, do it. Even though some of the action items aren’t directly tied to your BA work on the project, you’ll be building that background knowledge that will come in handy later on in the project.

Next, create a partnership with the Business SME (or wherever the knowledge is). While it’s always important for the BA to have a healthy partnership with the Project Manager, it’s just as important to have a healthy, open partnership with the Business SME. After all, they are the ones whose needs must be met by the project. More often than not, this relationship is overlooked, not in place or undervalued, and can lead to limited — or in worst cases broken communication — between you (the BA) and them (the owner’s for the needs/business requirements). If you want to be successful in the BA space, you must value the partnership with the business SME. It will be so much easier to get vital information quickly when the partnership with the Business SME is healthy, strong and open.

Lastly, and probably the hardest trick of all, is to be humble and ask. This is the simplest trick to grasp, but also the hardest to actually do. If you are like me at the start of a new project, you’re cautious of exposing your proverbial underbelly to a new project team. By that, I mean you’re hesitant to let your colleagues know that you have a vulnerability around fully understanding the subject at hand right out of the gate. However, if you don’t speak up now (at the beginning of when you start a project), it’s too late. Because the role of the BA is so vital to the overall success of a project, you should never pass up the opportunity in the beginning to ask the business SME — or anyone else on the project team for that matter — to clarify their comments if you do not understand them. It could be comments about scope, business needs, requirements, functional specs or anything project related. The point is, it doesn’t matter what the topic is: if you aren’t crystal clear with your (the BA’s) understanding, ask them to clarify their statement(s). More often than not, the requirements phase of a project moves at light speeds, so it’s important to level-set expectations of understanding the subject matter early and often in order to avoid getting left in the dust. And if you’re worried about losing creditability in the beginning of a project for not knowing the subject in detail, just imagine how much creditability you’ll lose when you get three weeks into requirements gathering sessions and you still don’t know what’s going on. Trust me, I’ve seen it happen and it’s not pretty! In the end, the business SME — or whoever is providing the clarity — would rather provide more clarity on a topic that you asked about than find out you (the BA) did not fully understand it.

Too often, I’ve seen good business analysts lose credibility with a project team because they aren’t willing to admit that they don’t know something. Fearing they will be ridiculed, the BA will play along like they know the subject matter, but when it comes down to crunch time on a project and they aren’t as well versed in something they’ve said they are, then that is when the requirements are at risk of being incomplete, or worse, incorrect. It doesn’t have to be that way! The next time you find yourself sitting in a project meeting or requirements gathering session and you don’t know the answer to a question or don’t know how a business process works, try using one of the tips in this article to assist you with gaining a better, clearer understanding of the subject. In the end, you will thank yourself for being bold enough to put aside your fear of losing credibility and doing what it takes to have a clear, concise understanding of the topic at hand. By doing that, you will have put yourself in the position to produce solid, real and most importantly, accurate requirements.

Don’t forget to leave your comments below. 

The Business Analyst: When Not Knowing the Answer is OK

A new project has spun up and you’ve been assigned as the Business Analyst (the same scenario outlined below could happen if you are added to a project that was already in flight). You’ve done your diligence preparing; you’ve read the scope, reviewed the charter document and called your first requirements gathering meeting with the business partners and IT representatives. Your meeting is underway and while you’re attentively listening to the business SME explain the detailed process for transferring a policy from one agency to another, you find yourself feverishly jotting down notes as the nuggets of information being thrown out are too juicy not to capture. Then it hits you: you have no idea what the business SME is talking about!

                Though your notes are word-for-word with what the business SME is saying, they might as well be a foreign language that you don’t speak. The fear of looking foolish or not wanting to lose creditability in the eyes of the project team, you do your best to keep writing while desperately trying to grasp the concepts that the SME is laying out in front of you. When first assigned to a project, this is where most BAs get tripped up.

                In my experience (ten years in the BA and PM space), I’ve been there many times. And it wasn’t until a few years ago that I finally figured out how to handle the situation described above successfully. No matter how seasoned of a Business Analyst you are, a situation like the one above will happen. It’s inevitable. It’s very rare for a BA — no matter how much experience they have — to start every project with knowledge that will allow them to know what’s going on at all times for all scenarios.

                The hardest parts of when you don’t know the answer is 1) trying not to look dumb in the eyes of fellow project team members 2) knowing how to make sense of what is being said and 3) being able to take the information given to you — at a time when it makes no sense whatsoever — and produce relevant (and accurate!) requirements.

                There are four simple tricks you can use to get you out of the jam of not knowing the subject matter yet still get something out of the meeting.

·         First, use your “Veil of Unfamiliarity.” As a contracting BA, I have many clients. And most of the time, when I work with a client, I know very little about the interworkings of their internal process, knowledge workflow and system-to-system linkage. But that doesn’t stop me from quickly picking up the things I don’t know. When I find myself new to a client, I often stand behind my “veil of unfamiliarity.” What I mean is even though you have all the best analysis skillsets in your toolbox, they are useless unless you know how to use them on a project. When I find myself on a brand new project that I know very little about, I will often say (out loud), “Since I’m new to this subject matter, I’m going to step behind my veil of unfamiliarity for a moment, could you explain that in more detail?” This is similar to asking the client, “Would you mind putting what you just said into easier-to-understand terms/language?” The reason you want to use your veil is so you can understand the unfamiliar topic at a higher level (less detail) before later diving into the weeds of that particular process flow or UI functionality or whatever it is that you’re trying to understand. In other words, you are openly admitting that you aren’t familiar with the details of the subject matter…yet. Being open and honest by asking the client to make the topic easier for you to understand will further strengthen that trust relationship with the project team and business partners. Using your “Veil of Unfamiliarity” is another way of saying, “I don’t know what you’re talking about yet, but I will soon,” all the while saving face (protecting your integrity) with the project team.  

·         Second, look for action items — even if they aren’t for the BA — and insert yourself into them (when it makes sense, of course). Another trick I’ve found to work well is to associate myself to follow-up action items that come out of a meeting even if they don’t directly involve me. Take the opportunity early in a new project to absorb and learn as much as you possibly can. It doesn’t matter where the source is either; just immerse yourself in anything topical to the project. Of course, it goes without saying that you should take care of your BA responsibilities first, but if you have the chance to sit in on a meeting with IT as they review a design document or sit with the business partners as they figure out how they want to incorporate their needs into deliverables, do it. Even though some of the action items aren’t directly tied to your BA work on the project, you’ll be building that background knowledge that will come in handy later on in the project.

·         Next, create a partnership with the Business SME (or wherever the knowledge is). While it’s always important for the BA to have a healthy partnership with the Project Manager, it’s just as important to have a healthy, open partnership with the Business SME. After all, they are the ones whose needs must be met by the project. More often than not, this relationship is overlooked, not in place or undervalued, and can lead to limited — or in worst cases broken communication — between you (the BA) and them (the owner’s for the needs/business requirements). If you want to be successful in the BA space, you must value the partnership with the business SME. It will be so much easier to get vital information quickly when the partnership with the Business SME is healthy, strong and open.

·         Lastly, and probably the hardest trick of all, is to be humble and ask. This is the simplest trick to grasp, but also the hardest to actually do. If you are like me at the start of a new project, you’re cautious of exposing your proverbial underbelly to a new project team. By that, I mean you’re hesitant to let your colleagues know that you have a vulnerability around fully understanding the subject at hand right out of the gate. However, if you don’t speak up now (at the beginning of when you start a project), it’s too late. Because the role of the BA is so vital to the overall success of a project, you should never pass up the opportunity in the beginning to ask the business SME — or anyone else on the project team for that matter — to clarify their comments if you do not understand them. It could be comments about scope, business needs, requirements, functional specs or anything project related. The point is, it doesn’t matter what the topic is: if you aren’t crystal clear with your (the BA’s) understanding, ask them to clarify their statement(s). More often than not, the requirements phase of a project moves at light speeds, so it’s important to level-set expectations of understanding the subject matter early and often in order to avoid getting left in the dust. And if you’re worried about losing creditability in the beginning of a project for not knowing the subject in detail, just imagine how much creditability you’ll lose when you get three weeks into requirements gathering sessions and you still don’t know what’s going on. Trust me, I’ve seen it happen and it’s not pretty! In the end, the business SME — or whoever is providing the clarity — would rather provide more clarity on a topic that you asked about than find out you (the BA) did not fully understand it.

Too often, I’ve seen good business analysts lose credibility with a project team because they aren’t willing to admit that they don’t know something. Fearing they will be ridiculed, the BA will play along like they know the subject matter, but when it comes down to crunch time on a project and they aren’t as well versed in something they’ve said they are, then that is when the requirements are at risk of being incomplete, or worse, incorrect. It doesn’t have to be that way! The next time you find yourself sitting in a project meeting or requirements gathering session and you don’t know the answer to a question or don’t know how a business process works, try using one of the tips in this article to assist you with gaining a better, clearer understanding of the subject. In the end, you will thank yourself for being bold enough to put aside your fear of losing credibility and doing what it takes to have a clear, concise understanding of the topic at hand. By doing that, you will have put yourself in the position to produce solid, real and most importantly, accurate requirements.

Don’t forget to leave your comments below.


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 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.