.svg){kind=icon}
.svg){kind=icon}
.svg){kind=icon}
Get your free ebook
Not so long ago, I had the opportunity to exchange a few emails with a worried CTO.
He was looking into outsourcing software development, examining its advantages and risks.
One of his questions in particular caught my eye:
“When your cooperation with a client ends, how do you support them in moving development back in-house?”
A very valid question, indeed!
When all is said and done, your outsourcing business concluded, you don’t want to be left wondering what exactly your code does and what to do with it next. Ideally, moving the development back in-house should be seamless and leave you with a clear path on how to proceed.
With the above in mind, I’d like to share some of STX Next’s experience in that matter.
We’re not new to the outsourcing game. We understand that scaling down or concluding cooperation with an external software house is a natural step for some companies.
It’s not an emotional breakup. There’s no need to be shedding any tears.
That’s why we’ve worked out a number of solutions and practices for optimal knowledge transfer. Here are some of the practices you can use to facilitate the handover process and make it as effortless as possible.
There are two main ways of recognizing when to initiate the handover process:
1. The work is done.
Some projects come with an established end date. It could be that a project only involves creating an MVP, start to finish, and nothing else.
2. The time has come.
Sometimes the time is simply ripe to scale down. That could happen if your in-house recruitment operation starts catching up with your demand for development resources, for example, or if the project transitions from rapid development to stable maintenance.
No matter the circumstances, usually it’s a meeting or video chat that kicks off the handover process.
Every project, every partner, and every cooperation is different. That’s why we use this first conversation to lay out the plan of attack and find out the specific needs for the particular handover.
Depending on the expressed needs, you have a variety of options and tools at your disposal that will make your handover quick and painless.
Treat the list below as you would a delicious, self-serve buffet. You may be tempted to exhaust all of the options, but it could be somewhat overkill. Instead, you can pick and choose whatever suits your needs best.
Sometimes the best way to transfer knowledge is to bring together the people who have the knowledge.
That’s why in some cases we send one of our developers to a client so they can work there for a time, side by side with the in-house developers. That way, our developer is always readily available to the client to answer their questions and share any information necessary on the spot.
In other cases, we invite some of the client’s developers to us instead, so they can learn from our engineers. The work can take on many forms, such as pair programming or reviewing each other’s code.
For optimal results, it’s best if the external and in-house developers spend at least a week working together.
For situations where in-person visits are either not viable or not preferred, remote Q&A sessions are the next best option.
During such a session, our developers discuss the functionalities of what they built, module by module. The presentation is followed by a Q&A, where the client can get answers to any additional questions.
To make the Q&A a lasting point of reference, we make sure to record it and share the recording with the client.
For each session, we invite only the experts that are relevant to the subject matter at hand. What this means in practice is that sessions on backend development will only include backend developers, while frontend developers will attend frontend-related sessions, for example. However, the Product Owner is present at every session to provide the necessary context.
Another variant of the Q&A sessions is to record a video chat where one developer explains the code to another. Again, this can be a series of virtual meetings that go over the codebase module by module.
The main advantage of remote Q&A sessions is that they can be easily organized online, eliminating the need to move anyone out of their usual places of work. It’s especially convenient if the two parties are halfway across the globe, for example.
Documentation is not always crucial while a project is ongoing. The knowledge of how the program works is still fresh in the minds of the people involved, both in-house and within the remote team.
However, when parting ways with a software house, it may be a good practice to ask them to prepare the project documentation for your app. To do this, we can ask one of the developers to spend their last week of work writing down the documentation, for example. Thankfully, the text can be generated automatically to some extent, cutting down on the time needed to present the necessary knowledge.
The practical outcome of this process is usually a wiki that the client can access at their convenience for future reference.
Project documentation can be especially useful for explaining the integration between the app and various APIs used within the project. In some cases, links to the APIs’ documentation will also be provided.
Fortunately, some solutions like the Django REST framework are already thoroughly documented, so the process of producing documentation isn’t as time-consuming as it may sound.
Cutting the cord in one fell swoop isn’t always the optimal option.
When parting ways with a software house, it might be better to finish the cooperation gradually by scaling down to 1-2 people first and having them do maintenance, as well as support knowledge transfer.
For example, if you start a project with ~6 people, you can scale down to 2 people for maintenance during the last month, then scale down to 0 to finish the cooperation.
In some situations, full-time support during the handover can be excessive. We’ve had cases where the need was small and 20 hours of support per month was sufficient. The details of such an arrangement, including the exact number of support hours, can be worked out on an individual basis.
Your software development contract includes a termination period for a reason. We make room for a smooth handover every time we sign a new contract, usually providing a termination period of 2 months.
That means we never end the cooperation abruptly and never ask a client to just fend for themselves. No software house worth their salt should skip the handover if they care even slightly about their reputation. Just imagine the Clutch reviews we’d get if we tried to pull a disappearing act like that.
When you’re creating software, you’re always eager to make progress. “How long will it take?” is a natural question to ask, and the handover process is no exception to this rule.
To give you a short answer, the handover process usually lasts a month or less.
The long answer is, as always, “It depends.” The more complex the system, the longer the handover.
If we’re dealing with a years-long project with complex software architecture, the gradual scaling down and the handover could take up to 6 months.
But for a small MVP that took 3 months to build, recording a few Q&A sessions may prove perfectly adequate. Alternatively, Q&A sessions plus 1 software house developer sticking around for a month to support the project should be more than enough.
The impact of the project scope on the length of the handover process applies both to a full handover as well as scaling down. Scaling down from 3 teams to 1 team with one of our enterprise clients took 4 months, for example.
Honestly, if your software house has an agile approach, they’ll help you work out a custom handover process that’s just right for your needs and the scope of your project.
When your software project is based on Python, you’ll find that the handover process may be faster than for some other languages.
The main reason for this is Python’s clear syntax, which is easy to read and understand, especially when the code changes hands.
Additionally, a competent software house will have worked out coding standards that improve the clarity even further. With concrete and uniform standards in place, you should be able to look at the code provided by multiple development teams and find common elements that make it easy to comprehend.
Working with a software house, it is wise to begin with the end in mind. That’s why I’m glad you took the time to think two steps ahead and explore your options for a successful software project handover.
To summarize your options, remember that you can always ask your software house to:
As I’ve said before, you probably won’t have to exhaust all the options listed above to transfer the desired knowledge. But now that you are aware of the possible steps in the process, you can identify the ones that best fit your needs to ensure a seamless transition.
Thanks for reading! It was great to be able to address this concern on our blog. And to think it all started with a few short emails exchanged with a CTO in need…
Special thanks go to Michał Kwiatkowski for working with me on this article as the subject matter expert.
If you have more questions related to software projects that we could answer on the blog, don’t hesitate to leave a comment below or reach out to us directly!
Alternatively, we encourage you to learn all the ins and outs of software development outsourcing or get up to speed on software development nearshoring.
