Managed support services: how to minimize your reliance on contractors?

Do you recognize your case? Broken deadlines, low-quality code, multiple mistakes, constant extending of working hours, a lack of support, and in the end, you’ve got something opposite to what was ordered… These are the typical issues companies face when working with contractors and not having a proper and stipulated process. In my practice, I very often hear that the clients have no idea of what’s going on in this or that project, or they cannot get any feedback from the contractor, or they even have different contractors simultaneously, and urgently need someone to provide managed long-term services and support.

So, what’s so important about the proper cooperation organization? Even if you have good relationships with your contractor, but their approach to performing tasks is wrong, the outcome will be poor. The contractor team should follow a specific multi-step plan to deliver high-quality results. If they do not stick to some specific approach and act chaotic, they know nothing about the right process of cooperation. In such a case, this should be a question for you both to discuss.

As a result, the company loses control over the expenses as they do not see the whole picture. The damaged area may be enormous if the software suddenly goes down and no one in your tech team can fix it. The consequences include reputational issues, downtime, and subsequent financial problems. Among technical issues, we usually distinguish versioning problems, open-source platform vulnerabilities, wrong tech stack use, and many other tech issues. In this article, let’s discuss the hidden rocks and pitfalls and what to do to build a perfect process of cooperation with your contractors and become less dependent on them.

Table of contents

1. Where does the issue lie?
   • How we helped our client to deal with the overdependence consequences
   • What you may face when your collaboration process with the contractor is wrongly set up
2. So, how can you level down the dependence on contractors?
   • What should the correct process look like?
   • Three ways of setting up the right process
3. Conclusion

Where does the issue lie?

What does it mean to be overreliant on a contractor? This means that if your cooperation is suddenly over, you have no idea about the project’s status and who is responsible for these or that tasks. To avoid such a situation, it’s important to understand that one day your cooperation will come to an end, and you should be ready for that. It doesn’t matter if that’s the rule in your company to change the contractors every year, or your cooperation wasn’t that successful, and you need someone else to fix everything, or your budget is now cut, and this team becomes too expensive for you. The reasons for ending your working relationships could be very different, but the only thing that matters is that you have to get prepared beforehand.

Let’s review one of our cases where a company was too dependent on the contractors, and that led to bad consequences. But no worries, we’ve helped them to fix everything.

How we helped our client to deal with the overdependence consequences

One of our clients had several solutions (e.g., websites or applications) developed by different contractors with different technologies, and all of these solutions were managed by different people inside the company. That was a tough task for their inner IT team. They had to dig deep every time something occurred in one of the projects, spend many hours, and in most cases, they resulted in 0. The issues remained unsolved and stacked, creating a snow block that became an avalanche.

Unfortunately, that is the truth as every contractor uses different technologies and approaches when developing a website, and for a team of 10, it’s impossible to control all the websites simultaneously, fix daily issues, keep a high level of security, etc.
So, they’ve decided to completely rely on each contractor and outsourced all tasks on support to them. Time went by, and a bunch of issues pounced upon the company’s IT department. Wrongly built infrastructures, no granted access to production, no access to the code, they almost ran out of free space, the website users were unhappy... That was a moment when they didn’t know what to do. The company’s IT expenses started to grow and become uncontrollable; these guys understood that they needed to save the business.

Well, getting back to the point, the company decided to find a Managed Service Provider (MSP) and set all the support and management processes going, i.e., they came to us, and that’s where our relationship started. The setting up process was long enough, and each party needed to be patient and calm. We had to contact each of the contractors on behalf of the company, ask for the necessary data and information, and then do a lot of work to make everything run as a single mechanism. Still, we’ve been successful in this. The process was set up so that both the company’s developers and ours were on the same page. No hidden rocks, no secrets, but increased efficiency and full understanding of the current situation.

What you may face when your collaboration process with the contractor is wrongly set up

When working with a contractor, the perfectly set process of cooperation plays a key role. For both parties to reach success, it’s essential to understand the responsibilities. As soon as you have set the process up, you’ll feel all the benefits of outsourcing: more time for you to run the business, stable work of your software, customer loyalty, etc.

However, if your current contractor skipped that step and everything went wrong, then most likely you are to face (or already facing) these issues:

