Choosing the right provider to outsource a software development project may be a tricky task. When looking for a provider, a variety of factors should be taken into account. Based on our experience, the most important things to consider are:

• The expertise of the team – whether they possess the knowledge and experience to handle your project;
• The transparency of their processes – whether the team informs Customer about everything that happens in a timely manner, including issues that arise, and whether there is a way to solve them.

Having a reliable development partner to work with all the way, from the project idea discussion to the product launch and support is what customers typically seek for. Unfortunately, sometimes unexpected issues arise, and you might even have to go separate ways with your vendor.

Why you may need to switch to another provider

Let's look through the most common scenarios which can lead to the necessity of changing your software development provider.

1. The price of the services may seem too high for you.

Based on our experience, we can say that the price (in particular, hourly rate) doesn't always determine the overall project cost. Although the hourly rate of specialists of the same level may vary from company to company, the productivity level and work approaches are also different.

Let's illustrate this point with the following example.

There are two companies – Company A and Company B. A developer's hourly rate at Company A is $50/h, and a developers's rate at Company B is $20/h. However, a certain amount of work – such as consultations, gathering project requirements, system maintenance, user support – needs to be performed onsite. An hourly rate of onsite experts at Company A is $70/h, and at Company B – $120/h. Company B spends more hours on onsite works, and it involves more experts than Company A does. In this case, the overall project budget at Company B may end up higher than the budget at company A.

Therefore, a higher rate doesn't necessarily mean higher project costs – such factors as, for example, the expertise should also be considered.

2. Your current provider may fail to meet the budget and time constraints.

Needless to say, staying within the budget constraints is critical for any business. Providing the deliverables on time is also an important characteristic of a software development partner, especially when important releases are tied to certain business events. If your provider fails to accomplish this, it may become a real threat to your business success.

3. The quality of the provider's work doesn't satisfy you.

If you notice that a product (or a certain deliverable) doesn't work as designed, and this happens systematically, start looking for an alternative provider.

4. The provider doesn't have sufficient competence to keep pace with the new business and technological requirements.

Business requirements are subject to change, which means that the existing solutions should adapt to these changes. Often, to keep pace with all the changes, new technological tools need to be applied, and sometimes it happens that the current provider doesn't possess all the necessary competences.

5. The provider has just disappeared.

In the most unwanted scenario, a provider may even stop replying to your requests.

If any of the above is the case, then it's time to look for a reliable partner. Let's see how you can do this in the most efficient way.

How to change the current software development provider

Gather all the artifacts on time

If you do not like the current development team for some reason, it would be a good idea to start gathering all the artifacts from them – i.e. documentation, code access, passwords for accessing the environments where the application and the database server are deployed.

Once you have all the artifacts, start the transfer process while the provider is still active. When you stop working with them, they can refuse to help you with gathering artifacts, conceal important details, delay the transfer time, or give incomplete answers.

Keep all the access details under control

Make sure that all the access credentials (the passwords and access to the environments where the application is deployed, the code) are real and are under your control (which means they cannot be changed without your permission). This way you will prevent the unwanted event when the provider you decided to break ties with begins to extort money for these accesses.

Ensure the data completeness

Make sure that all the artifacts (documentation, schemes, code, etc.) of the project are located in the repository. There shouldn't be any documents or code that exist only on the developers' machines or in a private repository controlled by the service provider. For this purpose, you may have to build the code from the sources, deploy and run the application on the prepared environment. In addition, the application will need to be tested. But the time spent is worth it.

Take the time to transfer all the artifacts

This is not an instant process, and it requires the participation of various experts – analysts, developers, managers, testers, architects. A proven format is: the team who hands over all the artifacts holds several meetings where it shares the key points of the project, its deployment, customer's business, etc., with the demonstration of the project related documents, and the accepting side asks all the questions it has. After getting familiar with the project materials received, the accepting side might still have some questions left. Therefore, it may be useful to hold additional meetings to answer the questions.

Most likely, this time will have to be paid for (by both sides of the process).

Agree on consultations

Agree on the possibility of consulting with the previous provider some time after the artifacts are handed over to a new provider. There will always be some questions left.

Arrange the recordings of meetings

A good idea is to have all the meetings recorded (in video or at least audio format). Despite the fact that minutes of meetings are usually written, they may lack small details, which might be needed further on. So, having the recordings will help you a lot with finding answers to your questions in the future. In addition, it will make your meetings way more constructive.

Have the two vendors work together

For large projects, it's a good practice to have the new provider's team working together with the previous provider's team under a single release or several agile iterations. As soon as they perform at least one release together, the new provider will get an understanding of the processes, technologies, and code.

Think of Plan B

Be sure to have Plan B in case something goes wrong while working with a new team. There are known cases when a Customer transferred the project to another team, and that team could not make a single release for the whole year, because the project was large and complex in terms of business requirements and technical aspects. Moreover, it turned out that the new provider lacked the required competence. So, there should be a possibility to return to the state of the project before it was transferred to the new team.

For a business, a new release on the project means certain changes in business processes for all the participants. And some processes are subject to change regardless of the project. Here is an example to illustrate this point:

*Two departments – Department A and Department B – have agreed to exchange the electronic documentation. Department A has changed its processes to meet the requirement of having electronic document management. Department B failed to launch the required software. Therefore, the business processes for both departments have been disrupted. *

A provider who has experience in accepting projects will help you at every stage of the project acceptance. All the experts from the accepting side are usually involved in the process:

• The analyst studies the documentation and gets understanding of the business side of the project.
• The system architect and developers work on technical implementation details.
• The software testers make sure that the version of the application received after building the code from the sources is the same as the version the customer has paid for to the vendor.
• The designer checks whether all the design and interface materials are transferred in formats that are appropriate to work with in the future.

So, the new provider's team should apply all of its technical expertise to ensure the successful project transfer.The activities in this area include (but are not limited to):

• reviewing all the necessary documents;
• reviewing the code;
• checking the transmitted code for the completeness;
• making sure that all the artifacts are transferred correctly and completely.

What about us?

ISS Art team – Top San Francisco Software Developers – have experience in taking over development projects started by other companies.

Actually, transferring a project to another team is not that scary. If the project is not very large, having access to the repository and the possibility to contact the previous developer for a while will be enough.

In fact, even if you broke ties badly with the development team, the most necessary minimum for us is the access to the source code. Just make sure that the whole application code is located in the repository (not just a part of it), and it is working.

Our experts will study the existing code and dive into your business specifics (possibly with your help), even when no documentation is left. We are already experienced in it.