How to Waste Millions Of Dollars With Outsourcing (or Make Millions)
July 10th, 2008 by Sameer | Filed under Software Engineering, Work Related.To management, the idea of outsourcing sounds very sexy…. The idea of producing the same content (code, or what not) at 1/2 or 1/3rd the cost is almost a wet dream for management, if I may be so bold. Even though it sounds great in theory, it’s actually a very tricky function to master. Here are some things I have learned with my outsourcing experience.
Keep in mind I am not discussing the outsourcing style of passing requirements and getting the end product complete. I am discussing the style of hiring outsiders and working with them on a daily basis.
You have to start by looking at what is the purpose of outsourcing. Is it to save money? Or is it to improve quality? Or is it so that your team can focus on other things? Get this straight first before going any further. My points below are in the context that you are a software company (or at least do some software development) and you are considering outsourcing to save money and cut costs.
From friends, I know that some very popular companies outsource, such as E-Trade Canada, Accenture, and recently the new online T.V. web site Hulu which outsourced its development to China.
- Before you start outsourcing, have your process solid - i.e. have regular scrum, know how much code you are generating each week, and so on. It’s very important that you have some idea of costs for developing software for your local team. If you have no idea, you won’t be able to see if you are really saving money or wasting it.
- Know velocities of individual team members so you can measure cost effectiveness of your outsourced work.
- Build your estimation skills. Read Joel’s article on estimation and his second article on estimation (which is really a promo for his bug tracking software but still worth reading) and Steve McConnell’s book on Software Estimation (highly recommended, very easy to understand).
- Get smart/able/competent guys. This can make or break your outsourcing project. If you are going to get developers that need baby sitting, then hire a baby sitter on their end to clean up their code, otherwise you are going to waste your valuable resources fixing and re-fixing and re-fixing their code. In this case you might not be actually saving money.
- Review their code. Someone on your side is going to have to review their code to make sure that they aren’t purposely obfuscating it in order to secure their jobs in the future. I have seen a Flash application that was built in this manner, the team overseas purposely messed up the code in such a way that it would be difficult for others to continue where they left off.
- Learn from those who have done it before. If not, you are going to mess up big time, in many ways. Might be worth getting a consultant who has been successful with such projects. Another idea is to find someone who has connections "back home", and go there to see how some of the shops work.
- Turnover is really high in India/Bangladesh/ and so on. This is because jobs start at really low salaries (like $200 a month) and go upwards to like $3000 a month (comparable to working in Canada or USA). You will need to find a way to solve this problem. Somehow you will need to get them to commit that guys will not drop like flies. This is so important because there is always an upfront cost to learn an application, and it becomes more as the complexity and lines of code increase.
- Consider a cross-cultural learning program, you send some people there for a while, they come over here for a while. A lot of big companies do this. It’s almost a must.
- For the team overseas, its important to spend your valuable time together in the beginning to ask lots of questions and understand the requirements as much as possible, in case there is a task that you run into questions, then leave it and work on something else.
Hamid, Axosoft CEO claims that Outsourcing is for Dummies. I think this isn’t true in all cases, as I have been able to apply outsourcing successfully on some small projects. However, it all depends on the case, and for building complicated software with a (geographically) fragmented team, you may just end up proving his point.
