CEO and founder of SolveIt—a mobile development company, entrepreneur and product owner of HBT.
“After us, the deluge”—is the last thing any product owner, СEO or founder expects to hear from their software provider, especially when it comes to transferring the project to another vendor.
Approximately one in four companies opt for third-party services for their software development projects. However, only 17.8% of them report being completely satisfied with the work delivered. The remaining companies either compromise on their initial vision or deal with the consequences of their choice of partner. Of course, we shouldn’t seize the head: The word completely indicates that the best is the enemy of good.
However, for the last three years, I have been witnessing the same concerning trend: About one out of every three customers seeks development services not from the ground up but rather for project rescue purposes. That’s why it’s crucial to remind your partner about the significance of preserving the project’s alienability, even when anticipating a long-term collaboration with the team. In fact, what’s truly alarming is not the mistake itself but rather how the vendor deals with it, so we won’t dwell on the signs that you have to make a transition.
Houston, We Don’t Have A Problem Anymore
Even though this transitional period involves detailed planning and coordination with all project stakeholders, in my opinion, it is much more important to understand what we want to achieve from a short-term perspective so that the conversation about the long-term prospects can have any right to exist.
Four main criteria for a successful project handover, which should become the objectives of this process, indicate you’re on the right track by providing:
• Quick knowledge exchange between teams.
• Efficient onboarding for the new vendor.
• Fast project launch and development by the new team.
• Possibility of continuous project work.
Therefore, all your subsequent actions should firmly align with one of them. If that’s not the case, ask yourself: Why are we doing this, and is this measure necessary right at this stage?
Bottlenecks To Be Prepared For
When you decide to switch suppliers, it often indicates that you have encountered a challenging situation and it’s time to prioritize your own well-being and interests.
While significant attention is typically given to aspects such as evaluation, selection and contracting with a new outsourcing provider, in reality, transitioning itself can pose significant risks.
1. Poor quality of service after notifying the termination of the contract.
We are all familiar with this scenario: Once you announce your intention to end the partnership, the vendor removes you from their priority list, thereby jeopardizing either the project’s deliverables or the project’s deadlines. Indeed, the contractor may lack motivation to continue delivering the same level of quality—well, maybe that’s precisely why you’re replacing them.
What can be done: If reaching an agreement by clarifying expectations and setting clear timelines on paper proves challenging, it is prudent at least to minimize risks in the most critical business processes. In addition, the app will need to be tested; the time invested will be worth it, I promise.
2. You’ll find yourself caught between two fires.
While we all hope for good business conduct, it’s more common to see projects transition from the previous vendor to the client and then to a new team rather than between two of them collaborating. And it’s okay unless specified otherwise.
What can be done: Simplify the communication chain by selecting a single appropriate channel. Consider creating a knowledge base in your project management system during the transition phase, recording meetings and dividing the process into iterations. Yes, get prepared to be here and there at the same time!
3. Handling confidential information and ownership issues.
I won’t remind you that any collaboration should start with non-disclosure agreements. Let’s be realistic: You won’t be able to verify or prove that the development expertise gained from your project isn’t being utilized in the others. Achieving complete detachment from the source code is practically impossible in real life. However, in the project context, it is feasible.
What can be done: Make sure to get all project artifacts (documentation, design kit, a full copy of the code, Apple/Google Play developer accounts, third-party services, changelog, etc.) in the repository. And don’t forget about the credentials—valid, controlled and unchangeable.
Final Words
In the outsourcing market, a vast array of services are available, spanning various levels of expertise and price segments, and it’s fantastic! The push comes to shove when there is no understanding of what you are looking for, what your goal is and how much you are willing to invest in it.
To rescue a project from the abyss, your new partner requires your time and attention. As the product owner, you bear the responsibility for its success. This entails setting goals, prioritizing features and maintaining regular communication.
Typically, the normalization period in such a challenging transition process takes no longer than a month. While this endeavor will undoubtedly demand effort, there is no guarantee of increased budget or scope. Everything depends on the initial issues and subsequent actions taken. If you make the right choice for the new partner, you will ultimately receive a released application.
And, in the end, congratulations, you have successfully changed the app provider!
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
