Transferring an Existing Software Product to a New Team – a Checklist

Sometimes, in the lifecycle of a software product, comes a time when it needs to be transferred to a new team within the company. Reasons vary. Most often they have some financial nuance on the surface, but their nature is always strategic. No matter the reason, these transfers often mean moving the product through whole continents, time zones, offices, cultures and processes.

Being a hands-on participant in multiple software product transfers to date, I’ve seen approaches and ideas that worked great and of course, some that failed. I had the chance to learn by observing the art of pulling off successful product transfers in completely different settings – of legacy products, of newer products, of products we got from teams that ceased to exist, and also from teams that continued within the company long after the product transfer had ended. 

Working at a dynamically growing business in Bulgaria, I have mostly seen how this works from the position of the receiving entity. That being said, a transfer is always a joint venture and I believe sharing my thoughts could help you, even if you’re on the other side of the project.

Now, as a last quick disclaimer before I start… Managing a software product transfer is classic change management project, so all change and project management techniques still apply, but there are some specifics and tips that you’ll be better-off considering in advance, than learning about them the hard way (as I did on numerous occasions in the past). So, things like having a plan, tracking and reporting on it, managing risks, stakeholders and commitments, etc. go without saying and intentionally won’t be a part of this checklist. Keep in mind, that it still does not cover all the peculiarities you will need consider at 100%, so please, use it just as an additional sanity check of your existing plan so you can improve your chances of success. 

So, let’s get down to business! What worked for me so far? This is my product transfer checklist:

Understand the product state and its future vision

Product maturity and its current state in the product lifecycle are important things to note in the very beginning. Is this a product that is developing rapidly or is it in maintenance mode? Does it have room to grow or is it the current Cash-cow of the company? Is innovation and growth expected, or the goal is to transfer and just  reach business-as-usual state? The answers to all these questions will affect your hiring decisions, who you decide to put on the team and the project, and how you package and sell the idea to the team – the people who will ultimately be responsible to care for it and develop it. 

Every product goes more or less through the same lifecycle. Which state is your product in?

Do not forget to also discuss the product with the current product owner or manager. See what their vision for the future is and act accordingly.

Do some due diligence

Assessing the current state of the product is crucial for the success of the initiative, so if possible, be sure to settle at least one, (preferably) very senior person in the existing team for a while, so they can see things first-hand and give you a good view of what you’re all getting into.

Ask your “spies” to focus on understanding the business domain pain points, the state of the code base and coverage of testing, the automation and the toolset that are currently in use. Transferring a product is a serious endeavor, so it is not a good idea to only rely on rumors and papers. If sending over a person is not viable, try gaining access to current documentation and code in advance and start exploring locally.

Dramatic reenactment of classic due diligence

Secure crucial resources and clarify constraints advance

After an assessment is done, it’s important that you make sure you have all resources you’ll need are available. See what the structure and headcount of the former team were, see what their budgets amounted to. Compare these to the budget you have and your projected labor (this one is probably going to be about 80%-90% of the overall cost), IT, office, training and travel costs. See if it all looks realistic. Make sure you go over all other constraints and expectations in the very beginning – what is the deadline of the project, what are the main goals and milestones? Put all these into your plan.

Another point that’s important is that you must find the available office space to accommodate the new team and you need to order the hardware and software they will use early enough.

To be on the safe side, it is a good idea to develop a contingency plan and try to secure additional budget to cater for risks that are very hard to control. For example, you might need to get expensive contractors on board for a while, due to stagnation on the market and inability to recruit just the right talent soon enough. This plan will give you options in case something goes really wrong.

See what functions you get to own

Owning all of the supporting functions in addition to development – like administration, delivery or customer support, brings benefits in terms of simplified communication and better synchronization between functions.

That being said, it also comes with a much greater deal of responsibility and might put you in a position to own something you do not have the expertise to deal with. So, stop and consider carefully what exactly you’re going to own.

See if key roles are local and/or available

See if roles are well positioned and thought-out and would not put you in a position of difficult and cumbersome communication across timezones. Understand if the Product Owner, the Scrum Master and Line Manager are going to be local and try to secure this as it is going to make life so much easier for everyone.

If any of this is not viable, at least make sure all key people are easy enough to reach and are reasonably available when the team needs their help or input.

Partner with HR 

