Outsourcing is a fact of life. Most companies - whether they choose to outsource work to outside vendors or a captive center of excellence (COE) in their home country, or whether they choose a foreign entity or a captive COE in another country (commonly known as offshoring) - find that it may make economic sense to outsource a host of business processes and application development work. There's a great deal of political debate these days about offshoring, particularly in the U.S. However, no matter what your opinion is (pro or con), the stark reality is that development costs in host countries are often substantially lower and - especially in the case of India - the pool of talented workers is almost endless.

The cost savings associated with offshoring come with substantial risks - particularly when the offshoring arrangement is for application development work. Consequently, finding a way to control and reduce the risks of offshoring has become a priority for companies that choose to move application development work offshore. Plus, the more complicated the application development work, the more complicated the risks in most cases.

This is especially true for business intelligence (BI) applications. Why? Because companies use BI applications to help measure the pulse of their business. These applications are critical to monitoring, understanding and managing business performance. If BI applications suffer from faulty design, the business could suffer as well. Also, the nature of the rapid development time frame, as well as the complex data management issues involved in BI application development, can often make offshoring problematical.

Before we start the discussion of offshoring, however, let's define some terminology. In this column, the term "client" describes the company that requires outsourcing work. The term "third-party service provider" (TPSP) describes the foreign entity or captive COE in another country that actually performs the work.

Now let's discuss the offshoring strategic plan. With all that's at stake, it's critical to have an offshoring strategic plan that effectively addresses all aspects of the offshoring arrangement. It must be especially specific in describing both 1) the work to be performed individually by the client and the TPSP, and 2) the work to be performed jointly by the client and the TPSP. It must also have clear goals and objectives for the outcome of the offshoring arrangement - i.e., service level expectations, expected outcomes, projected costs/benefits and a tactical execution plan.

This column is too short to cover all the aspects of a comprehensive offshoring strategic plan, but I'd like to address two of the most important: the division of labor between client and TPSP, and the keys to help make offshoring a viable strategic alternative.

First let's tackle division of labor issues. There are simply some tasks that the TPSP should not perform. These tasks run the gamut from requirements development to planning, managerial functions and testing. They should be performed by the client. It is not that TPSPs would not be skilled enough to perform these tasks; instead, it is simply a matter of common sense, convenience and logistics.

The tasks that clients should perform on their home turf include:

  • Project scoping and planning
  • Business and functional requirements specification
  • Overall development management
  • Systems and acceptance testing
  • Deployment

As you can see, these tasks are high-level, and they should only be performed by the offshoring client. The client knows what it needs, it has the managers and knowledge workers with the business knowledge required to perform these tasks, and because some of these tasks must be completed before the actual project work is moved offshore logistics dictates that the client perform them.
Conversely, there are a number of tasks that the TPSP can more than adequately perform. These tasks require considerable technical knowledge, effort and resource expenditure, but little in-depth knowledge of the client's specific business. These characteristics make them perfect for offshoring. They can include:

  • Technical design from business and functional specifications
  • Development and unit testing
  • Quality management at the development site
  • Development of training materials
  • Deployment and testing support
  • Operations support and maintenance

Effective execution of these tasks, which make up the backbone of any development project, is usually significantly less expensive - both in terms of capital and human resources that must be devoted to them - when they are performed by the TPSP. As a result, the client is freed to focus on growing the business.
The division of labor between client and TPSP is usually fairly clear-cut. What is not so clear-cut, and thus often trips up many offshoring projects, are the tasks that should be performed by both parties. It is this intricate dance - often carried out with a 10,000 mile gulf between collaborators -that often makes or breaks offshoring projects. The tasks that should be handled jointly by both parties, with frequent communication between them, are:

  • Project management
  • Resource allocation
  • Methodology and tool selection
  • Technical architecture and infrastructure design
  • Configuration management

Now that I have addressed which tasks should be performed individually and which should be performed jointly, I would like to discuss some keys to an effective offshoring project for BI application development. In my experience, there are five keys to effective offshoring:

  • Effective project management
  • Close coordination of resources and work effort
  • Open, frequent communication between the client and TPSP
  • Effective scope and change control
  • Ongoing monitoring and mitigation of risk

As I said previously, project management is a joint responsibility. Both parties have a lot riding on the outcome of the offshoring projects, and goals must be met and expectations must be managed across a distance - always actual and sometimes cultural as well. Therefore, it's a good idea to select a project manager with previous experience both in the type of project undertaken and in managing outsourced projects. And although the client should act as the overall project manager, there should be considerable input from theTPSP's management team. Each party must be on the same page of the project plan and know who's performing which tasks - and when - to promote an effective outcome.
The next key to the effective implementation of an offshoring project is communication. The project teams for both parties must maintain constant contact with each other. The frequency of the contact, whether daily or weekly, should be spelled out in their outsourcing agreement. Ideally, there should be, at a minimum, a weekly conference call or video conference to discuss project status and next steps. Any issues that have arisen during the last week can be resolved before they potentially affect project time frames.

However, at the beginning of the project, when requirements are being specified, and toward the end, when implementation is near, the calls should be daily. The bottom line is that both parties should have the ability to contact each other easily and quickly with any pressing issues. It's not so much a matter of what is discussed, but rather that lines of communication are open.

A corollary of communication is coordination. Indeed, it is difficult to have one without the other. The tasks that the client performs should be coordinated closely with the tasks that the TPSP performs. For example, once the client defines the business and functional requirements, the project work should transition seamlessly into the technical design phase at the TPSP's site. This close coordination helps the project work to flow smoothly and helps both parties in their efforts to meet their goals.

The next keys to an effective offshoring project are scope and change control. It is absolutely critical that both parties are clear on the project's scope from its inception - including what work will and will not be performed. The expectations for the scope should be very clearly delineated in the outsourcing agreement. Also, if the business requirements or functional specifications change during the course of the project, there should be a defined process for managing this change.

Nothing can derail a project faster than poorly managed changes. I have never seen a project where the circumstances and requirements at the beginning matched the circumstances and requirements at the end. So it's a good idea to keep in mind that change happens. It is not so much that you want to avoid change - rather, you want to manage it effectively.

The final key to an effective offshoring project, and one that really encompasses all of the other keys, is risk management. The nature of an offshore project in general, and the nature of a BI offshoring project specifically, create an environment fraught with risk. How effectively this risk is managed can go a long way in determining the ultimate results of the offshoring project.

The key to managing risk is to effectively execute all of the other keys discussed previously. Effective project management, open communication, close coordination of work effort, and meticulous scope control and change management are all critical factors for managing the risks usually associated with offshoring projects.

Figure 1: Data Warehouse Design Fundamentals

For many companies, the decision whether to offshore application development projects can be a tough one. Often the deciding factor is money. However, as the old adage states: it is often buyer beware. The offshoring experience can be positive, though, if the parties have a well-defined offshoring strategic plan that clearly defines their expectations for the project, there is good communication and coordination throughout the project's entire life cycle and change is managed effectively.

This publication contains general information only and Deloitte Consulting LLP is not, by means of this publication, rendering business, financial, investment, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte Consulting LLP, its affiliates, and related entities shall not be responsible for any loss sustained by any person who relies on this publication.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access