Outsourcing : The Pitfalls

---

This article aims to give a few hints in how to avoid the pitfalls of outsourcing. It's not an sermon against outsourcing, I mean, there a few good reasons that can justify resorting to outsourcing.  
​

• The contractor has more experience on that task
• The contractor can make that task cheaper
• The contractor can make that task faster
• We can't possibly do it ourselves at this point

Normally, we hope that everything will go according to plans,  job done according to our wishes and delivered on time, but reality unveils a different scenario.

There are a few considerations that are often forgotten or even unexpected that can hamper the effectiveness of the outsourcing, hence, yielding the outsourcing more costly than initially foreseen, sometimes surpassing the cost of an internal development.

Do we really know the contractor ?

This is a trivial one and easy to fix. Taking the time to visit the contractor and meeting with the team that will perform the task is a good investment. Don't trust solely on company history. While living in an age where mobility is dominant, basing the competence of a company on its track-record doesn't offer much assurance. Know-how is not a company owned asset, it's distributed among its employees. 

There is this saying that if you go to a restaurant, the level of hygiene of the toilet, is a good indication of the hygiene in the kitchen. This principle can be applied to companies. If you allow yourself to go to the company and check the quality of the equipment at the laboratory, the validity of the software tools or even the elementary office material you can get some clues. A company that doesn't reinvest in itself is not a good indicator. In case of doubt just ask about it, if there isn't a good justification coming up, be wary.

Added Paperwork and bureaucracy

First time it was like this. All the mandatory Contracts, Non-Disclosure Agreements, Work Descriptions and Payment Schedules were finally agreed by me, my boss, the contractor and the two respective lawyers. I took a deep breath and thought - "Jeeezz!! That was painful. Even writing User Manuals is more fun than this. Weeks ping-ponging e-mails and just dreaming that things would go faster, but now it's over".

Well, not quite. All communications should be minuted and reported, any small change, even if it implies just an extra-day, must be negotiated, authorised and signed. Even if it doesn't, but deviates from the original, it needs an addendum.

In India, and I guess other emerging countries, small consulting businesses, profiting from the favouring financial conditions, and a high demand for lower cost, have grown small consulting companies into a multi-million dollar behemoths. In consequence, the level of bureaucracy also increased, with an almost daunting amount of procedures and rules designed to cover the arse of the contractor. 

Suggestion: Always prefer a contractor that allows a direct interaction with the person executing the task, and be wary of "templates", "forms" or any kind of normalisation process that is in place.

Writing comprehensive specifications

When dealing with complex systems, such as software or hardware, writing good specifications is a time consuming task. Writing specs that will be executed by a contractor is more so.

No matter how good the specification is, there always will be some discussion points. Account for enough time for a specification to mature over a couple of iterations with the contractor. Do remember that a good start can save a lot of time later on. 

All this to say, that this time spent on getting the project running accounts as an extra cost to be accounted for.

Regular Checkpoints

Make sure to set on the development plan regular checkpoints where the course of the development can be controlled. This of course, will take time and the concentration of internal workers. But, failing to do so, you might later discover that a wrong assumption taken 2 months ago made the project unusable for purpose.

Cultural differences

When dealing with people from another land, country or continent, people expect to meet the same patterns of behaviour that they are used to. The same reaction to command, the same understanding to suggesting, the same reaction to critique and so on. 

Not going to make a dissertation on differences between collectivist and individualist cultures, because the differences are indeed big and then further enhanced by gender, age and status. In summary, cultural differences often get in the way of understanding. 

For the sake of this article, what I am more interested in raising the point that cultural differences do indeed add complexity and cost to the project.

For example, I was very surprised to discover that a simple suggestion was turned into a high priority task by an engineer in India. Another time, luckily I was warned in advance by an seasoned engineer that a particular chinese engineer had a problem in saying no, but later failing to deliver. Finally, don't be surprised if in a conference call with India to discuss a minor change, you have 10 people in the other end of the line.

Finally there is the aspect of language. Although English language has pretty much occupied all the business space, the fact remains that not all speak the same English. Differences in accent sometimes add noise to the communication channel.

Diverging Goals

The chief concern of a sub-contractor is to maximise their margins, gain knowledge and curricula that can leverage the next contract. The concern of  the people you have working for your company is the wellbeing of your company. At least is should be, if not, then you have a bigger problem you should be addressing. 

Quality Assurance

Once the product is delivered, it's time to open the package and make the quality control.

It's again a time and cost consuming task and often left out of the planning/budget. Even if resorting to strategies such as "sampling" is a time consuming task, but one that needs to be done.

Here is where normally problems are found and often too late to send back. Saw this happening a couple of times, where rework had to be made internally, at the expenses of the company.

Suggestion: be sure to include in the contract clauses that hold the payment of last milestones if quality assurance fails. Of course, this is only effective if a big percentage of the payment is reserved for delivery acceptance.

Maintenance

If all went well and the product is successfully launched to the market, time may come to make the maintenance to the product.  If by chance the part that was subcontracted needs a change, it's good that a description of the development environment and a consolidated document set be delivered together with the project.

Suggestion: If the maintenance of a software product is going to be transferred, ask for a virtual box containing the image of a development machine.

Avoid training your future competitor

One of problems of subcontracting  a huge part of the development, is that you are inevitably transferring internal know-how to the contractor. This risk always exists, even if you put anti-competition clauses in the contract. As said, know-how is not a company owned asset.
Suggestion: Avoid subcontracting sensitive parts of your system.

Other useful considerations

Subcontracting small tasks is often not effective, because the red-tape needed for setting up a contract will eat up any leverage that the subcontracting would give. 
​
Maybe obvious but worth mentioning, avoid subcontracting tasks that require constant vigilance in a different timezone. Reasoning is simple, each iteration costs a day. In such cases, the best is to insource the task, or in other words, to bring a consultant to do the task in-house.

I hope you found this article valuable.