Off-shoring: Are You Getting Your Money's Worth?

Introduction

Every day we hear about more and more companies moving functions off-shore to places like India, the Philippines, and China. Some of you may have had firsthand experiences. The justification is that it decreases headcount, reduces labor expenses, and provides better services. But these savings are far from automatic. Whether for software development, enterprise-wide software implementations, or call center operations, companies must approach these opportunities with their eyes wide open.

Such activities as due diligence, reference checks, and financial statement analysis cannot be taken for granted just because of a pot of potential savings at the end of the offshore rainbow. An offshore company having a point of presence in the US is not a guarantee for success. We are not talking about the SAPs of the world. We are describing companies for which operations have a relatively minor impact on the overall corporate bottom line, which are run on a shoestring budget with minimum staff, and which must prove they can make it on their own without financial help from the parent company.

These types of offshore companies pose a risky proposition. The information highway is littered with examples of orphaned US-based subsidiaries that have left customers in the lurch without a life preserver.

This article examines four areas that could be impacted by an off-shoring decision:

• software development
• remote implementation
• call center support
• regulatory compliance

For each area, the article defines the extent of the exposure, negative outcomes, and ways to mitigate the problem. In this article a scenario is painted of a US-based company using an offshore company. While most off-shoring is flowing out of the US, don't think that other countries are not affected. The language may change, but the same problems exist.

Software Development

At some point in the implementation of an enterprise-wide solution, a gap analysis must be performed. Gap analysis is identifying where the software does not fully satisfy the business requirements of the company, and defining an alternative. Remember, we are talking about gaps, not chasms. An alternative may be in the form of procedural changes or minor software modifications. In either case, fully understanding what has to be done is critical.

More importantly, though, with software modifications, this understanding must be transferred through three links. First, the US customer must translate the requirements to the US-based offshore consultant. Then the consultant must properly communicate the specifications to the physical offshore development center making the software change. Remember the listening anecdote where the first person says "John and Mary are in love and they've set the wedding for next year." The second person hears "John and Mary think that they're in love and want to wait till next year to make sure." And the third person's version is "John and Mary like each other but hope that by next year the infatuation wears off." Well, the same communications problem can exist translating the conceptual requirements to detailed specifications and programming.

When this type of situation involves software and is not caught in time, the effects can be poor customer satisfaction, lost sales, and an endless game of finger-pointing. If the situation is caught in time, the three-link transference process must be repeated back and forth. Turnaround times are increased; target dates are impacted; and end users are frustrated. The lost-in-translation syndrome does not only pertain to verbal misunderstandings. Not fully understanding the technological landscape can be equally disastrous. For example, not knowing that there needs to be a separate server for reports can bring an enterprise solution to its knees when customer invoices are being printed and the warehouse is processing pick lists.

Another aspect where software development can create havoc is user documentation, in the form of both user manuals and screen interfaces. Either form can have an equally negative effect. Tender means bid; batch means lot; or day books mean sub-ledgers. Users must bridge this jargon gap. But this is not the real problem. Users will start questioning whether the offshore developers truly understand the requirements. And once doubt starts to stir, an implementation team could be fighting a constant uphill battle trying to restore confidence in the developers and software. While there are tools to change these misconceptions on the screens, are you going to have to make these changes with each release? Did you budget for this?

Misunderstandings involving software development can result in too many undos and redos, delays in the overall project implementation, and frustrations and questioning in the user community. All of these can mean real and intangible dollar losses to a company. What can you do?

With respect to software modifications, require contractually obligated, written conceptual designs. Now, a conceptual design should not require a PhD in nuclear physics to understand. An end user who is familiar with the area of concern, should be able to read through a conceptual design document free of three-letter acronyms (TLAs) and the other obscurities we typically associate with information technology. The conceptual design document is not put to rest until there is a complete understanding of the inflows and outflows of data and reporting.

As a final proof of concept, a thorough walk-through of the conceptual design should be conducted by a US-based offshore consultant to confirm a complete understanding. This consultant communicates to the third link of the chain, namely the software developers. If this conceptual design process is not fully completed, the only savings you are likely to realize, will be virtual dollars.

As for screen interfaces, it would preferable to change them to the vernacular of the company. However, there may be a high cost associated with this approach, and it may just not be worth it. At a minimum, however, the offshore consultants should properly prepare the users and somewhat mitigate their initial confusion.

Remote Implementations

Off-shoring companies with US-based operations can offer an alternative to the traditional on-site software installation, namely remote implementation. Under the remote scenario, the quality of the time spent on site by US-based, offshore consultants is maximized, but the overall quantity of time is kept to a minimum. Based on information supplied by these US-based consultants, the software is configured at the offshore development centers. Using hardware and technology mirroring that of your organization, users access and test the software via a high-speed Internet connection. Once testing is completed and user acceptance is gained, the completely configured software is shipped to your organization for final installation and testing.

Make no mistake about it. The savings from a remote implementation over the traditional method can be significant. The theory is that, if quality time can be provided to the off-shoring consultants, your company saves on out-of-pocket expenses and, to some extent, on on-site consulting hours. That's a big if. Most companies start with the best intentions, but may not have the discipline to maintain the commitment, or a shift in business priorities may cause a reallocation of a company's personnel. As a result, a company may end up paying more than for a traditional on-site implementation. Furthermore, as with software development, the remote implementation option puts a heavy premium on communications. What can you do?

