If you are offered a role as a software business analyst (BA) to look after software/products/projects (let’s call them products for future use) in maintenance mode, don’t freak out. Why would you freak out? Because someone would tell you that the best thing to be is a BA for a project which is about to start or is in motion — not a product which is implemented, go-live done, champagne bottles popped and currently in maintenance. What's the glory in that?
OK, let’s clear some confusion first. Maintenance means looking after a product while it is earning you money, while it is being used by actual users, while it is facing the test of users trying all the straightforward and alternate scenarios, and while it is being run through real performance tests. So it is pretty damn important. You need a smart BA, with good customer handling skills and sometimes with good fire-fighting skills to deal with the role.
The role gets a bad rep because some people are stuck in pretty stable maintenance roles, where not much is happening, and you are dealing mostly with reports, running scripts and tackling pesky bugs.
So, whether the role is good or bad by itself depends on the kind of product you are working on. One of my colleagues was playing this role (BA and facilitator) for a product which was widely used and mature but still undergoing complex enhancements. Here are some of my observations watching him excel in that role:
You need to be good at fire-fighting
Tackling production bugs is not for the faint-hearted. There is immense pressure because that bug might be hindering critical business. You need to react quickly, prioritize bugs relentlessly so as to not get swamped, and suggest quick workarounds. And for this, you need to know the product inside out. And for a maintenance BA, this happens more frequently than you think.
You need to fight with managers for getting people
Very often, I would see that the team was understaffed because of budget reasons. One should make it a point to highlight this particular bandwidth issue so that the bugs are actually fixed and not just keep moving target dates. In some organizations, you may have adequate staff, but not enough people who know everything related to the product. It becomes your job to disseminate the domain and product knowledge to fellow developers and testers.
You need to make sure any changes are going back to the specs
If there is a change being done in the product due to a production issue, that should be documented and put in the relevant specs. The traceability has to be maintained. The product specs should always reflect the latest snapshot and for that all small/big changes coming out of maintenance have to go back into them. Now this is something that can easily be neglected by feature teams who are always working on newer functionalities. You need to make sure to stress the importance of having all the defects resolution documented.
You need to ask for relevant handovers for the new features being built
Anything new that is built into the product has to be explained thoroughly to the maintenance team — including handing over of specs, test cases, etc. This should be non-negotiable.
You need to be good at reporting
The number of new issues solved, the turnaround time, etc., should be reported to all levels of management in frequent cadences. One, it gives you visibility, and two, it gives the management a perspective into the stability of the product. So dashboards, charts, effort estimations and all that jazz are pretty important.
You need to be good at root-cause analysis
It goes without saying that things happening in production require a root-cause analysis. Why did it happen and how can you prevent it? If you are a BA in a maintenance team, those meetings will happen a lot. You need to be good at presenting facts, dissecting root-causes and coming up with improved processes.
You need to pacify clients
If something big breaks, you might be the one dealing with angry clients (and their lost business). If you have built trusting relationships with them, it would be easier to convince them to take some workarounds till the problem gets solved. With good communication skills, it would be easier to buy time from them and make sure things are not escalated beyond control.
In the end, the risks are actually higher in these sorts of roles (or at least you want it to be like that). So staying in these roles for a good amount of time gives you a unique set of BA skills. It is not as easy as it sounds.
Author: Pushkar Anand, Business Analyst
Pushkar Anand has been working in the role of business analysis for over 12 years and is specialized in air cargo operations, hospitality, and digital marketing. Has experience working with some of the biggest airlines in the world and some of the biggest players in the hospitality industry. He is passionate about discovering the newer aspects of business analysis and domains and sharing that with the business analysis community.