At NeuroSYS, we’re more than aware that IT product development is always a challenging task, both when it’s an internal system and a SaaS application. No matter if you develop it in-house, recruiting a proper team beforehand, or hire an external company to do it. The latter you can carry out in your home country or abroad – offshoring or, looking closer, nearshoring it. If you need nearshoring explained – here is the post on that particular topic.
Should you fear nearshoring? What are the most common concerns that CTOs face? We want to address common misconceptions and fears that might have arisen around the subject that we’ve encountered talking with our partners. We write about nearshoring but the issues discussed apply probably to any external team hiring.
In the article, we’re discussing the five most common fears about nearshoring:
- losing control
- low quality of service
- poor communication
- poor understanding of business needs
- becoming dependent
On a side note, one of the tools that can greatly facilitate cooperation with external IT providers is agile methodology. In the following article, we’ll refer to it a bunch of times. We’ll also use agile terminology in which some terms may have different meanings without SCRUM context, take as an example Product Owner. If you need more clarification on the topic, please refer to our previous blog entries on agile methodology or explaining how IT works.
1. Losing control over the development process
Putting your product or service development into the hands of another company raises concerns, always. And that’s normal and common. When we feel that we’re losing control, we’re afraid and might ask ourselves questions such as:
- What my nearshoring team is doing exactly (and why it takes so long)?
- At what stage is my project right now?
- How do I know If I’m not throwing money down the drain?
- Can I maintain flexibility and change the direction in which my product goes?
- What about deadlines? Will I be able to promise a delivery date to my end customers? Will it be done on time?
To make things clear from the start, employing an external company doesn’t mean that you lose control over your product. In an agile approach, if a project will be carried out that way, it is a Product Owner that plays a crucial role. It is him/her that decides which changes in the project are essential and will bring the highest return on investment (ROI). Product Owner has many tools at his/her disposal that help to define expectations towards the product in the making and to set short-term priorities that can change from sprint to sprint.
Most of the project management tools, such as Jira, Redmine, and YouTrack, help to track the progress of the whole project and single issues. Access to an agile board presents statuses of all tasks in the given sprint in a transparent way including information on time needed to complete, time spent, and incoming deadlines. A professional contractor will propose a set of reports as well.
Actually, what we observe is that hiring an external team motivates business owners to think the project over and helps them verify their initial assumptions by creating roadmaps, setting short and long-term goals. If the team is agile, they will also react quickly to any changes appearing in the meantime, caused by the market or the moves of the competition.
Considering deadlines, professional development teams work based on estimates. They discuss with you all the tasks that have been submitted for implementation, analyze them, and estimate the time and resources needed. Based on this information, they can predict the date of delivery under certain circumstances with high accuracy. If the external conditions, tasks, or Product Owner’s priorities change, naturally the declared dates cease to apply. Having that in mind, it’s easier to avoid moves that’d disturb the team’s work and reduce the predictability of the project. I always advise taking into account a safety margin when declaring delivery dates to the end customers in case of any changes that might lie beyond our control.
2. Low quality of service
Making use of more cost-effective solutions always draws anxieties. Business owners’ fears are typically:
- Are the nearshoring developers competent?
- What if the code produced is unreadable or inconsistent with the best practices?
- Will any changes be adequately tested and documented?
As a customer, you should expect your supplier to present a detailed Quality Assurance strategy for your product. Professional IT suppliers use many quality control mechanisms at every stage of production, including:
UX/UI design
It is the UX/UI design stage that allows you to assess user interface transparency, potential interactions, intuitiveness, and ease of use. All of it happens before the app is actually in the development phase. This first stage is there to assure you that your nearshoring company understands your business, vision, and end-users.
System architecture design
To create a well-thought-out and consistent system, we need to develop its architecture and data flow. First and foremost, it needs to take into account current business requirements and potential directions for product development. Otherwise, the application code will be continuously bent to the current needs, instead of implementing the patterns developed at the very beginning. A good practice is to document all architectural decisions using the so-called Architecture Decision Records. An ADR is a short document, which describes the details of the architectural decision made, including the context, an analysis of alternatives, and its consequences. Creating ADRs encourages the team to make informed and thoughtful decisions, carefully consider alternative solutions, and helps any new team members to understand all complexities with greater ease.
Test plan
App testing belongs to the most important quality assurance mechanisms. Thanks to it you can check if the product developed meets all the assumptions and requirements, both functional and non-functional ones. As a side note, take into account that the sole declaration that the application will be tested isn’t sufficient to ensure the high quality of the app. Only a test plan submitted before the project starts will provide you with details on the following issues:
- unit tests and test coverage
- manual tests of newly created functionalities and changes
- test cases being a part of the documentation, so they are repeatable or can be automated further on
- bug reporting and handling procedures
- automated tests with the policy for their creation and execution
- regression testing
- vulnerability and penetration testing of the app and server
- QA as a part of continuous integration/delivery
- tests concerning performance and support for the required traffic (performance testing and stress testing)
- Code Review (source code review), so every single line of code is verified in terms of code clarity, the use of the good programming practices, optimization, and following design guidelines, by at least one other developer
- test environment for the customer to examine the version of the system ready for release to production (the so-called staging/pre-release environment).
As you can see, there are quite many procedures that can ensure the quality of your application. I can’t deny the fact that all quality control mechanisms listed above entail higher costs. However, I want you to be aware that these options are available so you can make a conscious decision.
3. Poor communication (or the lack of it)
Employing a nearshoring team you want them to be able to take over the whole development process. But however excellent their business consulting and development skills are, it won’t go well if you can’t communicate effectively. The potential concerns in the area include:
- Unresponsiveness of the supplier
- Not answering your urgent questions
- Getting conflicting information from different team members
- Linguistic or cultural barriers that prevent effective communication
In terms of communication, the human factor and individual interpersonal skills of the team members play a significant role. However, establishing some basic rules on the flow of information will definitely help to overcome some barriers.
Single Point of Contact
The first principle is establishing a Single Point of Contact (SPOC) at both sides – your and your supplier. The role is performed most often simply by managers. This way we’re limiting the communication and contradictory information that might take place when more people are engaged in communication. Nevertheless, this approach does not exclude other team members from communication, but the presence of a single point of contact(s) is always required.
Communication channels
The second rule should be establishing communication channels and specifying their purpose. For instant, daily communication I recommend all chat tools such as Slack, Google Chat, or MS Teams. They also allow quick calls and larger video conferences, which usually are more effective than merely exchanging messages in a chat. If the team organizes its work via tasks created in a dedicated system, such as Jira, YouTrack, or Redmine, it’s also worth making use of that channel as well. Questions and answers, as well as any relevant information on specific assignments, should be posted as comments inside the tickets. Finally, think about setting up a communication channel, such as e-mail, for more formal communication, concerning deadlines, delays, estimations, risks, etc. Thus crucial findings can be found easily.
4. Lack of good understanding of my business
Looking for a nearshoring IT company we don’t want just the code written. We need a real business partner that has a deep understanding of our needs, vision, and can support us with major decisions. The main fears here are:
- The outsourcing company doesn’t know the industry
- Our processes are too complex to understand and/or not documented properly
- I don’t have the time and resources to prepare a detailed specification for a supplier
- Our need/product is very specific, it will take a lot of time and money for the supplier to get to know us well
- I’ll have to see the final result to know if it is what I really wanted
Software houses specialize in tailor-made software and they should have experience with a wide range of clients from various industries. Knowing that most IT projects are characterized by high complexity and variability, they won’t expect you to provide a comprehensive and complete specification for your app. Instead, all you need is a general description of the system and a list of functionalities that, at the very moment, it is supposed to offer. It’s good to have a vision of the whole application, but it’s usually not the best idea to aim to deliver all the functionalities within the first release. Instead, it’s better to aim at MVP – Minimum Viable Product, which brings time to market as well as first feedback from end-users and investors quicker. By providing your clients with just the core features you can start monetizing your project much sooner.
Once you determine what functionalities are key for the first version of the application, the supplier will have to know the details to plan the development phase. The analysis begins with the business layer, i.e. the processes that the application aims to implement or support. At this stage, your participation as a customer is crucial, because it is you who has the best knowledge about the product. IT analysts use various techniques to ensure the effective acquisition of knowledge from customers, from properly conducted conversation to special team exercises, involving not only the decision-makers on the client’s side but also people who will actually use a particular solution or module, such as HR specialists or accountants. Event storming is just an example.
A development team should also have a UX/UI designer on board, who, based on your requirements, will prepare professional mockups. They won’t look like final UI designs but will show you the content of particular screens, an arrangement of elements, navigation, etc. This solution allows you to make sure that the application will look as you expected, and also makes it easier for developers to implement all visual components based on mockups.
5. Getting fully dependent on a supplier
Last but not least, there comes the fear of becoming fully dependent on your nearshoring company. The nearshoring relationship may be long-lasting, but surely you don’t want to lose independence. When the contract ends – it ends. You shouldn’t be left with any duties or responsibilities towards them. Nonetheless, what might concern you is whether:
- The supplier will return the source code and grant access to all the materials
- The company will share knowledge about the project
- They use technologies or solutions that are commonly known
- They won’t force additional services taking advantage of their specialist knowledge
Source code and copyright
When choosing an IT partner, you can minimize the risk of developing a long-lasting unhealthy relationship. First of all, make sure that you’ll be the owner of the source code that will be created while working on your project, along with the transfer of copyright. It has to be regulated in the contract. Even if you’re not thinking about changing your application right now, it’s almost certain that sooner or later there will be a need to modify or modernize the system. If you won’t have the application’s source code or copyright, you will be doomed to cooperate with the same service provider.
Code repository
Usually, nothing prevents the provider from working on your code repository. If you do not have one, you can use services such as GitHub, GitLab, or Bitbucket. If the source code is kept in the vendor’s repository during the development, you can request access to it for your employees. It is also good to ensure that the code that is created is readable, preferably self-documenting. For this purpose, it’s worth establishing common rules for working with the code. Your developers can also participate in the code review process mentioned earlier, so they won’t take their eye off the ball.
As-built documentation
Having as-built documentation, preferably created on an ongoing basis, helps in a trouble-free disconnection from the supplier. When the cooperation is going well, such documentation will allow the faster and cheaper introduction of new team members, and when problems arise, it’s easier to find and introduce another supplier.
Mainstream technologies
Also, discover what the IT market looks like in terms of technologies. A supplier that builds its solutions based on niche technologies can effectively stop you from looking for alternatives if the cooperation doesn’t work out. Currently, the safe choice includes
- for web applications: Node.js, .NET, PHP, Java, React.js, Angular.js
- for mobile development: Java, Objective C, React Native (cross-platform technology)
- for artificial intelligence and machine learning solutions: Python.
It can be difficult to unequivocally judge whether a nearshoring company is actually targeting your project or trying to use their advantage to earn more money. Therefore, it is worth maintaining a close relationship with the supplier, asking questions when there are any doubts, and asking for a full and clear explanation of unclear issues. In exceptional cases, it may be necessary to hire an independent auditor that will assess the legitimacy of the needs notified by the supplier. If you’re interested in the topic – please go to our nearshoring service page.
