The Hidden Cost of Retrenchments

More often, critical systems knowledge resides in the heads of people who stand to lose their jobs when the offshore team takes over. Coaxing employees to train their replacements is a no-win situation that many CIOs find themselves in. "You're basically asking them to dig their graves before you shoot them," says Beyman.

For employees who agree to participate in knowledge transfer before leaving the company, the task can be not only demoralizing, but downright boring. "I was an extreme programmer. I made people happy with my work on a day-to-day basis," says Scott Kirwin, a programmer and business analyst who had to transfer knowledge offshore at JP Morgan Chase and Bank One, among others. "I went from that to endless meetings, documentation up the wazoo. I was all of a sudden a bureaucrat and a paper pusher. It was frustrating, because I could fix something a whole lot faster than I could document it for someone who didn't have the same knowledge I have."

Companies that think they can retrench "expensive" local employees, replace them immediately with offshore workers, save some money, and stay flexible and productive are deluding themselves. Kirwin compares the notion to cutting off your arm to lose weight. "While you will drop a few pounds," says Kirwin, "you won't be able to play baseball or climb mountains very well."

Even if there is documentation available or a retrenched employee agrees to stay on to download his knowledge of an application or process, the technical composition of a system is only a tiny piece of the knowledge that must be passed on. The language the application is written in, the hardware used, the location of the subsystems - that's the easy stuff.

But, "if you're talking about an existing system, there's a fair amount of knowledge transfer required not only on the technical side, but on the business side", says Beyman, who discovered that problem when he offshored Lehman Brothers' mainframe settlement system. He found the offshore workers didn't know what certain processes meant, such as "cornering a security" or "delivering a bond". "It's difficult to support that system if you don't understand the context of what the code is doing," says Beyman, who initiated training classes on Lehman's business for the offshore workers.

"There's so much tribal knowledge sitting in people's heads that even if you sit down to document things, you miss out on quite a few things that you only remember when a problem happens," says Pavan Nigam, CEO of Cendura, a software company that offshores development to its satellite office in Hyderabad, India.

That's the breaking point for many offshore projects. "Domain knowledge [the context of the work] is the part of knowledge transfer that people typically point to as a cause of failure," says Erran Carmel, associate professor at American University's Kogod School of Business. "Other pieces of knowledge transfer can create big difficulties, but outright failures usually have to do with domain knowledge."

At Life Time Fitness, the offshore workers had no domain expertise and, as a result, little understanding of what the user community would want from the system. And they were neither inclined to, nor properly prepared to, acquire that kind of knowledge. Bertch says it was a cultural thing. "There's a tendency with the offshore vendors to want to collect requirements and streamline the deliverable to produce anything that might meet the requirements, even if what they're producing isn't optimal," explains Bertch. "They're not thinking about how a system is going to be received or how it will provide value."

In addition, Life Time CIO Zempl discovered that his in-house programmers, with up to 20 years of experience, had a host of skills - such as communication and deductive abilities - that they could never fully transfer to the Indian programmers, who had an average of just two years on the job. No documentation could fill that void. "When you're building something new, you can't underestimate the value of experience," says a sadder but wiser Zempl. "Requirements can never predict everything, and experienced software developers can bridge a lot of gaps."