1. Harm for image

   Every company values its reputation. However, if your software product is unreliable, you can’t count on customers’ goodwill and trust. If your product constantly goes down, it’s just a matter of time when the customers will choose a more reliable partner.

2. Financial loss due to downtime

   One of the biggest nightmares for a company is downtime and no possibility to get back on track within a short period. If that happens, that means a business sustains dramatic losses. This concerns not only money but also reputation. So, a company needs to have a perfectly developed and solid product that meets customers’ needs and satisfies their expectations.

3. A mish-mash in technologies

   This is the saddest thing for every product owner. Tons of different frameworks and languages used to develop software make it very difficult for a new developer to understand the code. I also can’t help mentioning the versioning issues. Just remember the Delphi time when the libraries were constantly incompatible with a new version of IDE. Make sure the contractor has a thorough plan on software updates.

4. Open-source platforms vulnerabilities

   It’s a well-known fact that open-source platforms have weak security. Products developed with an open-source solution require much more time for their management and support. It’s not infrequent that such software gets hacked. So, either consider utilizing a commercial solution or work on your security level very well.

5. No code commenting

   The code comments absence is a very common mistake among developers. They are important for other specialists to understand what the code does. So, if you get the code and it lacks comments, most likely, you’ll need to spend a zillion hours to understand it. Ensure the requirement to add comments is stated in your agreement with a contractor.

6. No documentation exists

   A development company needs to have the necessary documents on this or that project. When working with a contractor, you need to emphasize right away that both user’s and internal documentation is a must. The former tells people how to use the product, while the latter describes how and why the product was built this way.

7. Weak client-server architecture

   From the item name, it is clear that the weak infrastructure results in additional issues. If a server is built, so it fails to process multiple user requests, then the whole architecture requires redevelopment and hardening. When starting your partnership with a contractor, it’s essential to discuss the client-server architecture plan.

8. Junior-level developers on a project

   I have nothing against junior developers. I do hire such guys, teach them, and they grow as specialists. Every junior-level specialist in my company has a mentor, and none of the junior’s work goes by without being checked by someone experienced. However, it is very common for development companies to put junior developers on a project and just let them do the job. So, if you want to get exactly what you ordered, make sure to discuss the level of specialists involved in the project.

As you may understand, this list can be very long. To cut a long story short, other tech issues may include the absence of unit tests, non-compliance with international standards, and no regular framework updates. These issues might lead to the point when harm to your business is very significant, and you need to take extra measures. So, to avoid taking it so far that you are in deep stress, think of your agreement with a contractor beforehand.

So, how can you level down the dependence on contractors?

If you are in the very beginning of your relationship with the contractor or have many years of cooperation behind, there is always some room for improvement. Business process optimization is the key to success. With that in mind, most companies consider their cooperation with Managed Service Providers. What is the point of having someone else outside of your team? The most significant advantage of having an MSP between you and the contractor is reliability, time, and cost cutout, and you always hold someone responsible for the product’s stability and efficiency. When hiring a managed IT support services company, you can focus on promoting your business, and completely forget about all the tech issues.

Moreover, this is exactly how you can get less dependent on a contractor. A third-party MSP company will run all the support and administrational processes. This doesn’t mean you are going to be reliant on someone else! The benefits of this cooperation lie in the MSP’s approach. They are not the owners of the source code, but you are, and such a company just supports your product to satisfy both users and owners.

All in all, by setting the process the way it should go, you’ll significantly reduce the possibility of having force-majeure situations.

What should the correct process look like?

Our whole universe complies with rules. So, it is very natural to adopt some of them and the optimum process order to your business, especially when outsourcing some of the tech tasks. Some of these simple rules can help you to significantly minimize your reliance on the contractor:

• demand the documentation for every project - in this way, you’ll make it easier for your IT team or an MSP to hop on the train and learn the nuances of this or that solution;
• check if they use popular modern technologies - this step must be discussed at the very beginning. You don’t want your product to be developed with a technology that’s on its last legs; its support would cost you a fortune;
• make sure they don’t reinvent the wheel – all the good and proven code is kept in different available libraries. No need to write something from scratch, at least in most cases;
• agree on code commenting – commenting is as important as the code quality. It always helps to make the maintenance smoother and detecting bugs faster. When managing a contractor through an MSP, the best option is setting up a CI/CD pipeline. Such an approach is considered to be one of the most efficient practices for the managed support teams to implement. It includes a list of certain steps that must be done to deliver a new software version using the right CI/CD pipeline tools. It enables the software development specialists to focus on the code’s high quality, business requirements, and security.

