True-Life Tales: Outsourcing Problems

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles The Art of Management in Outsourcing Crafting an Exit Strategy Getting the Service Levels You Expect with Outsourcing
	Discussion Forum "If you are in the US and your outsourcing team is in India, they may not really see the importance or value of what they are doing, to you and your firm. In such cases, motivation is hard to come by and people just go about their tasks as a routine..." Contribute to this Discussion

By Anonymous

My firm sells complex software applications for training management and skill tracking to medium and large companies. Back in 2003 we decided it was time to refresh our technology from Visual Basic 5 and Cold Fusion to .NET, so our investors gave us an infusion of cash. But rather than ramp up internal tech staff here, we decided to try outsourcing for the development of the new product.

As the product "visionary," I was in charge of the effort. I read a lot of articles and talked with people who had done it. We found a company in Pune, India that had expertise in corporate training. So we did a pilot project with them -- which showed some glitches but nothing we couldn't work out. We checked their references, which were rock solid, then had them bring over a business analyst for a month. He really seemed to understand everything we were trying to accomplish with the new product. I really felt like we did all the right things.

The business analyst -- who was razor-sharp and knew what we were trying to accomplish -- returned home. Since we had another project to finish up on a tight deadline, we relied on him to translate our requirements into detailed specifications. First mistake.

By the time I looked up again, four months had passed. Did I ever check the specs he'd come out with? Not really. Did the specs leave anything out? Of course. Two major components that provided the advantages that we were looking for with the new release were completely missing. (I know we'd discussed those components with him, because they were part of an itemized list I'd given him early on.)

Every week the team in India would send us a weekly status report that was a page or two long about the progress they were making and any design questions they had. We'd look it over and say, "That looks good," and then jump back into what we were doing.

It was only when we'd finally finished our project and could really devote time to looking over what they were working on that we realized something was really wrong. In fact, it was so wrong, we decided to can the code and start over again -- with the same company.

Initially, we tried to hold phone conversations, but on their side it was in a conference room with a speaker phone. There was a one-second delay from here to India, and with the accents and language, we finally realized it wasn't working. So we switched to instant messenger chatting.

All along, as we freaked out in new and different ways, they were wonderful. Did everything we asked them to do.

But that doesn't mitigate the fact that we ended up taking on writing the specifications ourselves and that with every problem that surfaced, it took four times longer to resolve with the Indian team.

For instance, it's a complicated process to assemble a course, especially when it's not structured. We had an issue about how it was going to work. The in-house team got together, discussed the pros and cons, and worked it out. But communicating that to the Indian team was a challenge. We sent them emails, but maybe we didn't word things properly. We'd try to avoid slang, abbreviations and anything else we could think of, because otherwise, they'd ask for clarification, which just slowed down the whole process. What we resolved in an hour here was taking three or four days of communication back and forth to make sure they understood.

Plus, within a year, in India, we lost our project leader, project manager, one programmer, and even our sales rep. There was just a lot of turnover. People were changing jobs and getting more money. We would have these chats and would say, "Where is so and so?" They would say, "You need to talk to your rep about that." "Why do we have to talk to out rep about that?" We'd finally get a hold of the rep and he'd say that he had resigned and was no longer with the company. He'd been gone three weeks. We'd ask, "Why are you just now telling us this?" Their project leaders weren't allowed to talk to us about anything negative.

So, our initial estimate for this project was off easily by 75%. As a small company, this kind of delay was significant. We had to explain the delay to our customers, investors, sales people and employees.

Plus, they're on a 56k line, and that was something we only found out about recently. We never asked -- we just didn't think about it.

At some point I expect the hassles won't be worth the cost savings. Right now we're paying the India company about $3,000 per programmer. They have six on our project.

Plus, we have to extend the contract with the company in India. They are trying to raise their rates. Because of all this job-hopping, they have to pay more to attract new people. Plus, there's rate exchange pressure. We pay in US dollars, but if it was 500 rupees before, now they only get 400 rupees.

And because this thing has come in more complex than we were expecting, I just know we're going to have to contract with them to maintain the code, which is another thing we didn't anticipate. It's going to be a long-term relationship.

My guess is that in about five years, people will no longer see a price advantage -- because I can now get local help for a lot less than what I was paying just a few years ago.

What advice would I offer you? First, don't expect this to be as smooth as your other projects. Also, the cost is going to be higher than you anticipate. The time it takes is not going to be an advantage. We were led to believe that while we are sleeping, the India team would be coding. We would come in the next day, review the code and make suggestions and changes and find bugs. Then while we were sleeping, they would be fixing the code, so that should speed the process. If anything, the opposite has happened. Sending emails back and forth and trying to explicitly explain in our best English what it is we're trying to accomplish just takes a lot longer than it does internally. Last, there's a high cost to managing the project -- 40% to 50% on top of the price we're paying for the programming work itself.

At times I thought about cancelling the project, but we were too deep in to do that. Saving money isn't always an easy matter.

About the Author: