Outsourcing is a very popular way of carrying out projects in the IT sector. With such a large number of companies from all over the world, you can be really picky when choosing the outsourcer that will suit your organization best and guarantee the good performance of the project you want to outsource. However, sometimes the company you choose – the one that seemed the best choice at the time – does not fulfill your expectations when it comes to reaching the goals of your project. What then?
The most common reasons for ‘divorce’
As in any other business, different IT companies offer different levels of service. The contractor’s development stack may look promising as you’re signing the commission contract, but it can turn out to be insufficient to realize your ideas in practice. In such situations, the limited know-how of the contractor’s company is the main reason you’re considering the change of the service provider.
This is not the only reason for deciding to switch one company for another, though. Other factors might include:
All of the above issues can prompt you to change your service provider. It may be just one or a combination of many but when they occur to a certain degree, the divorce is inevitable. What can you do to go through it as smoothly as possible, and what is important when choosing a new contractor?
Good practices for entering a new relationship
The choice of a new partner should be a well-considered decision, if only to avoid the problems that ended the last relationship, but also to minimize the risk of new ones. This is not a simple or quick process. Some make use of opinions shared on various websites, such as Clutch, others look up portfolios of similar projects, follow friends’ or network recommendations, or carry out research online.
The quality of the first contact can say a lot about a company. If you have to wait for a reply for a couple of days or their first question is about budget, you can walk away. If the communication (via email or phone) is quick, the company is honestly interested in the problem and able to offer adequate persons to solve it, you can pass to the next level of talks.
These should involve the presentation of the business and technical problems and the development of a further plan of cooperation. Sometimes an audit is required as a separate job, so if the company undertakes to work on the app, you can concentrate on drafting a support agreement.
The new partnership begins
Unlike starting a new project from scratch, where it is necessary to build the architecture, select technologies, etc. in a project which has already been started by another company, the focus is on what’s already there.
The code, technology, and architecture are probably chosen or in place but the previous contractor might have worked on them using a different process, in a different spirit, or with different values. That’s why the best solution to begin with is to audit the app in order to find out whether the business and functional requirements have been implemented, what the code quality is, and which features of the app are weak (e.g. security gaps).
Here are the most important points to pay attention to during the audit:
1. A detailed analysis of the system: what it serves, what problems it solves, if and to what extent it is used.
2. The identification of the most serious problems with the system – based, among others, on the backlog. These can include, for instance, slow operation, malfunctioning options, or instability. This process will result in a better understanding of the system.
3. A system test using a local installation. The process of installation itself can say much about the state of the application. Without ready automatic scripts, the app is probably rarely updated.
4. Checking if the app collects logs and if it has a data backup and cleanup mechanism. Without the logs, in case of a breakdown, all you’re left with is pure guesswork, and I don’t think I need to tell you how products without backups end up.
5. An analysis of the code. At this stage, it’s a good idea to answer a series of crucial questions:
Are there any tests? If so, that’s great, because this gives you a chance to check if anything is tested at all. Analyzing tests has another benefit: you get to know the system and the principles governing it better. If there aren’t any tests, you’re going to face a big challenge, as you cannot be sure you’re not going to spoil some element while editing or fixing the app.
Are the coding conventions consistent?
Are design patterns used?
Are the frameworks and libraries reliable? Here, it’s worth taking a look at their versions. It often happens that security bugs turn up because the installed versions haven’t been updated.
Is the app secured against attacks? Security bugs can be detected during the code analysis; for example, you can verify whether the entry fields data are correctly processed to prevent SQL Injection. There are many more possible attacks and each should be well analyzed.
To analyze the source code you can also use static code analyzers which can give additional support to the audit with data from an external tool.
After the audit
A well-run audit will help you take a next step. Its results will determine the following scenarios. For example, if the audit’s results are not good, you should think about several issues:
Should everything be rewritten? If the app is small and it’s possible to rewrite it quickly, this makes sense.
But what if the app is large? It’s hard to accept that nothing might be released to production for a whole year due to rewriting the app. What’s more, during rewriting, some significant assumptions from the beginning of the project may be missed, and that can harm the business logic of the app.
In this situation, it’s a good idea to place a “cap” over the app and to create new functionalities directly inside it and transfer the old code along the way, taking small steps towards better practices.
The audit can result in many similar scenarios to take into consideration. The ideal way to address each one is in cooperation with your new partner.
The next step is to get acquainted with the backlog, both in terms of the tasks already performed and those that are still in the planning stage. You should discuss your short-term and long-term plans with your new or potential partner. Don’t forget to add new tasks to the backlog, those resulting from the audit and subsequent prioritizing.
The infrastructure used by your ex-contractor is a key element. Normally, the list of tasks as well as the whole work history are in their system, e.g. Jira or Redmine, and the code is in the provider’s version control system, e.g. GitHub. Frequently, the app can be found on your previous outsourcer’s servers (mainly in the cloud but sometimes also on physical servers).
You should transfer all the required data to your own or your new provider’s infrastructure. Remember to check that the previous contractor no longer has access to databases, apps, and other data.
Before the app starts on the new infrastructure, it must undergo tests to make sure everything works just like it did in the latest version, and if all the integrations – e.g. with an external payment system – function correctly. When the app’s functionality has been verified, it can be started for the users.
Development and maintenance
If you already have a working app on a new infrastructure, a task checklist (backlog), and testing and development environments, you can start off (or re-start with your new contractor, that is) development and maintenance works for the app. Usually some members of the team work on the quick improvement of any essential errors (especially security bugs and those concerning other sensitive components), while the rest works on the development of the app, i.e. adding or changing functionalities.
A working relationship
Even though the whole process may look money- and time-consuming, sometimes there’s no other way and you just have to change the service provider instead of staying stuck in an unhealthy relationship. The cost – failing to realize your business goals, not to mention the stress of collaborating with an unsuitable team – can be much higher than that of changing provider and finding a new team.
However, before you make the decision to ‘switch horses’, consider the additional costs:
The cost of the audit and necessary amendments,
The cost of all the transfer works, which may not generate profit but might generate a loss if the app is still not available to customers,
The cost of implementing a new team before maintenance and development works start.
That’s why it’s so important to create a product roadmap, on your own or along with the potential partner, to make a precise estimate of the costs of changing contractor. That way you can make sure the profits will balance the possible initial costs in the long term. If the numbers are right, it’s better to finish the unhappy relationship and start a new one, giving you new opportunities and perspectives for the future… and a better chance of project success.