Outsourcing: Raise the bar. Share revenue.

Michael Fields of KANA writes about "Back Shoring" - moving software development back to America. Fields, CEO at KANA, moved the software development operation from India to the U.S. and that, he says, "was the best move for KANA".

He makes some important points we need to understand. First, he says,

As a small company, IP is a critical part of KANA's asset base - one that deserves full control and protection. Globalization is a powerful force. But I believe it is important to outsource only those things that enhance the success of your product delivery without outsourcing the core product engineering.

Every company wants to protect its IP. But what American companies like KANA do not realise, though, is that you could give the source code of highest revenue product in the world - Microsoft Windows or Office - to a company like Infosys or TCS, and they just will not know what to do with it.

Most likely, they'll go up to a Fortune 500 company and say "We can build you an email client that looks just like Outlook".

The IP protection argument is sound, but in another angle: Indian IT companies routinely "switch" developers between clients, because they need to continuously balance resources. Obviously the developers will then "borrow" code from their immediate past, simply by accessing shared source, or ask their colleagues to mail it over. Code simply flows, and concepts are easily shared. If you have a new or brilliant idea you don't want anyone else to see, don't outsource it.

Fields then goes on to say:

Indian developers have a very high level of skills. It's no wonder that executives become fixated on the fact that you can hire 2-3 Indian programmers for the cost of one U.S. programmer.

However I would be willing to bet that few software vendors have an idea of the TCO of their offshoring operation. For KANA, the competitive labor market in India meant that we had little control over who was working on our projects. There was no way to curb high turnover rates, control labor cost increases or to hold onto key talent.

This is crucial to understand. That Indian IT companies switch developers midway through a project is a not-too-well kept secret, and the effects of this, and the higher turnover, labour cost, managerial cost (KANA kept a program manager for every five engineers) and travel ensured a much lower ROI than expected.

Why do Indian IT companies switch resources between clients? Think of it this way: you get paid per engineer per month. To impress a new customer (Say A) , you use your best engineers on a project, and pour in a few riff-raff (i.e. less talented folks or fresh recruits) for supplementary work. Soon, A is happy and increases staffing.

At this point, you get another new customer (B) you need to impress. The number of high quality staff you have is limited - typically only 1 in 10 people you have is of the high standard a new customer expects. (My experience) You then pull out the smart guy from A's project, hoping that the others, including the "riff-raff", would be capable of taking on A's work. This rarely, if ever, happens, and combined with turnover, causes A's product to be delayed, shoddy or both. Guess what though, you get paid both by A and by B.

A's happy experiences the first time around make then stay - "this might be an exception". But it's not. It was always going to happen, and will continue to happen because the Indian IT business model works that way.

You might think this is equivalent to the good guy leaving the company. It's actually worse: if a person resigns, someone else ALWAYS takes on the work, and the company may even hire a new smart person or move someone from the bench. But if he's still there, but just on a different project, the rest of the team depends on him for inputs, and the company thinks he's always there for backup. This is the beginning of a disaster; not usually a catastrophe, but a disaster nevertheless.

Fields says attrition and hiring issues are rampant in the US as well, but with the downturn, reality has sunk in and "U.S. developers are simply not pricing themselves out of the market anymore.". Indian developers have just no idea how bad a downturn can be, so pricing pressures will exist until the s*** hits the fan.

Interestingly, Fields comments:

Software development is really a collaborative process. Typically an architect sets forth specifications for development. Then as the programmer works, he or she thinks of new techniques to improve scalability and performance. The programmer and the architect come together, make changes and continue to work in such a cycle.

This process is very difficult to re-create when teams are interacting around the world. We found that our offshore developers often told us, "Here's what we built, exactly as you wanted - but it won't work, and here's why."

Deja vu, all over again? (thank you, Yogi Berra) I agree soooo much. There is NO business reason that the Indian IT company should bother to correct the problem. If they get paid on time spent, they would rather spend the time and then ask questions.

