Why do some hiring managers need that? They have relied on that one person to work on that application and with the customer base far too long. Why do they do that? A big reason is that the customer gets comfortable with a particular individual and they do not like change. So as long as the person they love does not want to pursue other opportunities they will stay there until they leave the company due to a staff reduction or reach retirement age.
This particular post will not address the ways a BA manager can help spread the knowledge to avoid this situation. An earlier blog post, The Sadness of the Silo'd BA, touched on this subject. This post will focus on what the new BA who is replacing the long established BA should focus on to be most effective. Until organizations start pairing BAs, BAs will be in silos and will continue to be the only ones with certain knowledge. Coming onto a new project team, a Business Analyst needs to obtain as much information from the departing BA as possible. If you are the incoming BA there is so much information you need that it often feels like you are drinking from a fire hose. You have limited time with the outgoing BA, so you have to prioritize the topics you cover.
Conventional wisdom may lead you to believe the main priority should be the application(s). That in fact should be the lowest priority. Yes, you need to learn the features of the application and as much about the application as possible, especially if you are also responsible for production support. But there are other team members that often have knowledge about the application. QA Analysts and developers have in-depth knowledge of the application, so use them for support until you have had time to get caught up on the application.
Your top priority should be focusing on the stakeholder(s) who may be most upset about a new BA coming onto the project. Have the departing BA schedule time with those stakeholders to personally introduce you one-on-one. It is in your best interest to make these stakeholders feel comfortable. Ask them what you can do to make the transition easiest on them. The reality is that the departing BA is departing. The stakeholder may be upset, but if you ask for their input on making the transition smooth you are taking the first step in winning them over.
Next, get the departing BA to give you a brain dump on how all the stakeholders like to communicate. Which ones like formal meetings and which ones prefer hallway conversations? Get a list of those that like formal documentation and those that do not require formality. Understand what communication medium the stakeholders prefer; email, text, phone, face to face, etc. What stakeholders are usually positive on projects, which ones bring conflict? Are there stakeholders that don't get along? Are there stakeholders that dominate meetings? I think you get the gist of where I am going.
The BA who is departing understands and subconsciously considers all these factors when interacting with each individual stakeholder. That's why they love him/her. Since it has become second nature for the departing BA, it may not be easy for them to think of the answers to your questions.
The easier thing for the departing BA is to give you a demo of the application. Fight the urge to allow that to happen unless you have the time - after the analysis of the stakeholder(s) has been completed.
My one warning on the subject is to validate what you have been told. We all have biases and the departing BA may bring theirs when answering these questions. Take into consideration what you have been told - but make your own final judgment as you interact with these individuals.
All the best,
Don't forget to leave your comments below.