So, given that 98% (assumption) of blogs are stupid, do you conclude that any given blogpost is 98% dumb? Or do you go looking for the 2%?
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.
Yep, what the author fails to account for is that even locally run projects have a chance of complete failure, and huge budget overruns. It isn't that outsourcing created the problem, poor project management likely created the problem - and it exists regardless of whether your developers are on- or off-site.
But, when they are "offsite" PLUS speak a different language, PLUS have a different work culture PLUS have different cultural expectations about feedback (won't correct the boss even when they're wrong) PLUS massive timezone issues PLUS import/export restrictions PLUS network issues, then perhaps the probability of failure just might be affected a teensy bit?
I work constantly on projects with developers across the seas. I very rarely experience any issues with language, culture, feedback, timezone, network, etc.
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.
Yeah, there are challenges, and yes, the risk is higher -- I don't try to pretend otherwise. But those challenges can be addressed if you're aware of them. Writing off outsourcing all together is pretty narrow-minded.
Exactly. To quote "Nearly 50% of outsourced projects fail outright, or fail to meet expectations". Compare that to "68% of companies are more likely to have a marginal project or outright failure" http://www.zdnet.com/blog/projectfailures/study-68-percent-o...
In that light, outsourcing actually looks pretty good.
I've worked for several companies that outsourced work. Only one project was what I would consider at all successful, and in that case, the US company was owned and managed by several people originally from China, and some development work was outsourced to China, to a company owned by the president's brother. How that managed to work, I'm still not completely sure, but it actually did, for the most part.
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.
The CHAOS report[1] shows that in the US in 2009, only 32% were successful and met expectations. If 50% of all outsourced projects fail or fail to meet expectations, it sounds like they're beating us.
Thank you - I was about to go looking for this, although I wasn't sure that Jim Johnson was still doing the survey (last one I saw was 6 or 7 years ago).
I've been involved in very successful and not-so successful efforts to outsource offshore. It takes a kind of discipline that's rare in startups. It's also not particularly compatible with lean or agile processes.
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?
I'm doing pretty agile stuff with my offshore team. I find that it's when I give out the two-three weeks tasks I get the most problems - two-three day tasks work perfect.
> 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.
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...
Good catch; as I commented in an earlier outsourcing thread today (http://news.ycombinator.com/item?id=1418199), for many companies this is just a cheaper way to fail and that does have value of a sort.
I have a couple of friends that managed large software development projects with global teams, one while at Microsoft and the other while at Autodesk. They both told me that outsourcing work to India was not seen as a way to cut costs but to instead acquire talent. That being said, as a small business person with limited development skills I do save money by outsourcing to India. But I take the time to thoroughly qualify my contractors, develop proper specs, and establish realistic expectations. I may spend significantly more time managing an overseas project than if I was working with a local or even American developer, but I currently have more time to invest than money. So there are the opposite ends of the spectrum...I imagine the middle ground can get pretty convoluted ;)
What I've seen is that outsourcing goes across the board.
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.
I agree, I lost tons of money outsourcing. That doesn't meen you can't leverage the global economy to find remote employees that require a lower salary.
I've seen it work well when an existing relationship exists between the company doing the outsourcing and the programmers being outsourced to.
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.
i agree with @mseebach ... if outsourcing done right can bring a lot of value to a company. it is important to know that not every function can be outsourced. on a high level, tasks which are repetitive can be considered for automation or outsourced.
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.
The problem is often, the company doesn't know how much activities actually cost. Often, balance sheets are political or they're manipulated by sales people to show the P&L numbers they want. They're also unaware of the cost/quality relationship. This is often assumed to be a flat graph.
Thanks for the comment. Just some meta-notes: Why didn't you reply to mseebach directly? Have you considered writing out abbreviations and capitalization?
I would like to see what the % of projects that are not outsourced fail for comparison. My guess is that bad projects with bad management contribute to both, more-so than outsourcing.
We just completed a large outsourced project that would have taken not just 4x the money by twice the time if we had tried to do it in-house. And at the end of the project, the labor overhead for in-house is low and sustainable.
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
About 90% of my direct experience with offshore developers (most of whom have been in India) has been bad. (Not all of it has been bad: I've known a few good ones from India and Uruguay, but they were the exception rather than rule.) I chalk this up to several factors. One, most so-called developers are bad, period, regardless of nationality. Second, in the low-cost developing nations that folks most associate with offshore development (India, the poster boy) the average years of experience is much lower. Third, there's the language, cultural and distance obstacles. And fourth, and possibly not least important factor: low prices mess up the quality-is-price signaling mechanism. Is a particular offshore developer seeking a low hourly rate purely due to geographical/economic effects? Or is it due to them being lower skilled or having less experience, or needing to take more hours or developers to do the same task? Perhaps it is a mix of these factors.
> One, most so-called developers are bad, period, regardless of nationality.
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.
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.