The perils of outsourcing

read —
19 August 2014

There are probably hundreds, if not thousands of articles on the risks, and even the benefits of outsourcing to offshore companies.

The reality is that offshore development can be a valuable way of getting work done, and the output produced can be as good as an internal team.

The risks though are inherently high with the biggest being the communication breakdown and loss of urgency that comes with the disjointed offices.

This is the case for both English as a first, and English as a second language offices. I have experienced the effect that time-lag has on two offices and the 'us and them' mentality in a number of positions. It's almost unavoidable.

Where reputation is concerned the risk is far too great, especially when claiming to be a full service agency, though that's an entirely different discussion.

I recently consulted on a mess created by a company outsourcing work to Vietnam and not completely understanding how it should be handled.

In this particular case the client was educated enough that when the project commenced an immediate flurry of activity from Vietnam visible in Google Analytics seemed an unlikely coincidence.

A few days later they were asked a series of confusing questions via Olark about their shipping rules, and the various attributes of their products. These questions also came from someone in Vietnam. Interestingly the client wasn't at all upset or annoyed about the fact that the work was being completed offshore. They had enough confidence in the local company that they were willing to overlook this small aspect.

What resulted though was a project delivered that was so off the mark they couldn't ignore it.

Delving into the reasons that the agency outsourced it was evident that each reason was inherently flawed:

The deadline to build was too tight There were significant budgetary constraints An 'agile' approach was promised to make things faster In addition to this the actual body of work required wasn't completely understood, nor outlined properly so it was doomed to fail regardless of whether it was built in-house or offshore—but especially so offshore.

The reasons are particularly evident.

Fred Brooks talks about adding more bodies to a project that is already late will only delay it further in The Mythical Man-Month. Outsourcing for 'extra bodies' is a great way of achieving a significant delay.

We also know that budgetary constraints are exactly that; constraints. Making them somebody else's problem doesn't make them go away, just less obvious.

Trying to run any agile project is challenging enough with all stakeholders and contributors in the room, so abstracting the development team from the environment only complicates it further.

I'd argue that it is effectively impossible to run an agile project offshore without an immensely dedicated product owner.

The only way this project was going to succeed would have been to outline everything up front and run a good old fashioned Waterfall project.

This would allow the development team to work directly from great requirements documentation, business rules, wireframes, and considered UI documentation. Not creating these project artefacts is the best way to ask for one thing and receive a completely different implementation.

Budget constraints considered, the work involved in establishing a successful project is going to be a sizeable chunk and it's impossible to cut corners.

This isn't limited to offshore development. It's a problem that occurs frequently in the agency scene due a lack of understanding from internal stakeholders who don't manage their client's expectation well enough.

In reality this whole situation could have been avoided by simply not accepting the work, but it's understandable that revenue for an agency is critical. Refunds however, are catastrophic.

So the offshore outsourcing model isn't for the faint of heart, and may be more risky than simply declining the work.

Previous