An old saying goes, “Better the devil you know than the devil you don’t know.” But when it comes to your business, sometimes sticking with a vendor who is not performing as expected might be costly and dangerous.
Regardless of what compels you to consider changing your software development outsourcing vendor, one thing that stops many companies from making the switch is the belief that it is expensive and complicated. But the reality is that it is easier than you believe. In this article, we will point out the simple steps for switching, discuss what should be done before the transition, and explore a few examples from past cases we’ve had here at BairesDev.
Why Would I Change Vendors?
Most people engage in a business relationship with a vendor expecting them to fulfill their part of the bargain without having any problems. “Unfortunately, that won’t always be the case,” says Andy Horvitz, Senior Vice President of Client Engagement at BairesDev. “Typically, companies are exploring alternatives because there is a problem. . You are not going to make this transition because things are going well. The good news is that we can help; we can help bring discipline to the clients’ software development life cycle (SDLC) and their processes.”
You would want to change your current outsourcing vendors for many reasons. Better time zone alignment, lack of expertise in a technology you want to get involved with, price, inability to meet the deadlines for fulfilling orders or a simple change of direction from within the leadership from either the client or the outsourcing supplier — there are infinite reasons why you might want to look elsewhere.
To cite an example, at BairesDev, we’ve had a few cases where a client decided to change their vendor because of the war in Ukraine. The clients had their outsourcing vendors in Eastern Europe. Due to the current geopolitical situation, they could no longer continue doing business with that company, so they came to us.
How to Do It
If you decide to change your outsourcing vendor, you must take many considerations. We have written at length about how to choose a software outsourcing vendor in the blog, so we will skip that part of the process and assume you already selected a vendor. What follows will be a kickoff call or meeting where the following phases will be clearly mapped out.
Let’s dive into those phases:
Pre-Discovery
Once you have decided and negotiated with a different company, the first step is to embark on a pre-discovery phase, where you must provide the following:
- Access to code repositories (credentials active)
- Access to management tools (wiki, ticketing system)
- Available documentation from internal team members and current provider
- Definition of tech stacks (current use and future state, if they differ)
- Historical incident data
- Architecture diagram
- Testing approach
- Access to the cloud solution console of a secure environment (credentials active as the viewer)
- Access to the web and both mobile applications (credentials active)
Discovery Phase
This phase is where the real engagement begins. The new company will assign a core team of technical leaders, developers, and supporting Scrum team roles to lead this phase. Some team members will spend time with the client onsite and continue the rest of the stage remotely.
The objective of this phase is to:
- Construct a risk matrix with a mitigation plan for each goal.
- Secure the client’s operations without dependency upon the current vendor.
- Analyze, test, and document the current state of the applications.
- Propose improvement over the current tech stack and platforms.
- Define a reliable incident management plan.
- Accelerate the deployment process to scale up the product team.
- Implement IT governance on all the goals mentioned above.
- Define and agree upon success metrics.
This phase is further divided into smaller sub-phases, which are:
Definitions and Requirements
This phase consists of reviewing all the documentation gathered during the pre-discovery phase to obtain critical decision-making criteria from stakeholders. Include feature requirements, user scenarios, success criteria, goals, etc.
Here we also have the environment setup, which includes granting access, creating a dev environment, and testing local deployment. The archeological review also happens here, which means reviewing the current state of the infrastructure, CI/CD pipeline, workflow, QA, systems, and data.
“The archeology phase, in simple terms, is an investigation of the current state of the software, infrastructure, governance, processes, documentation, and more,” says Horvitz. “It involves answering questions like ‘Do they have effective repos?’ ‘Is the cloud infrastructure up to date?’ ‘Can it be handed off easily?’ ‘What is the level and quality of the documentation?’ ‘Is it in English, Spanish, or another language like Russian?’ ‘What is the complexity and scale of the application?’ ‘How easy would it be for us or anyone to take the reins given the facts on the ground?’”
Solution Scenarios
During this stage of the discovery process, we want to outline potential solutions for each goal/feature set based on the definitions and requirements sub-phase, especially during the archeological review.
Once we have outlined the goals, we can then proceed with the analysis for the prioritization and solution selection, establishing what goals should be attained first and how to complete them.
Backlog Definition & Prioritization
Here, we have to fill the backlog with several weeks of activities. The number of weeks varies depending on the project.
Once the backlog has been filled and we’ve gathered all the findings from the archeological review, we can begin with the initial prioritization of the backlog to determine critical milestones and timelines.
Build and Test New CI/CD Pipeline
Building and testing continuous integration/continuous delivery pipelines to deploy the solution is essential.
Justice Erolin, Chief Technology Officer at BairesDev, says, “You want to be able to test as you develop. Gone are the days of testing at the very end of what we call waterfall, where you design, develop, then test. So, start your testing process as early as possible. That way, you can automate many testing procedures but catch mistakes faster. And the sooner you catch them, the less likely it is to have a ripple effect across the software.”
Documentation Review and Approval
This is the last part of the discovery phase. Here, the client and the vendor review the minimum viable product (MVP) solution scenarios for final approval and kickoff.
Governance Implementation Phase
Governance in software development provides a structure for aligning development strategies with the overall business strategy, using a formal framework that enables them to track and measure performance against specific strategic goals. In other words, it is establishing goals and determining which key performance indicators will be used to determine whether or not the goals have been achieved.
The governance team will be closely involved onsite and in the day-to-day. The team comprises four roles:
- Delivery Manager. Acts as the bridge between the policies, corporate methods, continuous improvement, and the project management office (PMO) team to optimize the usage of best practices and mitigate/anticipate risks in our groups. They will serve as the client’s escalation point of contact in any delivery matters.
- Project Manager. Responsible for ensuring the team’s welfare and compliance with delivery times and project quality.
- Technical Manager. Ensures technical skills and team composition for each engagement, providing subject matter expertise and deep industry knowledge as added value. They will provide their expertise and assistance throughout every step of the engagement’s life cycle. They’re also involved with other areas like delivery and staffing.
- Account Director. Acts as a strategic partner focusing on long-term partnerships and is ultimately responsible for fulfilling capacity/staffing needs. They drive any commercial and contract discussions.
“Generate a governance structure and artifacts to exchange information and validate the health of the project, initiatives, or the current infrastructure,” says Horvitz as one of his success tips. After this third phase, the team is ready to continue where the previous vendor left off.
The duration of this process is not fixed. “It depends on the size of the migration,” says Guillermo Carreras, Head of Agile & Digital Transformation at BairesDev. “It is not the same to migrate a single application as it is to migrate an entire data center or a data center with a CRM, an ERP, and two mobile apps. Also, there is the complexity of migrating from an on-premise data center to the cloud.”
What Should You Do Before the Switch?
There are some things a company should do before starting the transition process.
“In these transitions, we first need to understand a bit about the current state of the existing vendor relationship”,“ says Horvitz. “We ask questions like ‘Is the current relationship amicable?’ ‘Does the client have the keys to the infrastructure?’ ‘How do we expect the current partner to respond if they learn that the client is exploring or commencing a relationship with a competitor, and could the relationship turn hostile?’ Understanding these key details helps us to manage and mitigate risks, and to ensure a smooth transition.”
The most important thing is to have the keys and access passwords to all of your development repositories. “If you don’t have the code, you need to rebuild that,” says Carreras. “That has happened before. We needed to reverse-engineer to rebuild the entire code.”
But there are ways of preventing having to do that. “Keep track of whatever you are developing, make sure that the documents are updated, that you have processes for whatever you are doing in a production environment, make sure that the organization is knowledgeable enough in case they have to act quickly in an emergency,” adds Carreras.
Key Considerations
Some clients might fear the change because they believe it leads to “breaking the code” or that changing the vendor will further complicate the code. But that is not what happens. “In most contracts, there is a clause in the contract that includes costs in case there is any damage or liability,” says Carreras. “There are a lot of penalties that might be applied.”
Remember that there will be a period when the company will have to keep the two vendors. “There is always going to be a transition period,” comments Horvitz. “You can’t turn off one before turning on the other.”
“One approach is to get the new vendor as a support team while the previous vendor is still working,” continues Carreras. “With that, we can get visibility of the code, keys, and production reports and get to understand the infrastructure and the processes while the other vendor is still on board. That way, if something happens in the transition, we already have a decent level of access and knowledge.”
“That is why you need to have everything covered by contract,” says Horvitz. “Our contracts make clear that the IP we help to develop belongs to our clients. Our preference is to work within our client’s environment, ensuring total control and transparency. So every company needs to have this conversation and be aware of how and where their outsourced teams are committing their work.”
We have a few killer tips to ensure everything works as intended. “Transparency and governance are the keys,” says Carreras. “Even if things are not properly documented, but the client is aware of how things are done or executed, things can work out.“
“Some clients can rely solely on the vendor, who, ok, is the one doing the work, but the client should always be on top of things and the situation,” continues Carreras. “The client delegates the task, but not the responsibility. The ownership of the application belongs to the client; we are just working for them, and unfortunately, sometimes they forget that.”
“Product vision and product ownership are two things that cannot be outsourced,” says Erolin. “So product ownership remains within the client side. We can give product managers and product analysts, but from a product owner perspective, they should retain that.”
Of course, every situation is different. Some require the change as soon as possible, but others might have the luxury of taking a more paced approach. “Our preferred approach is gradual, a crawl-walk-run of sorts, where we initiate the transition with a core team to facilitate the knowledge transfer,” says Horvitz.
“We have successfully executed this pivot many times.. And yes, making this change requires a brief pause of new feature development; this is a critical crossroads-type decision for a lot of clients,” concludes Horvitz. “You have to take the long view. If it’s not working now, take the short-term pain, and we’ll partner with you to come out the other side with things looking a lot better than they did.”
Conclusion
Switching your existing outsourcing vendors is easier than you think. You select the new vendor, initiate the pre-discovery phase by gathering all the documentation and keys possible, help the new vendor go through the discovery phase, implement governance, and let your new vendor work.
At BairesDev, we can help you with any transition. We have over 5.6 million hours of engineering time, working with thousands of clients in over a hundred different industries. Get in touch with us today and schedule a consultation. We are here, and we can help get you there.
