Offshore outsourcing has steadily gained credibility among mainstream enterprises as a cost-effective, quality alternative to traditional options. As enterprises evaluate a global delivery model (the optimum combination of on-site, domestic, "nearshore" and offshore resources), they need a way of determining which projects are suitable candidates for nearshore or offshore delivery. The factors detailed below can help them decide.
Qualitative Factors
The following qualitative factors can be used initially to select pilot candidates for nearshore or offshore projects. As enterprises gain more experience with the global delivery model, they can modify these characteristics to constitute the basis for a repeatable framework for evaluating new initiatives. As an enterprise becomes comfortable with a global delivery model -- and builds the internal competencies for managing a combination of on-site, domestic, nearshore and offshore resources -- it can begin to evaluate more complex projects.
- Ambiguity level of requirements: A rigorous process that defines requirements and builds consensus and sign-off on key assumptions reduces the need for changes and rework during development. Projects with clearly defined requirements that lend themselves to modular methodologies or the remote execution of programming and testing tasks, rather than highly iterative development processes, are more suitable for offshore delivery.
- End-user interaction: The level of face-to-face contact and communication with end users is one of the most critical factors for determining the suitability of the location for work tasks. Projects that don't require much face-to-face, end-user interaction during the entire life cycle of the effort are typically more suitable for offshore delivery.
- Application stability: An application that is in a steady state and relatively stable enables the delivery team to focus on the process, methodology and workflow, rather than on "firefighting." Selecting an application with a high level of stability enables enterprises to pilot the global delivery model for purposes of benchmarking savings levels and planning assumptions for future efforts.
- Low operational complexity: Pilot applications should not require complex procedures involving, for example, significant manual intervention or data fixes. Nor should they require a high level of integration with other systems, unless the majority of the systems are part of an entire application suite targeted for offshore delivery. This will ensure that the transfer of skills is completed in a short time and that the benefits of offshore support are gained as quickly as possible.
- Reasonable application life: The application should be scheduled to remain in use for at least 24 months. This will provide sufficient time to ensure that an adequate payback period is realized.
- Business criticality: Choosing a pilot application with low-to-medium business criticality will limit the effects of any initial problems with the offshore support process. Once the support process is established, applications with high levels of business criticality can also be considered for offshore delivery.
- Matching the business impact to enterprise goals: Some enterprises initially select low-visibility projects so they can smooth out the wrinkles without undue business risk. Another advantage is that there is less scheduling pressure with low-impact applications. Other enterprises, however, select high-business-impact applications with the aim of achieving an early "big win" that will create momentum for adopting a global delivery model.
- Knowledge transfer index: The level of explicit knowledge or documented information that is available is an important factor to consider when selecting a pilot offshore application. Projects with high levels of existing knowledge will likely be implemented faster and at lower cost than those where there is limited documentation or internal IT staff have the information "in their heads." There will be less need for developers to interact with internal employees who may be resistant to change and who may seek to delay or stop the move to offshore delivery.
- Minimal employee backlash: Pilot applications should be from business areas that more readily accept the concept of using offshore resources. Once the pilot has demonstrated the feasibility of offshore delivery, it will be easier to persuade more skeptical business areas that they too can benefit from offshore working.
- Support team size: The team size should have sufficient mass for early payback and to stress-test the process (15 to 20 full-time equivalents or more) vs. small teams supporting multiple applications. For pilot projects, the project team size is important to allow for a manageable and controlled transition that can be contained and monitored. In addition, the level of resistance and change management issues can be managed to understand the thresholds of the organizational boundaries and processes. Once the pilot projects are completed, the enterprise can think in terms of larger-scale projects that may require hundreds of full-time equivalents. Offshore external service providers (ESP) often offer significant discounts for larger numbers of staff, and enterprises report that projects with more than 50 staff typically have the highest savings ratios.
The following technical factors should also be considered when choosing pilot offshore projects:
- Hardware and software: For purposes of a pilot, choose projects with simple and standard hardware and software requirements. The projects should not require the enterprise to pay for duplicate or additional hardware to be installed at the offshore development center, and the projects should have a limited impact on software licensing costs.
- Application environment: Ensure that the pilot application requires skills that are relevant to the enterprise. For example, choose an application that will run on the enterprise's most widely used platform.
Quantitative Factors
ESPs often inflate expectations for the cost savings that can be achieved from offshore application development or management. Although offshore ESPs have substantially lower labor rates, this advantage must be quantified in the context of the entire life cycle of the project (concept to production). The rate for an offshore Java developer working at an offshore location typically ranges from $20 to $40 per hour, compared with $150 per hour or more for a developer who is a U.S.-based employee of an ESP. The offshore developer's rate will also likely be lower than the fully loaded internal cost of an in-house U.S. developer.
However, the hourly rate for an offshore developer who works in the U.S. will typically range from $55 to $90 and may be higher than the fully loaded internal rate. Thus, it is critical to quantify the proportions of the ESP's work that will be done offshore and on-site. A useful guideline is that significant cost savings will not be achieved unless at least 70% of the total labor hours can be executed remotely at an offshore location.
Additional quantitative factors include:
- Number of resources: The levels of personnel involved in the engagements that define the effort directly determine the scale of the project and correlate to the savings achieved.
- Duration of assignment: The savings achieved will vary significantly according to the duration of the engagement. For example, the savings from a multiyear offshore outsourcing arrangement would be very different from a three-month assignment.
- Technology platforms: The specific technology platforms involved in an offshore project may affect the demand and supply of specific skills. For example, it may be difficult to find highly skilled resources for emerging technologies, or for legacy technologies, so these resources may be priced at a premium.
- Scope of engagement: The statement of work that defines the project and the service provider's role in the overall effort will also drive the savings achieved through the effort. As the scope of the effort increases, the benefits will increase as long as the risks are managed.
Bottom Line
As enterprises evaluate the suitability of projects for offshore delivery, they should apply a framework that is composed of quantitative and qualitative factors. This framework will help minimize the risks of early pilot offshore projects and will lay the foundation for future success.
Gartner Inc. is a technology research and advisory firm with more than 10,000 clients.
What do you think? Post your thoughts and see what others have to say in our outsourcing discussion forum.
Offshore Buyer's Guide
Stories in this report:
- Offshore Buyer's Guide
- IT's Global Itinerary: Offshore Outsourcing Is Inevitable
- India Inc., Still Going Strong
- Canada: Safe, secure and 'near-shore'
- The Philippines: Low cost, but higher risk
- Mexico: It's Close; It's Cheap
- Ireland: Comfort and Convenience at a Higher Cost
- China: Low-level work at lower-than-average cost
- Singapore: Small but powerful
- Vietnam: Nascent capabilities but low cost
- Malaysia
- Brazil
- Russia and Eastern Europe
- Selecting the Right Offshore Vehicle
- Global Outsourcing Tool Kit
- Offshore security: Considering the risks
- How to negotiate an international outsourcing contract
- What projects should be outsourced overseas?
- Processes, QA key to successful offshore IT
- Outsourcing: Voices From the Front Lines
- Five Insider Tips for Managing Offshore Operations in India
- Software quality is still a work in progress, offshore and in the U.S.
- Hidden malware in offshore products raises concerns
- Making IT Outsourcing Work for You
- 11 Steps to Successful Outsourcing: A Contrarian's View