The Outsourcing Low Cost Lie
lessonsoffailure.com
lessonsoffailure.com
Did the failing projects fail because of outsourcing? Or was it bound to fail anyway because of unrealistic expectations?
Outsourcing done right can bring a lot of benefits, not just in cost, but also in flexibility if you're small. If, on the other hand, you think you can flick your wrist in the general direction of the shore, and have high quality software materialize it self, you're bound to fail - but that strategy was going to fail with local developers, too.
An essential reality is that you can't outsource your vision, in exactly the same way you can't get local employees to buy into your vision by sticking it in a PPT on the intranet and never talk about it again.
The difference is in management and due-diligence when choosing the developers. Every developer I work with overseas is someone who has come highly recommended or with whom I've worked on a project in the past. And that is a great way to do things, whether working with overseas developers or local.
In that light, outsourcing actually looks pretty good.
In the other cases, the costs were much greater than expected, both because the companies we outsourced work to did not perform as expected, and because we had to spend extra time managing them and correcting their mistakes. The poor quality of work by the company we outsourced to was the main reason I left one job - I just did not believe the company could survive given the quality of the product. Plus I was tired of putting in 60-80 hour weeks trying to make up for the crappy job they were doing.
[1] http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-...
True, unfortunately.
> Second, (...) the average years of experience is much lower.
That's easily addressable. Make your requirements clear. My outsourcer asks me what profile I want for every new hire on my team, advertises, interviews and tests, and gives me one or two resumes. I've been satisfied so far, but if I'd come back and said some guy isn't good enough, he would be replaced.
> Third, there's the language, cultural and distance obstacles
Language, again, is easy: no English, no hire. Cultural is the fun part, but that might just be me. Distance is workable. The US has South America, Europe has Eastern Europe and Near East. Africa should also be moving, but haven't had a chance to try working with anyone from there.
> And fourth, and possibly not least important factor: low prices mess up the quality-is-price signaling mechanism.
References can typically help here, but be prepared to build a relationship with a provider. You might get burned, but once you've got a mutually beneficial relationship, this goes away.
Do you have work for which iteration is not a major consideration? Do you have work which you understand well and for which you can clearly and completely communicate the requirements in written form? Do you have work for which it is straightforward to objectively test that milestones are being met and quality is being maintained?
When work has all those characteristics, how long would it take anyone?
As far as I can tell, the hardness of programming is the old "you don't know what you don't know". If you could completely specify what you needed, you would have ... written the program that does it.
An example would help. I could still believe this is possible...
> Do you have work which you understand well
This is critical either way -- if you didn't, how would you be able to do the work with a local team?
> and for which you can clearly and completely communicate the requirements in written form?
Be agile: train the developers like you'd train them locally. Put them in the chair of the user (mentally). Write usecases and userstories. Explain the goal of the application.
Again: how would you do this with a local team?
> Do you have work for which it is straightforward to objectively test that milestones are being met and quality is being maintained?
Yup, the same as I'd use with a local team the only one that matters: whether the client's satisfied. Pay your team by the month, just like you'd pay your local developers.
What is the percentage of "in-sourced" projects that fail?
I don't know the exact statistic, but I'm sure many software projects just flat out fail.
There are high-end outfits in India like Infosys that compete with the big consulting operations like IBM. They are cheaper than IBM but pricey compared with lower-end shops in the US. Those shops are world class and are as good as anything you'll find anywhere.
Other than that, you can have anything happen on an outsourced projects. Some of them go very well, but often they go bad... Sorta like farming work out to any development organization.
In our case, we have some Russian programmers working for us. They used to be permanent employees here, but have since moved back to Russia. The quality is known (high), and deadlines are met.
However, whenever any of the big outsourcing companies have been involved it has always been a disaster: More expensive than local when the project finally reaches completion (that's if it does), incredibly variable rates of quality, poor communication, continual programmer attrition.
to me, outsourcing is the easy part, to ensure and measure the quality of service/products delivered from the outsourcing effort is the challenging part. much easy if u r a small startup, but if u r like ibm, it is not easy to determine what to outsource and how to measure the roi of outsourcing.
1. Come up with a provocative blog post. 2. Write a whole lot of shoddy math to prove your title thesis 3. Extrapolate that your tiny sample set of anecdotal experience encompasses the entirety of the problem 4. Publish