If you’re going to be transferring a product, it’s highly likely that you’ll need to recruit a bunch of new people. This cannot happen overnight and Talent Acquisition is your most important partner in creating a market forecast and supporting your efforts for recruitment. You must discuss your plan with them and also consider alternatives like getting some contractors on board for a while if things are not looking pretty. 

Remember that labor market is cyclical, and there are many socio-economic events that affect it. You cannot hope to know what’s around the corner at all times. No one understands market conditions better than TA specialists, so go and leverage their precious knowledge.

Rely on existing talent

Letting everyone from the former team leave, often proves to be an overlooked ticking bomb. See if you can arrange key people from the former team to stay with the company. It will be best, if you can engage them with your new team, but if this is not possible, hopefully there will be an alternative position that can still keep them around. It could be a new product, a more interesting role or something else, but it is crucial that you have someone to rely on, while the new team is picking up speed but is not yet fully productive and aware of all the details. Such key people can prove invaluable when new members of the team need some advice and, even more so, in the event a critical system failure happens. Make sure you have at least a part of their time officially dedicated to the team until they are ready to own the product by themselves.

Another thing that worked for me has been bringing trusted people I’ve already worked with on the team. It is often better to move someone from your existing seniors to help building the new team. This provides an opportunity for the seniors to build new knowledge and leadership skills and is often appreciated on their end. On the other hand, it will enable cross-pollination. Processes and culture will grow from within the team, because you already have someone who knows how it all works and can be on the lookout for any deviations.

Simplify the transfer by ensuring the product is in a fit state and is well-documented

Ask the former team to not leave anything hanging out the trunk at the last minute. Make sure there is enough and well-updated documentation. See if enough tests are in place for the team to use as a safety net – these are going to keep your back time and time again. See if any simplifications of environment and deployment processes can be done and also see if all environments are well-documented.

Help your team know their progress and give them a sense of accomplishment

It is a good idea to have a tailored schedule available for all knowledge transfer events and milestones. Thus, your team will know what’s next and they may ask for more things to be added to the plan, some topics to be extended or removed. 

Knowledge transfer sessions are best to be recorded on video as most people won’t pick all the details on the spot. I’ve seen team members resort to available recordings from time to time. Remember that you cannot hire all members of the team at once, so these recordings also make for great entry-level trainings when you onboard new people.

You can help the team immensely if you do a stakeholder identification exercise together. This will help them understand their role and they will be much better prepared to work with all the stakeholders involved and manage their expectations.

Last, but not least – create a Team Competency Matrix that lists all key knowledge areas to be covered (might be product components, technologies or software tools). This has proven to be an invaluable tool and it is also a variation of the Management 3.0 practice.

Here’s how it works: first, ask the former team to assess their level of knowledge on a scale together. For example, 0 being novice, 5 being subject matter expert, or use the scale that Management 3.0 proposes. Thus you will know what is possible to achieve and you can establish a sane goal to aim for and compare to.

Then, regularly update the matrix for the members of the new team and ask them to set competency goals for the next period each time. In our case, we’ve been doing this monthly, and we often continued well after the end of the knowledge transfer because we’ve been finding it so useful.

How a Team Competency Matrix might look

The Team Competency Matrix will:

  • Keep people on track to understand and learn about all aspects of the product in a methodical manner ;
  • Demonstrate individual knowledge gaps, so the every team member can address them to balance their competencies;
  • Show the team their overall knowledge distribution, so they know where major risks lie and what to put more focus on next;
  • Create an environment of constructive competition that pushes everyone forward;
  • Give the team sense of accomplishment and progress, which will help keep their spirit high. This is especially important at the beginning, when there are often no other significant and tangible results.

In Conclusion

This turned out lengthier than I anticipated and I’m still sure that I haven’t covered everything.

A software product transfer is a wild journey and you’ll probably stumble upon different challenges each time.

You’ll need to walk the walk yourselves, but I’ll be very happy to know I’ve helped at least some of you by sharing these practices and ideas.

Feel free to leave a comment and share your experiences in the field which shows up when you view a single article!

You may subscribe to the RSS feed, and you can also leave your email address, so I can keep you posted (occasionally and responsibly) with more interesting content and news.

Share with others

One thought on “Transferring an Existing Software Product to a New Team – a Checklist”

  1. Thank you very, we are the middle of a Web Application transfer and vendor is just not happy

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.