While you can get everyone to sign a blood oath that they will be available whenever and wherever needed, it "ain't gonna happen." Your biggest customer needs an expedited order; a major production line is down; or everyone wants to read this article. Distractions are going to happen, and they may be significant enough to affect the implementation. The best advice is not to hang your cost justification for off-shoring on remote implementation. If the remote implementation is successful, consider yourself lucky and ahead of the game!

Call Center Support

As for another area impacted by an off-shoring decision, we all have heard the horror stories or, more likely, experienced firsthand the frustrations of dealing with offshore call centers. Honestly, this is more of a problem of poor training than one of language. You can hear the pages turn as the call center representatives read verbatim from orchestrated scripts, asking question after question having no bearing on the problem. The only thing worse is a voice-activated response unit. Been there; gone through that.

Now transfer this frustration level to your end users. These could be users that are the first line of contact with your customers. Are your users' frustrations now being transferred to your customers? After a period of time, users stop calling the call center altogether and start calling the company's senior management! What can you do?

The best safeguard against poor support is reference checking, reference checking, and more checking. Ask for a list of existing clients of the offshore company. Make sure the list is of sufficient magnitude to assure a good cross-section. If such a list is not forthcoming, be afraid; be very afraid. Talk to the referenced clients about their experiences. Have your subject expert talk to their subject expert—finance with finance, production with production, and so on. Make sure that all time zones of your locations are covered.

Finally, call the support center yourself. Develop problem scenarios and gauge your level of satisfaction. Ask to speak with the knowledge expert. Did the call get answered in a reasonable period of time? Did the representative appear knowledgeable? How long did it take you to get a resolution? Now, repeat the process with an off-hour shift. Were the results the same?

In the long term, as users become more proficient with the software, your company's power users may be able to act as the first line of contact. But this will not happen overnight, and depending on the stability of the software, could take years.

Regulatory Compliance

This issue of off-shoring support is the easiest to identify but the hardest to resolve. If your company is subject to external regulations and guidelines (and what company is not), is it reasonable to expect that a software solution developed offshore will accommodate these requirements? Let's face it, are the dairy restrictions in India the same as those in the US? Are drug labeling and reporting in China the same for pharmaceutical manufacturers in the US? Equally, do the software solutions reflect the current state of affairs? Were the solutions developed as an afterthought, or designed and seamlessly integrated with the complete solution? What can you do?

For this problem there are few options to choose from. A takeoff on the adage "When in Rome ": "When in Rome, best to let the Romans do it." If your company is heavily regulated and these regulations are changing constantly, it would appear reasonable to stay in your own backyard where a vendor has firsthand knowledge and access to pending legislation and public opinion, and not a vendor 5,000 miles away. Your company may still be able to take advantage of offshore components such as warehousing, forecasting, or business intelligence. But that ugly I word comes to mind, namely interfaces.

Summary

The chart below provides a snapshot of the four off-shoring affected areas, comparing the rate of occurrence of an issue with how severe its impact could be on an organization.

An explanation will help provide some insights into the analysis. Software development issues (such as miscommunicated specifications or poor documentation) are likely to occur most frequently, but should have less of a severe impact on the organization, particularly if disposed of quickly. Just by the nature of the volume of calls, call center support (i.e. increased frustration levels, frustration transference) has a high rate of occurrence but, if contained, should have the least severe impact of the four areas. The theory is that not all user areas would be affected, lessening spread of frustration and impact on your customers.

Since most companies may be reluctant to even consider the remote implementation alternative, this area will have low rate of occurrence. But if a company does select remote implementation and fails, the entire project is in jeopardy, and the delays and cost overruns can be extremely severe. Customers and product lines will be adversely affected, possibly resulting in irreparable damage.

Finally, playing around with regulatory compliance issues is tantamount to trying to start barbeque coals with gasoline. Sure, the coals will light but the aftereffects will be uncontrollable. Likewise, while most companies are prudent enough not to run risks with regulatory compliance, those that do and fail could bring the organization to its financial knees.

The bottom line is that, sure, you can save money by off-shoring. But don't expect it to be handed to you on a silver platter. Working with off-shore companies can have several negative impacts:

• increased levels of frustration
• project completion delays due to miscommunication
• unexpected cost overruns
• transfer of frustrations from your users to your customers.
• a constant struggle with regulatory compliance

As we have seen, there are ways to mitigate these concerns and issues. You probably know of others. The point is that these mitigation measures cost money. These costs must be subtracted from the expected savings before you decide whether off-shoring makes sense for your company.

A final sobering thought. Off-shoring may not be as attractive as it once was. For example, according to Technology Business Research, at current compounded annual growth rates, the average wages for Indian and US software engineers are expected to converge in the next twenty years. As the salaries of both nations get closer, the potential savings will get smaller and smaller. Similar analogies with other off-shoring geo-centers could probably be made. Sure, it's a long way off but as the off-shore salary structures continue to approach those of the US, the savings expected from off-shoring with continue to diminish, requiring companies to sharpen their pencils to ensure the move makes financial sense, and to take a closer look at the total cost of ownership.

About the Author

Joseph J. Strub has extensive experience as a senior project manager and consultant for the planning and execution of ERP projects for manufacturing, and distribution systems for large to medium companies in the retail, food and beverage, chemical, and CPG process industries. He has developed marketing and communication programs for IT organizations, and consulted on off-shore outsourcing opportunities for multinational companies. Additionally, Strub has been a consultant and information systems auditor with PricewaterhouseCoopers, and an applications development and support manager for Fortune 100 companies. Currently, Strub is an independent consultant. He can be contacted at JoeStrub@WriteTechnologyPlus.com.