The classic argument for offshoring is that history is repeating itself. It goes like this: The arguments against offshoring have all been made before in other contexts, and concerns that the U.S. economy would suffer long term were unfounded. The U.S. economy has gone through waves of offshoring in the past. A good example is what happened to semiconductor assembly during the 1970s. While there was short-term pain, the economy overall continued to thrive, and most displaced workers emerged intact with more satisfying and often higher-paying jobs.
The counterargument is that this is a new problem, not a repeat of history, since it is now knowledge workers and highly paid professionals who are affected, as opposed to those holding "more standardized" manufacturing jobs. The rebuttal to that is this: Even though today's offshoring involves knowledge jobs, it's still the more routine professional tasks that are being sent overseas, such as maintenance of legacy software code and standard call center procedures. Thus, U.S. professionals are freed up to work on more satisfying tasks, such as software design advancement and the creation of new applications.
As businesses struggle to rebuild after the economic downturn, they must look for every opportunity to gain a competitive advantage or risk losing to competitors that are willing to capitalize on offshoring opportunities. These businesses are forced to take the view that, regardless of the moral and political issues involved, outsourcing is a fact of life and the question is when and how, not whether, to participate. Timing is a critical factor, since there are many situations in which offshoring has not worked well, if at all. In the current offshoring frenzy, many companies are rushing to offshore projects that aren't appropriate candidates. The following are general guidelines for deciding whether to outsource.
When Not to Offshore
1. If you're a start-up or other organization with new-product development projects. In these cases, close contact is required between developer and customer. Many new-product development teams have frequent communication with one or more target customers to discuss trade-off decisions, review user interfaces and other key features, and clarify requirements. In some situations, there is a partnership in which the development team works on-site with the target customer. This facilitates frequent communication with multiple customer representatives and gives the customer first access to a product that promises to provide a competitive edge.
Offshore development inhibits close, frequent communication. Obvious potential issues are language, time-zone and cultural differences. Other factors can include differences in motivation between teams paid on a contract versus an equity or share-of-profits basis.
2. When it's a complex project involving multiple teams. These situations create many concerns related to offshoring. New-product development is one example of this; others include joint development projects involving companies with complementary core competencies or a project involving multiple subcontractors. Again, the increased communication overhead becomes an inhibitor.
3. When the project involves a company's core competency. Companies experienced in offshoring identify areas they consider to be their core competency and keep projects in those areas in-house. Typically, companies that consider their core competency to be software development don't offshore that activity, although they might set up a captive offshore facility. Companies for which the core competency is knowledge of a specific vertical market, and for which software is a means of delivering solutions based on that knowledge, will be good candidates for offshoring of development.
4. When a project involves a company's core intellectual property. The concern is the real or perceived fear that once offshore, IP is difficult to protect. Companies selling offshore development services claim that laws protecting IP are as strict and rigorous in many offshore countries as those in the U.S. and that there are contractual and operational safeguards that will protect information. But other companies live by the adage, "If you send it offshore, assume that it will get stolen and there is nothing you can do about it." While there are ways to protect IP and minimize the impact of theft (which will be discussed later), most observers agree that it is risky to export IP that has high value to the company.
5. When it's a "crash" project that was created to help bring another project back on schedule. The practice of throwing additional bodies on a slipping project doesn't work, even when the resources are from the same company, unless the functionality can be partitioned into modules with well-defined interfaces -- difficult enough to achieve at the beginning of a project, and virtually impossible midway through. If a company hasn't worked with the offshore vendor before, it should expect a ramp-up time of six months or more -- exactly what is not needed for a crash project.
6. If you're attempting to gain immediate cost savings. Many experienced companies have found that offshoring actually increases costs in the short term based on the need for additional high-level project management resources and the extra time necessary for working relationships to develop. The savings are generally realized only after an initial investment period. There are also the hidden costs of offshoring -- high-bandwidth requirements, an enhanced communications structure, travel, additional project management and administration -- that will offset the salary differentials that they are counting on for big savings.
When Offshoring Is Appropriate
"Incorporating offshore strategies into the business model can bring tremendous value to U.S. companies if used well," says Dimitri Nikouline, president of offshore outsourcing firm Murano Software Inc. "Companies can make the most of expert talent abroad and complete projects in a more expedient manner, allowing more time to proceed with groundbreaking opportunities in the U.S."
At a high level, there are two situations when offshoring is appropriate.
1. For performing maintenance, support and extensions to legacy code. In these cases, the requirements are well defined, the code base mature and stable, and the amount of change generally low. The opportunity for failure and corresponding systems integration risk rises exponentially with the amount of change. In addition, these tasks are generally considered less glamorous to U.S. developers. While there may be IP embedded in legacy code, the preponderance of IP for a mature product is generally the knowledge of how to deploy the product, not the code itself.
A consideration is the extent to which the legacy code is modular or entangled. If the entire code base must be replicated offshore or accessed from offshore through a virtual private network, practical challenges and client discomfort may arise.
2. For ancillary projects. Ancillary projects may be defined as those that are not mission-critical and don't involve IP, particularly if they are stand-alone or loosely coupled to the main products. Often, it's just those projects with a simple and well-defined interface. Examples include modular product enhancements or extensions, utilities and product-line fillers. Of course, having a project that fits the profile of an offshoring candidate won't ensure success without proper execution.
"Well-defined projects with specific objectives are suitable to offshore," says Dave Prasad, CEO of Scape Velocity Inc., an offshore engineering services firm. "With long-term projects, companies can follow the bi-shore methodology of offshoring design, development, support and QA activities and keeping the deployment and integration efforts on-site."
Those distinctions aside, there are increasing instances of offshore teams effectively developing new products. Keys to success for this include:
- A skilled, local project manager with a great deal of experience managing an offshore team.
- Good communication lines, as well as frequent milestones, to ensure timely completion of the engagement.
- The ability of the offshore team to work independently and make good judgment calls on its own.
Offshoring is not a panacea, and a company must be careful in determining when -- and when not -- to offshore. This can be hard to do objectively when there is a frenzied demand to offshore, and there will be the inevitable failures resulting from inappropriate projects. As with everything, good execution is essential to realizing the full benefits of offshoring, or having it work at all.
Hoshi Printer is president of the Software Council of Southern California, a nonprofit association that serves as a community for the region's software industry. Contact him at HoshiP@autobytel.com.