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. Fearing 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 (10 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 successfully handle the situation described above. 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 interworking’s 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 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 project.
· Next, create a partnership with the Business SME (or wherever the knowledge is). While its 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 one’s 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, more clear 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.
Author: Josh Jones, Senior Business Analyst