Looking for an IT partner? Avoid these outsourcing risks

Arrow down icon
Published on
November 7, 2023
Petko Milidragović
Published by
Petko Milidragović

Choosing a software provider and an external IT partner is a very responsible decision. Building software requires many resources – money, time, people and if you agree to invest your resources into an external company, you want to be sure they’ll deliver the desired results. 

When choosing which IT company to partner with, there are certain questions and risks you should take into consideration. 

During over 10 years of our experience, we’ve heard and answered many questions and worries from our clients, so we decided to write this blog post to help you understand the most common risks of hiring an external IT partner and to explain how you can identify them and what to do to avoid them. 

Some of these questions include: 

  • This is a big investment, what if something fails?
  • How can I be sure that I’ll get the right people on the team?
  • How do I make sure the software will be the right quality?
  • How do I keep control of the project if someone external is delivering it?
  • How do I make sure there is no sensitive information leak?
  • How do I know the company is financially stable?

We’ll answer all these questions in this article.

But first, let’s talk about the notion of risk and make an important note about the basic model of risk analysis. Keep in mind that there are more complex methodologies for risk assessment, but we’ll talk about the most used one. 

Risk and opportunity are two faces from the same coin.

Image of coin — It partner outsourcing risks
IT partner risk and opportunity are two faces from the same coin.

Risk is perceived as an uncertainty with a possible negative outcome while opportunity is perceived as an uncertainty with a possible positive outcome.

As a responsible business leader, you want to minimize risk (that can result in negative consequences) and choose a good opportunity. 

There are a few ways you can check whether the risk is too risky or it’s actually a good opportunity.

From a theoretical perspective, you can evaluate:

  • The probability of risk – how likely it is that there will be negative consequences
  • Consequence of risk – what would the possible negative consequences be and how severe the impact of consequences could be

Based on that you can create:

  • A mitigation plan – activities you can do to avoid the risk, set the procedures to reduce consequence or probability that consequences will occur. 
  • A contingency plan – activities you’re going to do if the negative consequence happens, set the procedure in that case

For example, one of the perceived risks when choosing business office space is a possible flood in the office building. The mitigation plan could be to check all water and plumbing installations once a month. This way, you can reduce the risk that a flood will happen.

If the flood in the office building happens, the contingency plan would be the procedure about what happens then. For example: first we need to switch off the water and electricity, call adequate institutions, control, and evaluate damage etc.

Now that we have established and understood important terms we’ll be using when we talk about risks, let’s start answering the questions.

We’ll answer them from our perspective as an IT partner and from our example so that we remain very practical and to the point.

So, imagine you’re our prospective client and your legitimate question is:

Building software is a big investment. What if something fails?

Well, first I would like to make sure you understand at what point we can start our IT partnership.

When you come to us with a detailed brief about the software you need, we don’t get into business consultancy, and we don’t analyze whether that software is a good market fit.

Our tasks and goals are to make sure we understand in detail what is needed, to get all the required information, to engineer the process of how we’ll develop the software and then actually develop it. 

Our expertise lies in engineering and delivering software solutions. We assume that prior to contacting us, you did a business evaluation and determined that you need a certain software solution. 

We guarantee that thanks to our expertise which involves software development processes, analytical processes, IT and organizational competences, we can initiate the cooperation, get all the requirements, build and deliver the solution.

Yeah, this all sounds nice, you might say, but how do I mitigate risk?

Here’s how you can mitigate risk when planning IT partnerships:

  1. Have a very detailed project initiation. This will make sure that we understand each other perfectly. We do this through our Project Initiation Checklist that we described in more detail in this post. Thanks to this list we make sure we understand all aspects of the project (scope, time, budget, communication...) and we get all the requirements from you.
  2. Do a pilot project first. If you’re still unsure whether we can deliver what we promised, our suggestion is to test us with a pilot project first. The pilot project is an initial small-scale implementation that is used to prove the viability of a project idea. That way, you can spend less money and take a smaller risk which can help you determine whether you want to continue cooperating with us on a bigger project. 

Here’s how you can mitigate risk during software development:

  1. Use agile methodologies for software development. This allows us to have regular check-up meetings with you in shorter intervals. This way, we avoid the risk of going in the wrong direction for too long. It is also a good way to make sure we’re on the right track and we’re taking into consideration all possible changes that may happen along the way.
  2. Develop an MVP first. We always suggest developing an MVP (Minimal Viable Product) first. That is a software product with minimal functionalities that a target group will use and feedback. Based on that feedback we continue the development and addition of more features and functionalities, since we know which direction to go next.

About the contingency plan:

Since we have developed processes to mitigate risk, we don’t have much experience with unsuccessful projects. If, however, we come to an unwanted situation, this is what we do:

  1. We move into the project closure phase with the goal of identifying the causes of the problem and current project state
  2. Bearing in mind that all project development is done with agile methodologies, the cost of failure is usually not that high and it’s according to the perceived risk.
  3. Based on the analysis and current state, we decide whether we continue with the project while removing the causes of the problem or close the project completely. 

