Hidden costs of software outsourcing

Published by

gopalshenoy

April 25, 2010

In my software product management career, I have worked with remote software development teams in India, China, Australia, Ukraine and the UK. In many of these cases, we were working with outsourcing partners. I have been wanting to write a post reflecting on what actions ensured success and what resulted in failures. It has been on my to do list for a while – like a year.

Software outsourcing is always pitched as easy to do. Common benefits that are advertised include 24-hour development day (they are coding while you are sleeping!) and the large cost benefits through hiring cheap but good talent off-shore. While there is an element of truth in this, it is also a double edged sword. The 24-hour development day can be advantageous or disastrous because a lot of bad decisions can be made by your partner team while you are sleeping. The time it takes to discover these and then rectify them is at least 48 hours. Developers overseas are also typically cheap to hire because of the favorable currency exchange rates, but if you don’t set up the right infrastructure, you could lose precious time and money because of bad architectural decisions, poor code quality, major integration issues etc.

Last week, I was forwarded a slide deck on outsourcing and its common pitfalls. This deck captures the valuable lessons I have learnt over the years working with software outsourcing partners. It in fact captures it better than I could possibly have.

This is a must read for anyone who is doing outsourcing, who has been burnt by it or who is looking to explore an outsourcing model for software development. Consider this a good 5-10 minute primer.

As full disclosure, Sitrus who has put this presentation together is the outsourcing partner in Ukraine that I had worked with and are one of the better ones I have worked with. I am not paid anything to pitch their name or to do this blog post.

Thoughts?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the column on the right.

5 responses to “Hidden costs of software outsourcing”

Joe Aggie

May 11, 2010

One of the main reasons why managers/directors choose out-sourcing over team-expansion is because it is easy to sell the idea to upper management or exective team with finance background. When you get a project (or almost about to get it), you cannot go tell your director that you need to hire two engineers and train them for two months. He will say “if you don’t know how to get it done with the team you have, I will find another manager”.

Reply
David Fulton

May 4, 2010

Gopal,
QSM Associates has amassed a lot of empirical data about the performance that can be achieved by a development team. They can also measure the performance of your development team and compare it to industry averages for similar teams. Lastly, they can estimate the impact of changing the methodology (Agile, waterfall, Extreme, Outsourced, etc.) of your development team. You can read more at http://wp.me/pRvZI-3J .

Incidentally, one of their conclusions is that outsourced development is not nearly as efficient as co-located development because there are many more communication paths which makes effective communication orders of magnitude more difficult.
-dave-

Reply
The Lama

May 2, 2010

I have been involved with many off shore dev teams, and none has worked to any level of satisfaction until I encountered the one at my current gig. Here are the reasons why it works:

1- Agile process: I have 6 scrum teams, 2 in US, and 4 offshore. Each team has its local tech lead engineer, 2 developers and one QA person. The scrum master and product owner are in US. There is no place to hide in this process. Everyone is accountable and decisions are discussed and made on the fly. No need to write a long winded spec to throw over the wall and hope that what comes back after 2 months is what you had hoped you’d get. Things move at lightening speed and at the end of each sprint (3 weeks, in my case) there is working code that one can see, test, demo and improve upon during subsequent sprints.

2- Same timezone: My development team is in South America, depending on time of the year, there is a maximum of two hours of difference – no worries about bad decisions while you are unreachable (needless to say, no more 4AM concalls)

3- Good communication: This has two parts. First, I have experienced better English skills with my Latin American team members than offshore teams from most other regions. (this is especially important for scrum teams where everyone MUST talk and ask questions). And two, Skype and IM – developers, product owner, QA, everyone involved is only a Skype call or IM ping away from each other at any time.

I have to admit that it was not easy to get the teams going with Agile, even though we picked this partner company because they are trained and experienced in Agile process. It took us about 3 sprints (about 2 months) to get things smoothed out but now I will not do it any other way with offsite resources (I guess offshore does not apply in my case since we’re all on the same land mass, per se).

Reply
Aravind S

April 26, 2010

I agree with you 100%. The company/person out-sourcing work has to go through a proper risk mitigation process & plan the transition before jumping at the outsourcing bandwagon.

For some reason I am unable to open/use the slide deck, and I tried this on a couple of browsers including IE 8. Can you please forward me the slide deck?

Reply
Srini

April 25, 2010

Agree with you Gopal. I am currently leading a team for offshore product development, and i see similar problems. The key is to find that right amount of balance where you can really leverage on the 24-hour dev day. My advice is design onshore, POC on shore and development offshore (Offshore team should be able to work for a week or two without having clarity issues). that said, it might not be true for every one, but that is what I have come to believe over the years as a Product Manager and also being involved in offshore product development efforts.

Requirements management, detailing,prioritization and validation of the work when u have offshore teams in the mix is very different.

Reply