Let’s discuss this in detail.

1. The source code.

   In most cases, the contractor is the only party that knows what the software is built with, how the environment is set up, how to access the production, and they are the only people who can fix the software if it goes down. That is a wrong approach. In my opinion, everything should start with building the CI/CD pipeline. And the first step here is the source code transfer through the source management software. The most popular solution for these purposes is Git.

2. The project documentation.

   As I have already mentioned, you need to state in the agreement with a contractor that the documentation, both for users and for internal use, must be present. Depending on the practice you stick to (agile, waterfall, etc.), the set of documents will differ. However, the most common are:

   • system documentation: product requirements, architecture, product roadmap, source code documentation, UX design documents, testing documentation;
   • user documentation: end-user documentation, sysadmin documentation;
   • process documentation: plan, scheduling, estimates, reports, statistics, different working papers.

   With that being done, you are on the same page with the contractor.

3. The deployment stage.

   System administrators or DevOps specialists deploy the application in both stage and production environments. Therefore the contractor is not the only one who can fix the software in case of emergency. So, when a contractor updates the application or adds new features at the client’s request, they put the code to Git, then it goes to the stage environment, and only after all the tests does it get to production.

Three ways of setting up the right process

Such a scheme, Client → MSP ← Contractor, can be performed in three options:

• Hire a system administrator or a DevOps specialist for your IT team.

  It’s the minimum number of specialists you would need, as the support process usually involves developers, QA specialists, etc. If there’s no need for further product development and it’s only about the support, then the sysadmin would be quite enough. Moreover, hiring a full-time specialist is extremely unprofitable if their working capacity would be around 12–14 h a month.

  That’s a pricey option, as having such specialists on board is not only about the wage. There are also other expenses, such as workplace organization. It includes expensive hardware (along with some software), paid vacation, sick leave, and insurance, etc. Though just hiring a DevOps specialist won’t resolve your main issues, there should also be set up certain infrastructure, which is another expenditure item. No doubt that is a good option, as such specialists are always there, in the office, so you can control them and see their pure efficiency. However, before choosing this way, it would be best to calculate possible expenses and check them against the company’s income.

• The contractor can perform the support of the software.

  Such a model of cooperation also works. However, it has way more cons and risks. On the one hand, the contractor knows the product better than anyone and can solve almost any issue. On the other hand, support is not their primary duty, and they’ve got no domain experts in that field. What if you have several software products from different contractors? To me, that is impossible to have that many remote specialists from different companies you need to control. That is very risky; no one excludes the human factor. So, when deciding on this option, it’s better to study all the pros and cons and have a good conversation with the contractor.

• From our experience, outsourcing support and management to a third-party MSP company is the most effective approach. We’ve had multiple cases where outsourcing all the management tasks was a great solution for a client. That significantly improved their inner processes and overall company efficiency. Especially if you have multiple contractors and need someone to manage all the products delivered by them, this is a perfect option for you.

  Moreover, this is a money-saving option. Remote specialists are much cheaper than those in the office. When deciding on this approach, try to find a very experienced IT outsourcing services company. In this case, you will get access to new knowledge and get the possibility to improve and optimize current IT processes.

Conclusion

The outsourcing model has always been present in the IT industry and has its risks and benefits. With the beginning of the pandemic era, it’s here to stay for a long time. The IT outsourcing services market is growing yearly, and by the end of 2021, it’ll amount to around $413.72 billion. Just imagine how many different companies decide to outsource their tasks to contractors! And the biggest issues in this are their total reliance on the vendor and lack of a well-thought working process.

Overdependence on contractors is a common issue. However, there are multiple solutions. If you feel like you’re facing a loss of control over your software products, the IT expenses are growing rapidly, and the whole business may be at risk, this is the right time to think of a solution for your case. Whether you choose to hire an in-house specialist, outsource it to an MSP company, or leave it to your contractor, the decision must be made quickly. The longer the downtime, the more losses you accumulate - starting from tech issues and up to the company reputation. It is up to you what to choose!