The option of staying stateside

When keeping IT assets close makes sense

When Wesley Bertch, IS director at Life Time Fitness, dipped his toe in the offshoring pool last year, he got a cold, unhappy surprise. Bertch, a strong believer in the benefits of free trade, hired a tier-one offshore vendor in India to augment his internal, 15-person software team, which focuses primarily on J2EE applications.

Bertch's idea was to start off with a small pilot project to test whether Life Time Fitness, a health-club chain, could add offshore capacity effectively without sacrificing quality. He went to great lengths to set the stage for success, working with leading analyst companies in vendor selection, sorting through individual developer resumes, and picking a low-risk pilot application. He even agreed to allow the offshore vendor to control all aspects of the project, including analysis, design, development, quality assurance, and documentation so that they could ensure successful delivery.

And the result? "The project failed, didn't work at all," recounts a frustrated Bertch. "It didn't meet the requirements and was fundamentally replete with defects. Our postmortem revealed that [the developers'] lack of experience was the No. 1 factor. And this was an organization that claimed to have high levels of quality and process."

Against the flood tide of IT work moving offshore, a small stream of work has been coming back to the United States as some U.S. companies have concluded that offshoring, for a variety of reasons, is not as much of a bargain as advertised. 

Second Thoughts

For example, smaller companies that can't afford the necessary up-front investment in processes and relationships have fallen short on success. So too have application-development projects that require close links with end-users, lots of innovation, or industry-specific knowledge. Politically sensitive projects and those requiring very high data security are also proving they may not be well-suited to go offshore.

In Life Time Fitness' case, the culprit seemed to be poor performance on the part of a specific vendor. But Bertch believes his experience is symptomatic of an offshore application-development industry that has grown too fast. 

The average worker assigned to his project had two years of experience, Bertch claims, and even senior managers had only three or four years under their belts. "These kids are right out of college with very little savvy and maturity in the biz world," Bertch says. "We concluded that to be successful offshore, we would have to control the processes and send our management over there. There's no royal road to offshoring. The Indians require years of mentoring, training, and experience before they add more value than they cost -- just as would be the case with hiring U.S. labor."

As a relatively small company, Life Time Fitness couldn't justify the necessary investment. Bertch says he instead chose to hire low-cost developers out of the University of Minnesota who were able to get the job done for half of the $30 per hour the offshore companies were charging.

Bertch encourages IT managers, based on his experience, to look hard at the onshore option. "U.S. businesses already have a built-in cost advantage over any other non-U.S. labor source: they're local," he says. "There's a huge bias among U.S. management [that posits] offshoring cuts costs without sacrificing quality, even though this usually proves not to be the case. IT management has a hard time communicating the lack of ROI with offshore because they come across as trying to protect their jobs."

Keeping Code In-House

Even with strong offshore management processes in place, offshoring may be better suited to straightforward development projects that don't require a lot of design or real-time collaboration with U.S.-based marketing staff or end-users. Such was the case for Stephen Beck, director of technical services at InvesTools, a developer of private-branded, Web-based financial applications for customers such as Business Week, CNBC, and The Motley Fool. Beck's team includes a stable of 10 programmers who work in ASP, C++, and Forth.

Although he initially believed he would save 50 percent of his labor costs by moving some of that work offshore, after scanning the market, Beck decided to keep the work onshore for two key reasons. First, because Forth -- a mainstay language for InvesTools -- is a relatively obscure programming language, Beck believed "it would be almost impossible for us to find individuals overseas that could do the same thing." Second, Beck felt going offshore would limit his group's ability to respond to customers and his own management.

"Ultimately the product would suffer, at least for us," Beck says. "Because of the nature of our products and services, we need to have direct contact with the developers during the course of a normal business day, we need to develop in real time," he explains. "We've had many instances where management has asked us to roll something forward or back based on business decisions … we simply couldn't do [that] with people sitting in another country."

