August 8, 2020

Lessons Learnt / Best Practices for a Business Analyst- BA’s

There is an old saying, which I guess everyone must have heard it before. The saying is “Learn from your mistakes”. Never knew that this saying which I heard from my grandma will be an important part of my project management and business analyst career. On the other side PMBOK actually clearly specifies it as a best practice. PMBOK says to document the lessons learnt for each project and make it accessible to other project managers as well for future use. So I am following the code of PMBOK and  writing all the things that I have learnt in my career as a business analyst, developer and a project manager. You can call them as lessons learnt or best practices, but I prefer to call them lessons learnt as these things I have learnt on my own as I am not as smart as CHUCK NORRIS.

Lessons learnt as a business analyst

1.) Understand the business/ Industry of the client – It is very important for you know what industry/business your client is working in. Do your HOMEWORK before you set-up a meeting with the client. Having knowledge of the client’s business/industry, this will give you an upper hand and help you gain confidence of the client. Also try to find the client’s competitors, see how are they growing or what technology they are using.

2.) Be patient – The client’s words could sound ALIEN to you. If you have done your homework then you could overcome this situation. If you hear such a word try to see if you can use your smart gadgets quickly enough to dig it up before the client realizes that you are trying to look it up. Doing it smartly is very important.  One of the words that I have heard during one of the elicitation sessions is “INFORMATION MEMORANDUM”. Go figure that out yourself 🙂

3.) Record/Document your conversation – That’s one of the most important things you should do. Record each conversation whether it’s a phone call, skype, hangout, citrix or a one to one meeting. Also keep track of every e-mail exchanged, personally I group them in folders in OUTLOOK. If you don’t do that then it might bite you back and the after-effects could be bad. The client can easily say “ I DIDN’T SAY THAT AND YOU GOT IT COMPLETELY WRONG” . You can save yourself from such a situation only if you have a proves of your conversations with clients.

In north America it is very important  that you let your clients know before the conversation begins that you are recording the conversation (If not then you could be landing up in legal trouble) . In other parts of the world it may not be necessary but it’s a courtesy to let the other party know that the conversation is being recorded. If the client is a bit hesitant you can convince him that it’s just for the notes and better understanding of the needs you are recording it.

4.) Document Clear, Concise and Accurate – Make a clear documentation, keep it concise and accurate.There should be no redundant information. Redundant information can confuse developers.

5.) Implement Change request Procedure– To avoid scope creep implementing this step is very important. You can also read my blog post on SCOPE-CREEP as well.

6.) DON’T be OVER-TECHNICAL – This is very important, 99 percent of the time of all your client meetings will be with people who have close to none technical knowledge, except for clients aiming at affiliate business (check our payday affiliate loan offer – the example of a clear working scheme). Avoid using technical jargos, use functional/business terms. If you speak technical then it will not be making no sense to them and they might loose interest which in turn would hamper the elicitation process. If you are talking about memory allocation of java as compared to their existing leaky ASP.NET application then it might not make sense to them. THEY JUST WANT TO GET THE WORK DONE NOT HOW THE WORK IS DONE.

7.) Powermap and Stakeholder Matrix – Create a stakeholder matrix for the client ( I will be writing up a post on this as well). There will be many people in the organization with whom you are going to spend time with to know what they want out of the software. They might be high in the organization or just john doe from the sales department whose opinion doesn’t weigh much. So you have to be careful in identifying what features, requirements is required by whom and how does his opinion matters and also how it will affect the cost and risk of the project.

8.) Keep everyone in LOOP– It is very important to keep everyone in the loop.  The best way is to use an e-mail list or group for every e-mail communication. You can use tools like collaborate, sharepoint or basecamp as well. There have been several occasions where few of the stakeholders didn’t knew that few of the requirements changed in last few days. The problem with this technique is that volume of e-mails could be very high. They might start complaining about getting huge number of e-mails every day, so prefer to educate them about using folders and rules in outlook or if you are using collaboration software then they can received all the daily update in a single e-mail.

9.) NON-COOPERATIVE STAKEHOLDERs – This is very common situation for every business analyst. There will always be an odd person that will give you hard time providing all the information that you need. He might be high in the stakeholder matrix as well. Your first approach should be personal meeting and then e-mails. If you are storing e-mails then you are on the safe side.  If I you are getting frequent busy replies then the next step  I tend to use is my e-mail group list. This technique has never disappointed me and acted as the silver bullet. I write a very soft and professional  stating progress of the project and what is the current status of the project. In the end mention the things that are left from the client side and request for details or appointment from that non-cooperative stakeholder. You will see the information you requested or a meeting request in your inbox shortly.

This has always worked like a silver bullet.

10.) ALICE IN WONDERLAND – As a business analyst you have to know this, you are not in a wonderland and everything you promise cannot be delivered or its not easy to deliver. Don’t make fake promises to client. If you are unclear about something whether it is achievable or not discuss it with your team first. Discuss risks, cost and challenges involved with it.

11.)GLOSSARY – Maintain a glossary of terms used by clients or what is used in their specific industry, its also nice to pass that list to the project manager or the development team.

12.) Reiterate – Go through with the client all the requirements that you have collected.Explain him the process how you have mapped it for him. Use some visual tools. Its better to reiterate again before freezing the scope/project charter.

13.)Monitor – Although its not your duty to monitor the project but you are the face of the company to the client. If something goes sideways then you will always be questioned by the client first. So its better you monitor the progress of the project yourself . Make sure that you are on the RACI matrix (read my post here on RACI Matrix).

These points are high level overview of my experiences. This does not imply that they might be the best practices for you. They documents is just quick points to remember. The list is missing all the best documents, best practices mentioned by ITIL, PMBOK and BABOK. I guess they were not necessary to be mentioned here. Please share your experience in comments.

Akash Deep Singh

|| Eat Packets || Drink Management || Sleep Virtual || Work Linux || Think I.T. || Love MAC || Look After Windows || Dream APPS ||

View all posts by Akash Deep Singh →

Leave a Reply

Your email address will not be published. Required fields are marked *