Slashdot Mirror
What Pitfalls Exist When Outsourcing Code?
mmmmbeer asks: "I have a question for anyone who has outsourced programming jobs to overseas companies. My company is considering doing this, which in theory will allow us to dump off a bunch of (supposed) 'grunt work' and free up our programmers to do other work. One of our management's reasons why they think this is good is because the contracting company can 'throw a bunch of coders on it' and therefore get it done quickly. To me this seems to violate Brooks's Law. We (the in-house programmers) are also worried that the learning curve will in fact be great enough that, even if the extra manpower works to their (and our) advantage, it could still be done faster and better in-house. My question is, has anyone had any experience with this, good or bad, and do you have any warnings or suggestions for us?"
There are dozens of other things to a development cycle than just oursourcing 'certain problems'...
Over the last few years I've had several opportunities to view the problem of outsourcing development from different perspectives. Primarily I've been in the business of picking up failed projects and teams and making them successful, but I've also lived abroad and run development projects from there.
I've seen projects fail when done by internal teams, US contractors, and overseas contractors. Although there are many reasons why projects fail, most projects fail because of poor leadership. Poor leadership can take many forms: failing to fire the jerk whose blowing smoke and slowing everyone down; applying too much, too little, or inappropriate processes; failing to apply pressure and set deliverables; applying too much pressure and setting unreasonable deliverables; poor communications; inadequate analysis; too much analysis; poor hiring practices, etc, etc, etc.
Adding contractors to the mix is not an always/never kind of deal. Contract/outsourcing (US) can solve a variety of problems. Generally it's done for a few different reasons: 1) managerial uncertainty (fear of failure), 2) missing temporary skill sets, 3) lack of strong internal development teams, 4) short term development needs greatly exceed long term needs. Of these, 2 and 4 are valid, whereas 1 and 4 are just looking for trouble. Hiring outsiders must be done to solve a SHORT TERM manpower need. This isn't to say that a manager who hires an outside company for the wrong reasons won't succeed, but it's definitely a roll of the dice.
Running an outside development project has ALL the same problems as running an inside one PLUS a few others.
The first thing to remember is that it's not a company that you're bringing in but a group of individuals who will act as a new development team on your behalf. Like any team, these people can have a range of skill levels. Many contracting companies won't be able to let you meet the developers they bring to the table before you've actually inked a deal (the big ones like AC, EY, KPMG, etc are especially bad in this respect). If you can meet the team and literally interview them before the fact, then you should. If you can't, then you have to be ready to get rid of people and ask for others at no cost to you. One of the impediments to doing this can be the project managers that such teams bring with them. Frankly, the PMs at consulting companies are probably much better than the PMs that most companies have internally. The one drawback they have is that they tend to protect the interests of the contracting company FIRST and your interests SECOND. This means that you need to be more aware of his or her individual tasks and activities than you would be of someone who works directly for you. (Manage the relationship closely).
The second thing that is critical is up front analysis. Most contracting companies want to come in and do a requirements/needs assessment first. The result of such an assessment should be a clear set of requirements and general documentation that will form the basis of your project definition. One of the problems with this is that the 100-page (mostly boilerplate) result is not the best way to help YOU understand your OWN requirements and needs. If you don't understand your OWN NEEDS, then failure is right around the corner. If you have the money and time, go ahead and let them do the assessment, but only after you have put together your own basic requirements. As your requirements are gathered make sure all the stakeholder are personally and INTIMATELY aware of the details of the requirements that are gathered. Remember that this process is garbage in garbage out. They may turn out a bunch of junk requirements if your stakeholders haven't taken the time to think through there own needs. Bringing in outsiders can give stakeholders a false sense that their needs will "automatically" be met. (Manage the relationship closely)
Assuming that you have "good requirements", whether generated internally or externally, the challenges aren't over. The nature of any sufficiently large development effort is some degree of iteractiveness. That means the developers need to be able to COMMUNICATE with a variety of people throughout your organization. Some of these people are technical, and some aren't. Either way, if communications breaks down or becomes formalized to death, you'll get something that "meets the requirements" even though the requirements are wrong. The internal/external nature of the relationship can make communications doubly difficult. Sometimes people may be knowingly or subconsciously sabotaging the effort (a developer unhappy that outsiders were brought in says "I'll just let them go ahead and fail" and sure enough they do). Communications, collaboration and intimacy are the nature of the game. (Manage the relationship closely)
The last issue is the final handoff. Products rarely meet all expectations, and most have some degree of fixing and maintenance after the fact. The final "handoff" usually involves a bunch of documentation (half to 2/3 of which is either boilerplate or wrong). Not surprisingly, this is not an ideal way to communicate. Most communication is an iterative two way process. Even face-to-face conversations frequently end with two people walking away with completely different ideas about what was said. If the team (or individual) who takes over the system doesn't adequately understand/respect what s/he's getting then you can pretty well bet that it'll get junked/gradually-rewritten-over-time. Ultimately, some period of phasing out is desirable to let the new and the old transfer adequate understanding/respect to allow the transfer to succeed. As long as you manage the relationship closely this can be done.
Those of you still unclear on the concept: manage the relationship closely.
Having said all that about US contracting, how does it all apply to overseas contracting? Generally there is only ever one reason for doing overseas contracting: money. There can be little doubt that this is a valid motive, but being cheap (and oversees contracting IS CHEAP) doesn't solve the problems of doing successful development.
Developers in other countries are just like developers here: some suck, some really suck, and some kick a??. Unfortunately, you'll not get the chance to meet to many if they live 10,000 miles away, so you'll have to pay more attention to the code and design documents. Remember: CODE IS TRUTH! Do regular code reviews, bring their milestones in house and have someone try to figure out how they work. If things are going badly, remember the principle of sunk costs and abandon-ship/demand immediate change. (Manage the relationship closely).
Foreign countries CAN mean language barriers. Make sure that individual goals and milestones are meeting your expectations. Don't let them go to far down a blind alley.
If you have the time to do these things, you have a well-defined project with well-defined goals, and you are lively and unprejudiced, then give it a shot. Unfortunately, at least one of these probably doesn't apply to you, so you should probably do it in house:)
Kevin Barnes
Sr VP of IT
OneSecure
kbarnes@onesecure.com
Mid last year my company was in a bind. We had a large amount of development to do, and not enough people to do it. The solution: off-shore outsourcing. We basically handed these guys all the specs, gave 'em a rundown and let them go. The end result can only be described as crap. I mean really, really bad. If you can think of a negative thing about out-sourcing, it happened. In the end I just re-wrote the lot.
The next attempt:
Late last year my company got another large project. Once again we did all the analysis and design, but didn't have the resources to code it in the time frame we had. Once again, we used an off-shore development house (the same one, even!). But this time, we sent two people over in a team leader / advisory role (I was one of them). This time it went much better. Here's a few of the benefits we saw:
- Because we had an interactive role with the outsourcers, we could identify any potential issues before they happened.
- We were able to teach them our coding/documentation standards and enforce them on a day-to-day basis rather than every other month. We did regular, on-site code reviews to make sure we didn't get sloppy code.
- Many of the out-source developers were hopelessly inexperienced in our development environment and the technologies used. We were able to identify the guys who were struggling and give them the extra attention they needed to keep up.
- Any specification ever written contains vaguries and some ambiguity - basically the issues for the programmer to figure out. If it didn't, then it's a waste of time - the person that wrote the spec may as well have written the code. Since we physically there, we could answer any questions that the guys came up with on the spot rather than waiting half a day or longer for email. This prevented huge amounts of potential misunderstanding.
- We were able to give consistant, regular feedback to our management on the state of the project. This was a big one. One of the problems with outsourcing is that the people you give the work to, because they're hanging on your money, are almost always hesitant to admit that they're struggling. With us there talking straight back to our management, there was none of that.
The end result: Quite simply, it worked. My company didn't get it at the absolute basement price they might have without sending people over to be part of the team, but it still turned out cheap, and the code worked.This was my experience with a company in India:
1. Difficult to get in touch with people because of the time difference (something like 12 hours ahead over there.) My cell phone wouldn't take incoming foreign calls nor could I make outgoing foreign calls (didn't want to pay for them anyway). This left me chained to my desk for 7:30 AM phone calls.
2. The calls and faxes will get expensive b/c all meetings must be conducted over the phone, not in person.
3. The company I dealt with made a lot of promises and did not deliver. They were given a site to reverse-engineer using a new technology (went from ASP to WebObjects). Even with source code and complete access to the server's configuration they were unable to complete the task without my team writing 80 pages of technical and functional specifications for them.
4. The time it took us to right the specs, we could have coded the site ourselves.
5. Certain foreign companies don't like women, it is a cultural thing. If the CTO (a woman) gave them instructions, they waited to confirm with the Project Manager (a man). This was problem for us. It may not be a problem for you.
6. The final code was mediocre and completely undocumented due to the language barrier.
7. If you go forward get a fixed price agreement for the complete project. Don't do any weekly rates or billing system that allows them to report hours. We were over budget by 25% because they took longer than promised.
8. Suffice to say, I would never do it again.
9. Good luck.