Regardless of whether we continue with the project or stop it, thanks to our continuous improvement culture, we have a meeting to assess the lessons learned. 

I will tell you more about a very important part of our company culture – a process we call continuous improvement. 

After each project is done or whenever we reach an important milestone, we gather all relevant stakeholders from a project and analyze lessons learned. We do that by making 3 lists: 

  • Keep doing – we list everything that was good and worked well 
  • Start doing – we list all the things we agreed we should start doing to cooperate and work even better
  • Stop doing – we list all the things that didn’t work well or didn’t give results so there’s no need to do them anymore

This way, we make sure we are continuously improving our way of working and cooperation both among our internal team and between clients and our team. 

You can also include contingency plans in the contract – define what happens if the delivered product doesn’t work or doesn’t have all the agreed functionalities.

Another way might be to check if insurance can be bought or set up. 

The next question you might have is:

How do I know my IT partner will give me the right people for my project?

You are used to choosing people who work for you, but when you partner with us, we already have our employees that we will allocate to work on your project. It is normal that you’re worried about whether those people are competent enough and how they’ll integrate with your team.

Over time, we’ve developed a detailed process for choosing which employees will work on which project. Also, we have a procedure that guarantees good team integration

We know that we can’t reach perfection, but our vision of an ideal team is the one that allows us to minimize the turmoil of integration and focus on the work as soon as possible. That means this team is required to be:

  • Seasoned — The team should possess adequate know-how, not only in technical but also in the problem-solving sense.  
  • Performing — The focus of the team should stay on creating business value for your company.
  • Adaptive – We are aware that all our clients have different working methods, so our team should be able to easily adjust to those methods. That will help them understand your culture and cooperate smoothly with your team.
  • Efficient – Skills and knowledge of our team members should be complemented in a way that makes the team self-organized, cross-functional and capable of handling difficulties.

How do we choose people that make the ideal team?

Based on your answers to our Project Initiation Checklist, we determine what level of analytical, technical and organizational skills each team member should have. This allows us to employ the optimal resources for each project and select the best fit of a team for your project according to the questionnaire we filled in together. Based on this, we create a profile of an ideal developer and search for the best match. Rest assured that this assessment is through.  

  • Analytical skills include understanding requirements and transforming them into technical, having knowledge of software architecture and being capable of designing their own software components.
  • Technical skills are related to the developer’s knowledge of the programming language in question, testing, operations and handling databases.
  • Organizational skills include understanding the SDLC (Software Development Life Cycle), as well as leadership, communication and management skills.  

Then we compare this table to actual candidates for the team and select them based on their capabilities. This is the responsibility of the Chief Engineer (CE) and HR with the help and support of the Sales Manager and Chief Operating Officer (COO). Once we have our optimal team proposal, we bring it to you and consult you on it.

How do we make sure that the ideal team integrates well with your in-house team?

We highly emphasize that the process of integration shouldn’t be a burden for you. You should focus on your business and it’s up to us to get all the necessary information through our procedures which will enable us to easily integrate. At the same time, the point of the integration and the goal of the newly created team is to deliver the product needed, while ensuring the quality level stays high and the time frame is respected.  

Taking care of all those things would be a lot more challenging without the right procedures and mechanisms in place. Besides that, for a group of great individuals and professionals to become a high-performing team, the process of integration is crucial.

That’s why we go through 3 phases:

  1. Setup phase
  2. Onboarding phase
  3. Performing phase

We explained all three phases in detail in this blog post: the process behind successful IT partner integration.

Now that you know how you can mitigate risk if something doesn’t work well, how we’ll find the ideal team and integrate them with your in-house team, your next question might be: 

How do I keep control over the project that someone else is delivering?

It’s your project, your money and you deserve to have full control over it. That’s why we claim we can give you full transparency into what we’re developing for you. How?

We have processes in place. Based on the chosen Software development model (Agile or Scrum), we plan regular meetings and sprints. Some of the meetings are happening among the development teams, but we’re also regularly communicating with you – our client. 

That’s why we’ve established a Key Account Manager (KAM) position in our company – so we can guarantee better communication with you, and you’ll have a single point of contact for all questions and concerns that may arise. Regularly, we have formal reports which include info about the project development stage and what percentage of the budget has been used so far. 

Not only that our KAM is keeping you informed about your project, but they’re also keeping you informed about the important news from our company. Since we’re partners, we believe we should be open and transparent. So, if someone from our company that works on your project is leaving the company, we make sure you know that, and we let you know who will replace this person. If our employees get a new technology certificate or we celebrate success, we share that with you as well. 

