With some frequency, we come across articles that mention lose of control as the most considerable risk of nearshore IT outsourcing, as no outside vendor can match the responsiveness level offered by an in-house department.
In fact, this supposed loss of control will depend on how is your nearshore software development provider organized, how you two cooperate and which level of flexibility you’ve agreed.
To assist in the decision-making process, we decided to list three key moments/actions to reduce the risk of losing control when outsourcing your IT project.
Choose Specialists instead of generalists.
Choose a provider familiar with the industry or sector of activity in which your project belongs.
It seems undoubtful that companies with specialized industry skills have a noticeable advantage, either by providing precious insights to their clients or by being aware of problems specific to each sector of activity. By working with a specialist provider, you can count on specific skills from developers through scrum masters to account managers that can save your company time and money.
Therefore, when choosing your nearshore partner, you cannot ignore their experience, or lack thereof, in your industry. To assess these skills, we advise requesting references, case studies, e-books or videos, where you’ll be able to find their previous work on similar projects.
At Cleverti, for example, there is a history of partnering with clients in some sectors like banking, insurance or energy, and for all of them, we have success stories that you can find here.
Transfer the necessary and relevant internal knowledge on time.
The quality of your nearshore partnership depends on how fully you transfer the necessary knowledge to your partner and how you communicate the basics of your business.
It is reasonable to say the transfer of internal knowledge has its proper moment, and not complying with it could harm the project. Moreover, this knowledge transfer process will also establish a decent working relationship by increasing confidence between both parties.
Anyway, let’s focus on which kind of knowledge you should pass on regardless of the provider you’ve chosen, and what methods you may follow:
1. Agree on a non-disclosure agreement, protecting sensitive data;
2. Give access to the software architecture documentation;
3. Explain your business requirements;
4. Make clear what is your project roadmap;
5. Provide deployment guidelines;
6. Mention (and if possible share) software development tools and techniques you use;
7. Access to the existing environment and third-party systems.
When making technical decisions, listen to those who know the tools to accomplish it.
Assuming you followed the previous steps, you may consider the three dimensions of knowledge sharing: from the individual to the team; from the team to other groups within the company, and from those to other company teams – Nonaka and Takeuchi (1995).
Having this in mind will allow you to support your decisions based on feedback from developers. In addition, this will also allow decision-makers to look at developers as a valuable part of the project.
Yet you should be asking at which times the technical opinion should be taken into account (more than at any other time). So, take a look at the following moments:
1. When choosing dev machines;
2. When introducing new technologies/frameworks;
3. On architecture decisions
4. CI/CD practices
Have you ever thought how absurd it would be to hire an expert cook but disregard his advice about the mise en place?
