A company that has its own software development capability is driven to outsource software development in an attempt to save money or reduce costs. The company’s management may say they’re doing it because they can’t find enough qualified staff locally (or quickly), or so they won’t have to build up an additional development facility, or that they are taking advantage of a particular skill that a supplier says it has. But these are all variants on the theme of saving money or reducing costs. And I submit that when the outsourcing is offshore, it’s always to save money.
Saving money is good (although it may have unintended consequences, which we’ll examine later this week). Saving money is good if it really happens. So, is outsourcing software development always a good idea? Do companies really save money by outsourcing? Ever?
In a previous blog titled “Friends Don’t Let Friends do Outsourcing”, the outsourcing experience wasn’t good. There have been many articles written in recent years about bad offshore outsourcing experiences. The bloom is apparently off the rose. Offshore outsourcing often results in failure of one kind or another (quality, schedule, even cost), and companies are rethinking this strategy.
I think these outsourcing experiences fail for many of the same reasons many in-house software developments fail. It’s just that the failures are more dramatic because offshore outsourcing is so much more difficult to manage and it is harder to recover. And for some reason, they usually come as a shock or surprise to upper management.
This week, I’ll make some suggestions about what should happen before an outsourcing decision is made, and what should happen during an outsourced development to make outsourcing work, or at least to find out as early as possible that it’s not going to work.
Some things to do before making the outsourcing decision:
1. Analyze your rationale for doing it. Do a realistic cost/benefit analysis. Don’t assume that just because it would take 20 in-house staff to do this work that you can get 20 cheaper developers in South Dakota or India to do the same work by the same deadline. Figure out what the real cost will be, and don’t forget the in-house staff that you’ll need to make sure the project is on track.
Ask yourself some questions about why you’re considering outsourcing:
· Is your staff too busy on other projects to do this work and do you think that a supplier has staff readily available to do your work?
· Do you think this is a quick, one-time job and that you only need staff temporarily and perhaps don’t want to hire? Have you considered hiring temporary contract labor to work in-house with your existing team?
· Does your staff lack some technical skills or domain expertise that a supplier says it has? Do you think it’s too expensive to train your staff?
· Do you just expect to reduce your development cost with cheaper staff because you think this job is easy? Have you considered all of the requirements to convince yourself that this really is easy? Have you asked your technical staff if they think it’s easy?
2. As a part of the cost/benefit analysis, analyze the risks and consider the costs associated with mitigating them. Often (usually) management assumes that by giving away software development to another company they also give away the risk, not realizing that they keep the primary management responsibility and most of the risk. The project manager will face all of the challenges of an in-house development plus many additional ones. The outsourced employees are part of another company with its own goals that are not the same as your company’s goals. They’re not right there with you to ask or answer questions. They have their own managers they must obey.
Unless you can assign a project manager who has training and experience managing outsourced projects, one that you trust to do the job right, there is a huge risk of failure.
Other risk questions might be:
· Will the supplier really be able to assign well-qualified engineers to your job?
· Will the supplier keep the best engineers on your job if other jobs come in to their company?
· Does the supplier understand your work?
· Is the supplier’s company sound?
Do you still think outsourcing is a good idea and will save you money? OK, just a couple more things to do before going forward with it: in my next post.
Great information you have shared through the blog. Looking up for more such type of detailed content.
SaaSonhand,
Define “best” ……… building software isn’t the same as producing widgets, some of the best software comes from the quality of communication and the connectedness of the developers with (and ideally part of) the decision making process.
You *cannot* do that when it’s out sourced, the motivations for completion are different.
So, I disagree as it’s regularly a problem.
Hence :
http://www.jeremyhutchings.com/2010/12/more-myths-of-software-outsourcing.html
I don’t think it’s a bad idea, it’s like trying out to get the best there is in all area of the planet. So long as there’s a great interaction between an employer and the developers…it wouldn’t be a problem.
I agree that when requirements are extremely firm (such as modification of a product that’s already built, whether localization/translation or porting), outsourcing can make sense and succeed.
Your third point is interesting. I think that, ultimately, the reason for the outsourcing was cost (the labor laws and absenteesim adding cost).
There are situations in which software development is outsourced offshore for reasons other than cost. Here are three examples:
1. The software needs to be customized for use in the country to which the development is outsourced.
2. Porting of software to many platforms is boring and repetitive. Offshore developers are willing to do this; inhouse developers grumble. WindRiver outsourced porting to VietNam for this reason in 2003-2004 and may still be doing so.
3. Labor laws are less stringent and the work force exhibits less absenteeism and tardiness in the outsourced country. This was the reason why a large German company outsourced to India the porting of software from mainframes to client server systems in the mid-90s.