Based on our experience and organizational knowledge, we have created a structure consisting of 6 basic communication processes:  

  1. Development Team – Client. This is the most intensive process which takes over 90% of all communication. Our development teams communicate with you – our client – daily about operational matters since they work on creating the optimal solution and value for you every day of the project's duration.  
  2. Team Lead (TL) – Key Account Manager (KAM) – Chief Engineer (CE). This internal meeting is organized every two weeks by CE and its purpose is to exchange key information and monitor progress. TL presents the state of the team through a set of indicators – technical, organizational, and HR-related – as well as the key findings about the project itself. KAM presents the input from you and communicates any request or feedback you may have to the L, team members, or the company in general. On the other hand, TL communicates all findings you should be aware of to KAM since TL might foresee certain issues before they arise but doesn’t have the authority to act on them. The result of this meeting is a set of action items directed at the Team, KAM, the client or our company.  
  3. KAM – Client. Once a month KAM meets with a higher-level manager from your company to exchange business-related information and discuss expectations and future plans. The purpose is for KAM to get your feedback, make sure you are satisfied with our service or bring up any input they received from TL.
  4. Team – Chief Engineer. We call this meeting a quarterly retrospective and the main thing about it is that the whole team participates in it. It’s organized as a workshop led by CE where the team openly discusses all the relevant aspects of the project. Team participation is important because sometimes the Team Lead may oversee some relevant aspects that can be discovered during this workshop. Again, the result of this meeting are action items that also present the input for the biweekly TL-KAM-CE meeting.
  5. KAM – COO – CE. The input for this meeting, which is held every two weeks, are all the items from the action item list for all our clients and projects, while the output is a focus list for the next two weeks. The purpose of this meeting is to determine what to focus on for the next two weeks, according to project priorities and action items list from meetings (2) and (4). All KAMs participate in this meeting and receive directives for their work in the two following weeks.
  6. Executive Management (EM). This is a strategic meeting where the Executive Management receives necessary input in order to make strategic and operational decisions about each project (whether to increase the number of engineers, close the project, change the team seniority, etc.). The input is a report that includes information from all relevant stakeholders: CFO provides financial input, CE provides technical input, Head of KAM provides business input, and HR gives people data.

All these processes are interconnected, and they enable us to ensure the right information is communicated to the right people at the right time. There can be no transparency without properly conducted communication, so having regular meetings and receiving valuable feedback will impact your satisfaction with the final product to a great extent.

Through regular and structured communication, we ensure you’ve got control over your project we’re working on.

Another, very important question you might have is: 

How can you as an IT partner guarantee security of information and that there won’t be any sensitive information leak?

This question is extremely important, because often we work with a lot of sensitive and confidential data, and this is important for both you and your clients or customers.

One of the ways you can easily check if the company can guarantee information security is to check which security certificates they have. To get these certificates, the company must undergo a deep and serious certification process and an external agency must inspect it and make sure they comply with all the criteria before awarding them the certificate. 

We’ve been awarded ISO ISO 27001:2013 certificate by renewed TÜV Austria.

All our safety measures correspond to the ISO 27001:2013 Chapter 7. This certificate guarantees security of information. 

Security measures we have for hardware include:

  • Organization of information security
  • Asset management
  • Access control
  • Physical and environmental security

Security measures that we have for software include:

  • Access control
  • Operations security

If you’re thinking about hiring an external IT partner from another country, you might be worried about whether they’re reliable and financially stable. You don’t want to start working with someone who doesn’t have enough resources to help you or who is a risky partner.

The question we hear usually is:

How do I check if an IT partner is financially stable?

There are a few ways to check out the company you’re considering partnering with.  

  1. Check their financial statements in the national company register. In Serbia, it is called APR.
  2. Check their financial certificates. There are organizations that award companies based on their financial results – search or ask for financial certificate they have.
  3. Check their current clients and even contact them and ask for a reference.
  4. Check the company online – check how many employees they have, where their offices are etc. 

We have AAA Gold Credit rating certificate from Swedish rating agency Bisnode AB (now part of D&B Group), which means that we are among the most successful and liquid companies in Serbia. 

Well, now you know how to evaluate the risk and avoid getting into hazardous partnerships with external companies.

If you don’t have prior experience with partnering with an external software development provider, I hope this blog post can guide you and help you make a good choice. In short, you can:

  • Ask how they do project initiation and how they make sure they understand your needs
  • Choose to do a pilot project first
  • Choose to create an MVP first
  • Choose agile software development methodology
  • Get to know the process of selecting the team that will work on your project
  • Ask them how they guarantee quality and transparency (if you want to have control over the project)
  • Ask for security certificates they may have
  • Ask for financial statements and certificates they may have

If you like the answers and feel good about it, go ahead. The benefits you can get with the right IT partner are enormous. Protect your downside risk and focus on the upside opportunity.

If you would like to hire us to be your IT partner or to test us with a pilot project, contact us through our website.

We’re looking forward to talking to you!

Feel free to contact us

Enlight logo