making systems development outsourcing work

As an independent management consultant I often help clients optimise their IT outsource arrangements.  I do this based on my own experiences as a client for many years of systems development providers (onshore, nearshore and offshore), and as someone who also advises outsource firms on how best to meet client expectations for software delivery.  I confess that I am a big fan of the benefits that outsource suppliers can bring (eg access to stable, easily scalable teams with top quality technical resources) while acknowledging that outsourcing (partial or wholesale) brings its own problems.  I have also enjoyed building and leading successful in-house teams in the UK and US, and recognise the benefits of the in-house supplier (easier communications and stronger personal relationships) compared to the outsource option.  My most productive experiences where when strong in-house teams worked well with equally strong outsource teams in the same or different countries. In this short article I want to share some of the common issues that I encounter in my work on nearshore and offshore outsourcing, and some of the approaches that I have used to resolve these problems.  [NB many of these issues can also manifest when engaging with onshore suppliers].

The most common complaint from both suppliers and clients is that the outsourcing arrangement never fully meets original expectations.  Even when the initial project is completed successfully, clients often feel that making the arrangement work required far more effort on their part than they were expecting, and that relationships at the day-to-day working level were not as smooth as hoped (even when the technical quality of the work done was good).  Another common complaint from clients is that there was less value added over and above the simple completion of tasks.  Many clients (including me when I was a client) are hoping for suggestions for design improvements, technical innovation, and enhancements to the overall business systems architecture as a by-product.  For their part, suppliers become frustrated when engagements end when the original project is completed and/or the account never grows above the initial team size.  Here are some of the suggestions I make when I hear these issues:

  1. Be realistic.  Outsourcing rarely works perfectly straight out of the box with a new supplier.  I’ve used the very biggest to the very smallest suppliers, but in the end it is just people learning to work with other people.  All of the training and methodological awareness in the world doesn’t mitigate the need to learn each others styles, preferences and needs.
  2. Domain experience is always context dependent.  It never transfers 100%.  New contracts need to allow time for learning the specifics of the business; the details of an unfamiliar business systems architecture; and, the scope of the particular project.
  3. Take responsibility for making it work whichever side of the equation you are on.  It is not someone else’s job.  Some of the best supplier relationships that I had, had the worst possible starts and were teetering on collapse before issues were resolved.  The grass is not greener elsewhere, so get on with flushing out all of the issues in a safe environment with no blame or recriminations.  Whatever issues you have in this supplier relationship will manifest in all supplier relationships if you do not tackle them head on and learn something in the process.
  4. Suppliers cannot complain that the account did not grow or continue post initial project if they made no attempt to share their ideas for broadening their scope while they were delivering the first project.  The big consultancies are good at this – many suppliers could learn a lot from them.  I once found out by accident that my supplier felt that other aspects of our technical architecture were a mess, but they felt that it would be rude and inappropriate to tell me or my colleagues (even though that is exactly what we wanted).  My view is that suppliers should treat every engagement as the start of a long relationship, and act accordingly (even if it means taking risks by delivering bad news).
  5. Become expert at operating agile approaches to software development in large-scale geographically distributed environments.  Hire people with that expertise.  Don’t claim you can do it if you can’t, as that just leads to the worst aspects of waterfall methods being married with the worst aspects of agile methods (I see a lot of that).
  6. Communicate, communicate, communicate.  If you operate daily stand-ups via Skype etc, then make sure that everyone attends.  Do not hide team members behind a team-lead or the person with the best English.  Transparency is everything in outsourcing.
  7. Be sensitive to cultural differences, but avoid stereotyping or operating on false assumptions.  Some cultures are generally more comfortable with agile approaches, while others are generally more comfortable with well-planned structured sequential methods; but I have found significant exceptions to the rule.  Distance from your own country does not necessarily increase the culture gap.  Companies have cultures too – not just countries.
  8. Beware the dog and pony show.  The salesman in your office does not necessarily reflect the culture back at the ranch.  Always visit the offices of your potential outsource provider, and spend time with engineers – not just team leaders and account managers.  Regardless of technical expertise, not all companies will work well with your company.  Find one that feels like a good fit.
  9. Do not try to bankrupt your supplier.  Outsource suppliers work on slim margins as they believe (mistakenly in my opinion) that they are competing on price.  Of course outsourcing provides excellent value for money – but it provides a lot more than that as well.  Paying a fair rate reduces your risk as a client.  Accept that nearshore suppliers cannot match offshore rates, but they more than make up for the price difference in other areas.
  10. Do not underestimate the impact of time differences.  Structure your projects in a way that works with the time difference, rather than fighting the time difference.

I hope this reflection on personal experiences is helpful to someone somewhere!

Cliff Moyce

September 2013


2 thoughts on “making systems development outsourcing work

    1. cliffmoyce Post author

      Steve, one of the principal reasons that I use outsource firms is because the turnover is so low in many of those firms – especially in nearshore locations like Romania and Russia where loyalty is highly valued. One dedicated nearshore team I put in place eight years ago at Markit has only lost one person from c.20. I have found it increasingly difficult to maintain stable high quality in-house teams in London as the recruitment industry (and therefore the level of poaching) has boomed. When young men with families living in such an expensive location are being offered more money by highly desirable employers like Google and Goldman Sachs, you cannot blame them for leaving (even when they get lots of autonomy, support and development in your own firm). Cliff


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s