You might think - Well, pay them a fixed price then! Ha. I thought this was the answer too - but that solves no problem at all. Fixed bid contracts need fixed specifications. If you want a collaborative process then you will spend all the time just "freezing" your specifications, and then you'll realise you have to change something drastic, and the whole model falls apart. Also, you're then hiring code monkeys, not software developers - after all, if no inputs are allowed after a specification is frozen, the developers wouldn't even want to think about whether it will make a positive impact! (The IT company will ask you

Communication is also inefficient - There's no "coffee room chat" and the ideas you get by simply bonding with other developers. The time difference destroys innovation by removing the developer interaction with the business people - or even, as Fields notices, between developers. A product company does not benefit by stifling innovation, and time zones are not really in our control.

Fields concludes, quite appropriately, with the results: "For every 3 to 4 programmers in India, we are now able to hire 1 American programmer to deliver an equal level of productivity."

Okay, we have a problem. What's the solution?

S. Sadagopan at Satyam writes about managing offshore costs. He suggests that solution is to look closely at costs, that the best cost is not the lowest, but more closely aligned with value provided. (That's good, but how do you measure value until you've spent the money?)

Sadagopan also provides 10 steps to manage outsourcing costs - including resource backups, better vendor tools/reports, ignoring short-term spikes/troughs etc.

This, I think is simply the wrong approach. Better reports and resource backups are great for a manufacturing process, which software development is not. What a software product company wants from their Indian outsourcer is greater buy-in. What Sadagopan mentions as "a shared risk model" is the only way forward, but as a "shared revenue model".

The shared revenue model is self explanatory; the Indian company makes a percentage of gains made - and shares a percentage of losses. What's different from a shared risk model? Typically shared risk involve a minimum payment per month, and a "bonus" based on gains made. The upside/downside is not significant - and causes very little bottomline difference to the Indian outsourcing company.

So what really is different in shared revenue? That each party actually buys in. Let's say an company - call it AmCo - wants to outsource to an Indian IT company ("Indo"). Indo will buy a certain part of AmCo, part of the IT resources and even IP. This can be structured even as debt between Amco and Indo, including monthly payments to keep Indo running.

Indo will then work closely with Amco and refine the product so that gains are real. These real gains are then shared between the companies, and the debt (if any) gets written off slowly - eventually the debt goes away and both companies make money.

The downside is that if the project fails, Indo has the debt on its books to repay. Indo will do everything it can to avoid that. Put it's best developers on the project, do the coffee room video conferencing if it has to, build quality resources instead of "riff raff". Oh and with visible upsides, Indo can even provide product performance related bonuses to staff - attrition and movement is controlled.

But Amco loses it's IP, and part of future revenues! Well, there can be a buyback agreement in place, but frankly, Amco benefits from having Indo own equity in the project. After all, Indo's reasons for succeeding including making Amco's products successful!

Do I recommend this for every project? Well, if there are real gains to be made from the project. But do not use a shared revenue model:

• If Amco didn't have the budget to use local staff, and outsourced purely to get things done at a lower cost, don't use this model.
  
• If Indo doesn't give a hoot about debt on its books, and takes the project purely as an "I'll do whatever gives me money".
  
• If Indo asks no questions about the revenue model, marketing efforts, cost gains and so on. "Buy in" means informed decision making - and if one party asks for no information, something is wrong.
• If Amco has no process to measure the revenue/cost gains accurately and have you know. How would Indo know how much it earns?
• If Amco doesn't want to give out IP. But then it faces the same issues as our friend, Mr. Fields, did.
  

Shared revenue models are about raising the bar. It's not just about the software development process, but the entire business itself! That's a big leap forward. Let me give you an example.

An insurance software, developed using the shared revenue model, has increased premium revenues and decreased claims processing costs shared between the insurance company and the outsourcer. The software development is spread across 5 phases, and each phase has additional revenue. From an initial web based software specified the outsourcer enhances product revenue using mobile technologies, across countries/languages, and cross sell with other companies - purely because it's equity in the project makes it interested enough to explore these options.

I think it's possible, and the balance sheets of some of the Indian IT companies are now big enough to take this on. But the question is, will they do it?