Software handovers between teams and individuals in any ecosystem can be a minefield, often threatening to disrupt continuity and harmony across teams and organizations. In most cases, handovers result in knowledge loss, which in turn leads to chaos and time wastage when a critical issue hits the system. As a business analyst (BA), you will invariably be a part of the process, both at a junior and senior level. It is better to be fully aware of the complexities and pitfalls associated with taking part in a handover. You’ll eventually be able to apply some best practices to navigate around it (some of mine i hope and some of yours based on your context and area of operation).
Now, a lot of problems i talk about would not generally happen in a perfect world. Correct guidelines, collaborative teams, proper managers and you would not see the problems talked about in this story. However the world is not always collaborative and correct. People are not always pulling in the same directions due to issues beyond capability and processes.
Let me first explain some real-world scenarios that come under the term ‘software handovers’:
A team was handling a critical module in enterprise software for a number of years. The team was being disbanded and transferred to a new division. Another team in the same organization, working on the same enterprise software, was asked to take charge of the module.
Development of a product is shared between two sites (across countries). Management has decided to transfer control of some components from one site to the other.
A stable product was running in low-bandwidth maintenance mode for a year, managed by a developer and a BA. No new features were introduced due to lack of budget. In the new financial year, budget was allocated for the product and a new team was assembled. The new BA had to take handover from the current BA.
IT vendor A is transferring knowledge of an entire product including multiple components (catering to a customer) to IT vendor B. This was done as its contract with the customer was coming to an end.
In my experience as a business analyst and a product owner (PO), more often than not a handover has turned out to be a major headache. Some of the complaints I have often heard from BAs (including myself) are:
From the BA receiving the handover:
- The functional documentation is not clear to me. There is a lot of reverse-engineering effort required to understand the modules.
- The handover sessions given to us were very high level.
- No handover sessions were given to us (yes, it happens). The module was just transferred to us.
- I cannot take in a new change request immediately after handover, or at least until I know about all the impacts it can cause.
- There are a lot of defects associated with the product. I have to analyze them fully before I can accept the handover.
From the BA giving the handover:
- I do not know the entire module myself, as it was hastily transferred to me a while back. I am just maintaining it.
- I do not have the approved bandwidth to give elaborate sessions.
- Why are we even transferring the module?
- I have forgotten quite a lot about the module, as it was in a dormant state for quite a long period.
Under these circumstances, the role of the BA receiving the handover becomes very important in driving the handover process. I would suggest looking out for the following points to better manage a handover.
1. Prepare a checklist of things to ask before you go to handover sessions
Always have a checklist prepared for the documents and items that you expect from an acceptable handover and share it with all stakeholders before the handover starts. The checklist should contain:
- Business requirement documents, functional specifications, API specs, mapping documents, glossary documents, etc. (basically any kind of specs).
- Names of all the functional stakeholders associated with the module.
- Change requests implemented in last “N” months. Future backlog with the team. Existing defect list (to be of primary interest to the QA team, so work with them).
- The interactions of the module being handed over with other modules.
- Recurring BA tasks for the module. Any reports generated weekly/monthly out of the module.
- Any major customer complaints/issues which originate from the transferred module.
- Any compliance issues to be covered in the future.
2. Ask for access to the document repository even before the handover sessions and assess it for clarity
Request all documents well before the handover process starts. This should give you a chance to read them, understand them and get an idea about the coverage of the specifications.
3. Highlight handover issues with your management upfront
If there are any issues during the handover — such as lack of proper sessions, lack of proper documentation, or compliance issues with the product — make sure management knows about them. They should not have expectations from you to start on a new feature or a change request immediately after the handover. At times, if the knowledge transfer is really not up to the mark, make your management aware of all the risks it could pose.
4. Advise development on the transferred software only when there is full understanding of the impacts
Assess and advise the management and development teams if new development can be taken up for the product. As a BA, you would be in the best possible position to understand the risks and impacts of creating and understanding a new solution. You would also know the current defects associated with the product and complexities surrounding them.
5. Develop a small enhancement just after the handover
If the handover has ended as per your satisfaction, see if you can jointly develop a small enhancement of the product. As a BA, this would give you the chance to understand the module better. Helping it get deployed all the way through the process through production will give you an idea about the entire lifecycle of changes.
6. Ask the team handing over the module to commit some bandwidth even after the transfer
Make sure you ask for some bandwidth from the team transferring the module. It will be catastrophic if you have a production issue and suddenly you have nobody to turn to for functional input.
7. Maintain good relationships with everyone on the transferring team
As always, it helps a lot if you develop a good working relationship with your BA counterparts and all the other members of the transferring team. This will go a long way in bailing you out when you are stuck with an issue in the transferred module. Understand their limitations, but ensure that everyone understands that a smooth handover is in the interest of everyone.
Handovers are actually quite frequent in software service companies and it makes sense for a BA to have the right strategy and approach to them. Running a smooth handover process from a functional standpoint with a smart process ensures continuity of knowledge.
You, as a BA should take the lead in such activities and take it to its appropriate conclusion. Managing it while tackling the problems mentioned above would establish your chops as someone who can take charge of situations and overcome operational issues. Someone who the management can rely on to be responsible for future handovers.
Do you have any interesting stories of handovers you’d like to share?
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.