The Curmudgeon Coder Rants and raves, tips and tricks from Aaron Korver, the curmudgeon coder

How to Succeed at Outsourcing

Outsourcing is becoming a very popular trend at large and medium sized companies. Who can really blame them though? The thought of having the same work done for less cost is very attractive. Less cost means more profit, which means bigger dividends for the shareholders. At least...that is the idea.

I've been on three different projects with four different outsourcing companies. On each project at the end MANAGEMENT deemed the project a success while EMPLOYEES saw it as a failure. Management's main criteria for success was the line item balance sheet. If that showed a bigger revenue than loss, success! The employees viewed success in a different way. They looked at the quality of the product, because ultimately, THEY were responsible for it.

And thus this leads to the body of this entry, how to make it so both management and the employees are happy with outsourcing a coding project.

The first step in success is to tighten up every single feedback loop your company has. If you are having weekly meetings make them bi-weekly. If management only meets once a month, make it bi-monthly. If the feedback loops in the project become smaller and more efficient, any problems will show up sooner than later. This should in effect make the communication across all boundaries of the project become stronger. And in my opinion, communication is the number one thing to make or break an outsourced project. Another very important feedback loop to tighten up are the code reviews.

Which leads us to step number two. Make it clear between the on-site team and the offshore team where the final authority in code quality. Code reviews are a necessity for a successful outsourcing projects. The employees need to be involved and see the code that is going into the project which they will have to maintain. This is where the code review comes into play. It should be made clear that the employees have the final word on accepting code into the source control system, and that the code will be reviewed.

Ah yes, step three is have excellent source control management. Development is going to be happening 24 hours of the day. So when one team sleeps, the other codes, and visa versa. If your source code control system (you do have one right?) is not managed properly, it will cause some very unexpected problems. Make sure all your branching, versioning, merging procedures are in place and well documented.

Step four is...documentation. Remember step one when I talked about communication? One part of communication is the written part, or documentation. Everything needs to be documented BEFORE you start a project. Not during, not after, before. You are hiring a whole team, department, company to do your work. If you don't provide precise direction as to how you want things to work, then it won't be as you want it. The unfortunate truth is that an outsourced project needs MORE documentation than an in-house one. Teams that are overshore tend not to call you at 4am to ask simple questions and instead make a decision for themselves. Thus, document every single thing.

Step five, commitment to steps 1 - 4. Everyone in the company needs to be onboard with doing the outsourcing thing. If only one developer is doing code reviews, that person will not catch everything. Management must recognize the time needed to do documentation and be willing to let the employees create the necessary docs.

Step six find the right outsourcing company. There are many many outsourcing companies in this world. Your company needs to do the due diligence and select the right one. In the end, the people will make the difference. For example, one outsourcing company was being used as a jumping point for junior developers. They would hire a "developer" who had taken a single class in Java. Then put that person to work on our project. The on-site team would then basically have to train this person how to code by continually rejecting that person's work. Admittedly, the person would in the end become better, but then they would leave for a hiring paying company. Thus, starting the cycle all over again. If a bit of scrutiny was done before hand by my company, it would have saved us quite a lot of time.

Step seven your on-site team must be able to talk directly with the outsource team. Outsourcing companies seem to want to protect their developers. This will lead to questions being filtered through one person and a stone wall erected between the developer teams. Remember step one? The teams need to be able to talk and discuss issues that may arise. Tunnelling all communication through one person creates an obvious bottleneck. Make sure that this is agreed upon before starting and that the channels are fully open. Publishing an e-mail list is one excellent way to acheive this. If the outsourcing company refuses this..refer to step six.

I'll stop with these seven steps. With any change comes pain, and outsourcing for the first time is a huge change. I hope that with these seven guidelines that everyone in your company can honestly say that it was worth outsourcing that project.

Posted at 02:37AM Jun 26, 2006 by Aaron in General  |  Comments[6]