Kevin Derrick, CTO of LeonardoMD, which develops hosted practice management software for physicians, chose not to go offshore for similar reasons. Although recently tempted by low quotes for Microsoft Visual Studio developers ($15 to $18 per hour) and .Net C# developers ($20 to $25 per hour), Derrick decided the distance would be too big a barrier.

"I like to meet face-to-face with folks and develop relationships," Derrick explains. "Our code is our business, and I'm not comfortable handing that off across an ocean or two. No matter how tight your spec is and how refined your documentation is, things always require change and a lot of good communication."

Furthermore, Derrick had concerns about data security. "We house critical health-care information," he explains. "I really don't want anyone seeing our code that doesn't actually work in our building. From a cost standpoint [offshoring is] great, but when I look at all the other issues, [offshoring] just doesn't work for me."

Differing Views

How representative are these companies with regard to other enterprises deciding whether to go offshore? Not very, asserts Peter Bendor-Samuel, CEO of Everest Group, an outsourcing advisory service.

IT work is "overwhelmingly going offshore; there are [only] some dribbles coming back," Bendor-Samuel says. And those that are reining in their offshore projects tend to be companies that have had bad experiences with smaller, second-tier application-development or call-center outsourcing vendors that "don't have rigorous processes or data security," he adds.

According to Bendor-Samuel, some companies get in trouble offshore because they don't anticipate the complexity involved or don't test the water before plunging in. "Development is a high-risk game anyway," he adds.

Lance Travis, AMR Research's vice president of outsourcing strategies, takes a different view, ticking off a long list of legitimate business reasons why companies decide not to go offshore. In addition to projects requiring lots of interaction and rapid end-user feedback, projects requiring company-specific knowledge may fare poorly offshore as well, he says. "The folks in India have very good generic skills around development. What they don't necessarily have is a lot of knowledge about the industry you're in or the specifics of your company," Travis says.

In the aerospace, defense, and pharmaceutical industries, there are confidentiality and other regulatory issues that make it difficult to move work offshore, such as change-management regulations in drug-development environments, which can be difficult for offshore developers to get up to speed on, Travis explains.

Travis also notes that intellectual property laws in India differ from those in the United States and that attitudes about intellectual property are very different in China. "You may not want to send offshore the development of an app that's going to give you a unique business advantage," he concludes.

Travis also notes that smaller companies oftentimes cannot make the significant investment in processes necessary to succeed in outsourcing projects offshore. "There's a real learning curve. You've got to be able to capture your requirements, develop a specification, and hand that to a group of people who you're going to have very limited contact with," he explains.

Creating New Models

Are there any attractive domestic alternatives to offshoring in an age of relentless cost-cutting pressure? Yes, says Meta Group Vice President Dean Davison, who suggests that enterprises look at cost-cutting alternatives such as outsourcing to lower-cost, rural U.S. areas such as Hood River, Ore., or even to Native American reservations, where "the cost of labor is much lower than it would be in [Los Angeles] or New York or Chicago." Many enterprises have adopted creative solutions for employing low-cost domestic resources; JetBlue Airways, for example, uses home-based reservation agents.

Davison also says implementing processes such as the Capability Maturity Model can help reduce internal development costs. Companies that have been able to institute an efficient internal development process, Davison claims, "are getting much of the benefit without going offshore; … only half the benefits [of offshore] are labor arbitrage."

AMR Research's Travis recommends enterprises look at buying packaged software or at ramping up self-service capabilities as a viable alternative to offshoring support or application development. "Instead of hiring offshore bodies, automate the process itself," he suggests.

But there are other alternatives to going far offshore. Meta Group's Davison notes that many companies are adding a "near-shoring" component to their portfolios, outsourcing work to Canada, for example, where labor rates are lower than in the United States but communication may be easier than going offshore.    

"It's not about India, the Philippines, or Canada. It's about taking the whole portfolio of applications a CIO is dealing with and optimizing a solution that includes people domestically, some near-shore, and maybe two or three at offshore locations," Davison explains. "We want to manage a project on a global scale and get the best blended rate possible."

Copyright © 2004 IDG Communications, Inc.

How to choose a low-code development platform