When IT executives at Life Time Fitness Inc., a fast-growing health and nutrition company, first considered sending systems development work offshore two years ago, they tried to do everything right.
They started off with a small pilot and used an Indian vendor they had already been working with. But that offshore team had worked solely at Life Time’s Eden Prairie, Minn., headquarters — not at its own Indian location. Even so, Life Time’s IT executives were happy with the team’s work and felt they had a good handle on the cultural and communication issues that sometimes arose. So in mid-2002 CIO Brent Zempl decided to take the next step: to truly offshore a pilot project — a non-mission-critical application used to analyze data for construction site selection.
He signed a contract with the same vendor the company had been working with. Their pitch “was very convincing,” recalls Wesley Bertch, Life Time’s director of information systems. “They had all of these processes — Six Sigma, CMM Level 5 — and said they could collect requirements and deliver the system on time and budget at or better than the level we could. So we went ahead.”
Problems cropped up immediately. The culprit was knowledge transfer. The offshore workers’ lack of programming experience and knowledge about the project and its origins, together with their faulty understanding of Life Time’s users’ needs and misperceptions about what constituted a successful project, hindered the documentation of system requirements. Life Time Fitness went over budget to bring one of its own technical writers into the process and extend the documentation process from two weeks to a month. Finally, the offshore liaison hopped a plane back to India, documentation in hand.
A few months later, the offshore team produced a data model. It was a disaster. “It had so many problems, we couldn’t even log all the defects in the week we had to do it,” Bertch recalls. “And that was just the database. When we went through the QA testing, screens would go blank. Data was lost.” The application wasn’t just user-unfriendly, it was unreliable and, therefore, unusable. “It was a major embarrassment for both sides,” Bertch recalls.
Ultimately, Zempl swallowed the financial loss and brought the system back in-house for his own programmers to rework. But not before learning a lifetime of lessons about offshore outsourcing, and the importance — and limitations — of the offshore knowledge transfer process.
As Zempl discovered, the process of transferring knowledge from U.S. client to offshore vendor — everything from hard skills like programming knowledge to more tacit knowledge such as an understanding of what the company and its users expect from a system — can make or break a project.
CIOs hoping to transition work offshore must deal with cross-cultural misunderstandings, the fact that employees who hold most of the knowledge about a certain system may also be clutching pink slips, the unavoidable reality that offshore vendors lack company-specific understanding and the problem of high turnover among offshore IT professionals.
In certain cases, these obstacles will completely preclude a move to offshore outsourcing. In others, knowledge transfer can be done well enough to make the outsourcing work, but only if CIOs understand the full extent of the knowledge that must be transferred and spend the time and money necessary to get it from here to there. “Many people just think about transferring the technical knowledge,” says Atul Vashistha, founder and CEO of offshore advisory firm neoIT. “They forget about all the other aspects — including change management, people retention and mentoring — that have to take place both here and offshore.”
Do you know what you need to know?
One of the biggest issues in offshoring is the fact that very few IT departments have decent documentation on their systems. You have to know what you know about a system or process before you can communicate that information to an outsourcer.
That lack of internal knowledge doomed the offshoring of Lehman Brothers Inc.’s IT help desk to Bangalore-based Wipro Spectramind. Jonathan Beyman, CIO of Lehman Brothers, had already decided to outsource the maintenance and support of a mainframe settlement system (which records the receipt and delivery of securities and money for the company’s fixed income and equities businesses) to Wipro’s system development arm. At the same time, he decided to send the New York help desk for Lehman’s 7,500 employees to the Indian vendor’s technical support division, which he thought would be a pretty straightforward affair.
He was wrong.
It turned out Beyman didn’t fully understand the nature of calls made to the IT help desk or the requirements Wipro would have to meet to respond to them. He underestimated the complexity of internal help desk calls, as well as the training and process documentation that would be required to make the offshoring work.
As a result, Lehman found that service levels were abysmal, and Beyman wasn’t saving money — his objective in offshoring the help desk. So last December, “after eight months of banging our heads against the wall,” Beyman pulled the plug.
When he went in to tell his CEO, Richard Fuld Jr., about his change of heart on the offshore help desk, Fuld called in his assistant, who promptly kissed Beyman on the cheek in gratitude. Although Beyman had retained a skeleton staff of 12 help desk employees in New York and had built the insourced help desk around them, he had to hire 20 new employees, since those he had laid off nine months earlier were no longer available.
In retrospect, Beyman admits he was surprised. “I would have thought that the help desk would have been easier to transfer offshore,” he says. “But it turned out we had a much better idea of what goes on in our settlement systems than we did in our help desk.”
The company still offshores application development and maintenance of several systems, including the mainframe settlement system, to 400 workers at Wipro and Tata Consultancy Services as part of two contracts costing approximately US$70 million. The business processes supported by the settlement systems were mature, well understood and decently documented. “As a consequence, it was far simpler to move the support of these types of systems offshore,” Beyman adds.
But even with mature applications, internal documentation can be hit or miss. Sixty per cent or more of the knowledge of legacy systems is sitting in someone’s head, according to Steve DeLaCastro of Tatum CIO Partners, an IT professional services provider and consultancy. “If there is any (documentation), it was probably done 20 years ago by someone on the verge of retirement — you know, the kind of person that if they were ever hit by a bus, the whole company would go down,” he says.
The hidden cost of layoffs
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 J.P. Morgan Chase & Co. 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 lay off “expensive” U.S. 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 laid-off 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 Corp., 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.”
The part that gets lost in translation
Time to face it: Total knowledge transfer is impossible, in large part because knowledge is geographically sensitive. Offshore vendors may tell you they have experience with a certain kind of software or industry, but that know-how is rarely “North American-centric,” says Tatum Partners’ DeLaCastro, who has set up offshore development deals in more than a dozen countries from Chile to Taiwan.
They may understand the basic needs of the health-care industry in general, but not HIPAA. They may be experts in PeopleSoft maintenance, but they don’t fully appreciate the requirements of Sarbanes-Oxley. “Without that kind of knowledge,” says DeLaCastro, “they’ll misinterpret the nature of certain requests, such as those that rely on the kind of multilevel logic contained in certain business rules or regulations.” DeLaCastro has seen problems crop up when offshoring everything from the programming of interest rate calculations and amortization to the treatment of complex benefit and tax calculations in a payroll system.
The inevitable trade-down in experience levels also hinders the knowledge-transfer process. “The big Indian vendor may come in and tell you, ‘Absolutely, my programmers can support you. Sangita, Kumar, Raj, Parvati and Anil have 186 years of experience altogether in your industry,'” says DeLaCastro. “Well, maybe if they started out when they were 12 and they’re now 50. But even then, it’s not the same industry as it is here.”
The effectiveness of knowledge transfer efforts can also get diluted the further down the food chain the information has to travel. When preparing for offshore transfer, CIOs have to train two types of people — those who will remain onsite (usually at least 20 per cent of offshore talent stays stateside) and those who will return offshore and train others.
The problems usually arise with the offshored talent. “If the people who are remaining onsite don’t get some of the training right, you can make up for it because they’re still here,” DeLaCastro explains. “But if the ones who go offshore miss some crucial element of training and they have to train others, the knowledge transfer is further diluted. If they’ve only gotten 70 per cent of it, things are lost.”
Add to that the difficulties with turnover offshore, particularly in the most popular offshore destinations; IT attrition rates average 25 to 30 per cent in India, according to a 2002 study conducted by Hewitt Associates and India’s National Association of Software and Service Companies. “Because of the boom (in India), every IT worker is getting 10 offers,” says Cendura’s Nigam. CIOs may need to start the arduous knowledge-transfer process over again with new offshore workers — or pay the price for not doing so.
When knowledge can travel
In reality, there are, in fact, only certain types of situations where offshore outsourcing stands a chance of succeeding. That’s because certain corporate cultures make it impossible to give up enough knowledge to offshore completely. “Some companies are just not up to doing outsourcing, forget offshore. They want to own everything,” says neoIT’s Vashistha, who points to examples such as traditional mutual insurance companies whose tolerance for risk is low and need for control is high.
It’s also particularly tricky for young companies to transfer knowledge offshore. “In a startup company there’s the growth factor, and trying to figure out how to do things here and at the same time how to do things offshore would be too challenging,” says Emmanuel R. Saint-Loubert, CIO of e-mail security at antispam software maker Tumbleweed Communications Corp.
Other types of projects on the no-no list: anything that involves complicated processes or complex problem solving and decision making, rapid development projects, systems that may be retired without a clear sunsetting plan, high-risk projects (for example, those with major revenue impact or sensitive data), legacy systems in older programming languages (offshore workers rarely have this training), works in progress, applications requiring specialized technical or business knowledge, and systems subject to regulations compliance.
In effect, the most likely candidates for knowledge transfer include the support of mature systems (if they are well understood and documented by the client) and the development of new, noncore systems — such as timekeeping systems or inventory control — that are a manageable size and can be easily separated from the company (and reintegrated).
Smart CIOs will take the transition slow, and approach the transfer of knowledge — technical, domain, cultural and personal — to offshore workers no differently than they would manage the training of a new employee fresh out of school (which makes sense). “If you bought PeopleSoft and spent two and half years training your own people on it,” DeLaCastro says, “why would you expect someone offshore to get it in any less time?”
Among the requirements for successful offshore knowledge transfer:
Pilots. Would you start a green in-house programmer on your biggest system? “A lot of CIOs suddenly open the floodgate on the dam, and they’re surprised when the whole city goes under,” says DeLaCastro. Conducting an offshore pilot project helps CIOs and their staffs identify the bottlenecks in the knowledge-transfer process and work on them in advance of sending more critical systems offshore.
Structure. Before the arrival of offshore workers for training onsite, neoIT’s Vashistha advises creating a transition road map that outlines all the processes involved in knowledge transfer—including identifying who the in-house subject matter experts are and the processes or systems they support, the knowledge they must transfer and to whom, a schedule of job shadowing, a plan for a transition readiness test and a schedule for ultimate transition offshore. “During the knowledge transfer, it’s literally like being on the receiving end of a fire hose a lot of the time, and (the offshore workers) can’t absorb it all at once,” Nigam says. “(A structure) mitigates the risk of losing the context of what was learned.”
Layoffs. As for dealing with the sensitive issue of displaced employees who harbour vast stores of knowledge, candour is the best policy. In addition, making an effort to help laid-off employees find new positions either within the company or outside of it enables a smoother transition.
“There’s no topic that internally creates more fear and loathing than moving jobs offshore. You have to be sensitive and honest about it. You can’t do it under cover of darkness,” says Beyman.
For the Lehman Brothers CIO, that meant standing up in front of the entire IT group in four locations (New York City; Jersey City, N.J.; London; and Tokyo) and explaining the company’s rationale for going offshore. Lehman Brothers gave the 100 employees affected — most of them programmers — a three-month working notice and the chance to find another job in-house, which 20 employees have done.
The company offered a standard severance package along with a special transition payment to encourage people to stay through their notice period. More than 95 per cent remained through the transition, but Beyman doesn’t kid himself about the main reason why. “It was the peak of bad times,” he says. Most couldn’t find jobs elsewhere.
Job shadowing. The simplest way of accomplishing knowledge transfer is through job shadowing. Where most CIOs miss the boat is in recognizing that job shadowing should be a two-way street. Not only must onsite employees mentor the offshore workers and enable them to learn their roles in context, some U.S. workers or managers must also travel offshore and shadow the vendor’s employees there to observe how the work transfers from the client to the vendor, and smooth out those touch points.
Audits. As the knowledge transfer progresses, it’s important to check against original goals and plans often. The checks and balances put in place (like a test on capabilities) are the key to preventing a premature sign-off to the offshore vendor. “With the pressure to meet deadlines, CIOs have to understand that getting the transition done well is more important than meeting a deadline,” Vashistha says.
Ongoing travel. At Cendura, Nigam keeps the two-way travel going long past the transition phase. Twice each quarter, either he or a software engineering vice-president is in Hyderabad. In addition, he sends domain experts over regularly to train employees on new business processes or systems.
“There’s also a constant flow of people from India coming here,” says Nigam, who rents out an apartment to house them. “We just had a dozen people over here, and the next batch will come in a month.” They don’t come over for specific development work but to get to know the way things work. “The cultural osmosis in both directions is very important,” he says. Yes, it undercuts the cost savings of offshore outsourcing, but it’s crucial.
“I think at least half of outsourcing initiatives are going to fail,” Nigam adds flatly. “So many are going to fail, it’s not even going to be funny, simply because (companies) skimp on ensuring that ongoing two-way traffic.”
