Five things to look for in an Outsourcing Relationship

Google "Outsourcing to India", you'll likely run into this old article in the CIO magazine. Wait, wait, don't surf away because VERY LITTLE of this applies to you if aren't a Fortune 500 company or thereabouts, and especially if you're trying to get a PRODUCT built. Checklists with 500 variables to cull from 50 vendors? Multi-year deals? CMMI level 5? You must be kidding.

I've been on both sides of this supply-chain, we extensively used providers when I ran my outfit in Atlanta, including elance and guru.com. A stint back in the '90s and since a year ago, I've been on the supply side based in Bangalore. Well, I looked around, and couldn't find anything halfway decent that explains in a nutshell what to look for to find and manage a good partner. No wonder, you find these horror stories that proliferate in blogs…

---------------------------------------------------------------------------------------------------------------------------------
Here's an excerpt
---------------------------------------------------------------------------------------------------------------------------------
Some of the problems we encountered:

• Communication. You will never hear about problems until it is too late. It's a cultural thing. They lose face if they let someone know they don't know what they are doing or that the result is below par. The problem is that there is no way you can manage this and you cannot take actions. You end up with either a dropped project or a bad product. You need to have someone you trust on the ground.
• Infrastructure. Our team was in Mumbai. Many in high tech use Bangalore. The Internet and phone connections were awful and dropped four to five times a day.
• Loyalty. We noticed a dramatic change in resources constantly moving. People were always leaving for another 20% salary increase. It's all about cash and who will give you more.
• Micro Management. If you are to avoid some impact on lack of information sharing about any problem you must micro manage the project. Preferably, you need someone there full time, which we couldn't.
• Cost. Well, it looks cheaper on the surface but caveot emptor. In the end, this cost us more and we were throwing money away. Furthermore, it is not that cheap any longer.
• Quality. In short, we discovered that the code developed in India was either poor or eventually thrown away. Not very well invested time and money.

---------------------------------------------------------------------------------------------------------------------------------

Some of the problems have been mitigated with time -- infrastructure issues to an extent. Some simple checks and balances, however, would have been well worth the above gentleman's time, so here's is my list (sound like motherhood and apple pie, but aren't as obvious as they look on face value, so could use some elaboration that I'll provide in subsequent blog posts).

• Be absolutely positively clear about the expected outcome.
• A proactive project lead on the ground is worth their weight in gold.
• Demand full transparency
• Show up at your vendors offsite or offshore office, or have a friend show up without advance notice
• Chop the project up into well-defined frequent deliverables.

Notice I didn't mention "cost". Nor "expertise". Notice I didn't go anywhere near "size". They all matter, but none of these is likely to get you in deep doodoo as the five things above.

The Intellectual Property Scare

We start most interactions with prospective customers or vendors with a duly crafted Mutual NDA - for larger clients its mostly a CYA, while for the smaller outfits, I guess it provides a sense of security. That said, I've never had the occasion first or second hand to see any substantive breaches of these by anyone I know.

So when prospective customers do make a big deal out of it when sending out work to India, I'm frankly puzzled. Puzzled not because its not an issue -- there are horror stories, but because its all about common sense management of risk. So here are some things that will keep you safe so that you can focus on things that matter - like building better quality product and selling it to a large number of people.

#1. Honestly evaluate if you're at risk
I had a prospect who spent several days of his time and mine trying to figure how to protect his code base. His application? Available on the web for $19.99 per month unlimited usage. If I were a legitimate competitor, stealing his codebase would be the last thing on my mind.

#2. Know what's at risk
Years ago, we spent a lot of time consulting for large Telcos; at one of them, I was appalled to see the ease with which I could access its customer care information - including social security and credit card numbers. And this at a place teeming with contractors. They got lucky, nobody put that data on a CD and walked out.

When we outsourced our work, we spent a few hours classifying our assets into stuff (a) that could be sent out of the company with minimal risk - about 80% of what we had (b) needed to be obfuscated or dummied up - about 15% (c) under absolutely no circumstances should someone outside the core team have access to it - about 5%. It wasn't hard to do, and buys you a lot of peace of mind.

#3. Know your vendor
Its easy to do a reference check on your vendor. And ask a few questions about their internal practices - do they have separate repositories for each client/project? What kind of access restrictions and tracking do they do? What physical security do they have in place? Have someone local to help you do some due diligence - it's not hard to do.


These are steps you should be taking anyway, whether you're outsourcing or not. Maybe the possibility of sending your work out brought these issues to the forefront - think of it as a way to better your own practices than as an aggravation - your IP is important to you, isn't it?