Managing the Risks When Outsourcing Offshore


Increasing numbers of businesses are choosing to outsource their development overseas, for either smaller, defined projects or through a long-term outsourcing partnership model. The main reasons cited for outsourcing include a desire to increase company productivity and efficiency, while simultaneously lowering operating costs in an increasingly competitive economy.

But with outsourcing, whether overseas or locally, comes risks. Five major risks of outsourcing have been identified in recent years:

  • Communication/cultural barriers
  • Misunderstanding of requirements
  • Quality assurance
  • Concerns about intellectual property security
  • Differences in company infrastructure and processes

In this article I’ll discuss each risk in turn, as well as methods of mitigating the risks when outsourcing offshore.

Risks during outsourced project development are related to three factors: people, processes and policies.

By identifying where these risks can occur and taking steps early to mitigate them, your firm can enjoy an outsourcing relationship that is of high value to all parties involved. In the next section, we will describe what these risks are, and specific steps you can take to address them.

The Most Common Risks Encountered When Outsourcing

If you have concerns about outsourcing, you have plenty of company. When the management of several hundred companies in the United States was surveyed recently, they noted that their primary concerns included:

  • Communication difficulties. This consistently came in as the #1 concern
  • Quality of the development provided
  • Lack of physical proximity to the development teams
  • Concerns about the protection of intellectual property

Many times, managing the risks involves managing the expectations on both sides, to paint a realistic picture of what the outsourcing relationship will look like. From the deliverables that are expected to the methods used to create source code, you need to know that the firm you’re outsourcing to understands clearly your expectations. This is why risk number one is critical: Poor communication of project requirements is deadly to any project.

–> Risk #1: Misunderstanding the Requirements

You may have heard managers at other firms complain about the “poor quality code” that they received when outsourcing overseas, or statements that the developers “didn’t get it.” But in most cases, service providers fail to meet expectations not because of inferior ability, but because they misunderstood the project requirements.

The number one risk when outsourcing overseas is poorly defined project requirements. Your company project manager may be tempted to pull together a “quick project overview” or ask that an overseas development team develop a project “on the fly,” especially if the deadline for completion is tight. But skimping on documenting the project requirements is a recipe for potential problems further down the line – and numerous, often costly, change controls. A development team is often only as good as the project requirements they’re given and with good reason. There are many, many different ways to approach developing an application, for many different purposes. Any may be valid, but if you leave this up to chance, the developers may choose a path that you didn’t want, causing the project to go “back to the drawing board.”

There’s a line between creating a massive, overly detailed project specification that takes months to complete vs. a one-page, completely inadequate “project concept.” But in general, the more clearly defined your project specifications are from the beginning, the better the vendor project managers will be able to understand what you want done, how you want it done, and how it should be implemented.

How important is this stage? A study conducted by the Software Engineering Institute discovered that poorly defined or unclear project requirements are the number one reason why software development projects fail or are delayed.

How to Reduce This Risk

Never force a software vendor to “guess” at what you want built. While engineers are often talented individuals, they’re not mind readers. While there are many different paths to building a product, not all may be acceptable to you. To avoid disappointment, clearly define your requirements. To reduce the risk related to misunderstanding of the project requirements, it’s important to approach the requirements development phase of a project as the most critical to complete, prior to starting development. After development begins is too late, since that “wrong path” may be taken. When considering a firm to outsource to, evaluate what processes they have in place for gathering project requirements and for translating these requirements into system specifications that the developers can use.

The better vendors will make this as easy as possible on you (or your company’s designated contact). They’ll have a project manager, fluent in English, who will spend time in interviews learning about your requirements, and documenting this for the overseas development team. They’ll know what questions to ask and, based on their experience, can capture project details and requirements relatively quickly. It will often take several discussions, either on-site (for larger projects) or by phone/teleconference. But it’s well worth the time spent. The vendor project manager will be collecting information to be used during the three steps in creating project requirements.

1. Gathering the Initial User Requirements

Prior to creating the system use cases, the vendor project manager will spend time interviewing potential users about the desired features and functionality for the system being built. This includes learning about the business requirements for the completed system, and gathering from your firm the high-level system requirements and user interfaces the system will include.

The #1 Source of Failure

Unclear requirements are the #1 one reason that outsourced software projects fail.

  • Spending extra time on the requirements gathering phase always pays off.
  • Both companies should have designated company contacts throughout the project, for communication.
  • Provide vendors with specifics about the users, load, business requirements and technologies involved.
Many times, the vendor engineers will use these initial requirements to create an initial “mock-up,” that will be built upon later, to ensure that the requirements are accurately understood. During this initial phase, the vendor project manager will document the system requirements and specifications, including any significant project milestones and parameters for performance. It’s vital that the vendor captures and documents information about the number of users the software is to support, how quickly operations are to be performed and how users will actually be using the software.

2. Analyzing the System Requirements

This involves determining the acceptability, ability to implement and testability of the proposed system.

3. Inspecting Requirements

This involves a comprehensive review of the proposed requirements, with the goal of identifying any issues or errors related to ambiguities or discrepancies discovered in the requirements. Part of this documentation will include a plan for issues tracking, and how issues that occur during project development will be handled. While the above stages require some time and effort, their importance to success can’t be over-emphasized. A strong initial analysis will significantly reduce unexpected project costs. Once this phase is completed, you’ll have a detailed requirements document, which you and the service provider will jointly review and sign off on. This becomes the guideline for development and will provide clearly defined parameters for project development.

–> Risk #2: Quality Assurance

Even the best development teams create code that has “bugs,” which is why quality assurance (QA), whether development is completed onshore or offshore, is important. A major risk when outsourcing to an unknown vendor is whether they have adequate QA/testing processes in place. Waiting for product release to find out what bugs are present is not the best scenario. You can reduce this risk by taking time to check on the QA processes a vendor uses. The three main reasons that QA isn’t done, or is done inadequately, are:

  • The service provider lacks its own QA/testing team and assumes the client will complete this in-house.
  • The project has a tight deadline, and so QA testing is done rapidly or set aside to give development a priority.
  • The vendor doesn’t fully understand the system requirements, and so testing doesn’t cover them.

How to Reduce the Risk

One of the first things to evaluate in a possible software vendor is what QA processes they have in place. The better vendors have their own QA teams in place that work in conjunction with the developers to implement a test plan for your software. Things to check include:

  • Is there a system for tracking issues/bugs or system changes in place?
  • What processes are in place for fixing bugs?
  • What standards for monitoring and quality compliance are in place?
  • Do the developers use industry-standard unit tests and regression tests to test each build?
  • Is the software being tested for load, performance, integration and the real world end-user experience? (This last is key.)

QA is Critical

  • Check that the vendor has its own QA/testing team.
  • Carefully evaluate the vendor’s QA processes, including tracking and documentation.
  • Are their standards compatible with your company’s?
  • Test carefully prior to beta release, no matter how “rushed” a project is.

It’s important that test cases, created based upon the carefully documented system requirements mentioned in the previous section, are developed for any software system developed. This can mean the difference between a “great beta” version, and one that is bug-filled. Once development is completed, the QA team will step in, checking that all functionality, scalability and security issues have been addressed based upon the initial test plan developed from the system requirements gathered. The test plan covers all system regression, load and volume testing and user acceptance testing, with specific performance criteria for each.

Another way to improve the quality of the completed deliverable is to conduct inspections of the work products. Inspections are detailed technical peer reviews of software designs or implementations. It has been estimated that each hour spent on QA activities, such as design reviews, can save a firm from three to 10 hours in downstream costs. You should ask your offshore vendor to conduct inspections at each stage of the development or maintenance process.

By conducting regular peer review inspections, the vendor will be able to detect and correct defects rapidly in upstream work products. This allows them to better control the costs and prevent schedule delays during the project. For instance, a requirement defect left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix when the system requirements were originally being developed.

–> Risk #3: Intellectual Property Protection

Your intellectual property is one of your company’s greatest assets, and when outsourcing, it’s critical to take steps to protect it. Stories abound of unethical companies that have stolen technologies or data and marketed them; but in most cases these problems could have been avoided with careful vendor evaluation, and implementing measures to protect your company’s intellectual property. This starts with only providing any vendor with only the minimum proprietary technology or data needed to complete the project and carefully evaluating the confidentiality measures the vendor you have selected has in place.

Be sure to evaluate these policies carefully for both your firm and the vendor firm. For instance, you’ll want to make sure that your own employees understand what corporate information is acceptable to share – and what is not – with an outside vendor. This includes the internal rules for authorizing access to company data. Make sure that the vendor you’re outsourcing to has in place clear, enforceable policies for protecting the data you share with them. At a minimum, this includes signing a nondisclosure agreement, a non-compete agreement, and a no solicitation agreement, as well as policies that prevent the vendor from creating unauthorized copies of your software or technology. While this may seem straightforward, it can become a bit more complex at times, such as when a service provider uses its proprietary technology or an open source solution to develop a new product that will be used by your new application. In this situation, it’s important to predefine what source code belongs to the vendor and what belongs to you, the client, and to clarify any licensing issues.

Protect Your IP

  • Check that the vendor has a documented, enforceable information security management policy in place.
  • Share only necessary information during projects.
  • Clarify licensing and source code ownership.

Always insist on clear documentation of all source code created during your project for your software. This becomes your company’s property and is legally protected. You’ll want to check with any vendors being considered to see what processes they have in place to protect your confidential data, such as customer and employee information, financial data, or proprietary market research data. If a vendor lacks a documented information security management policy, you should search elsewhere for a vendor that has one.

The better vendors will offer to provide development on a dedicated project and data server, with audit control access for each of the project servers. Some things to check on include:

How physically secure is the vendor’s facility? Is it secured with smart cards to control physical access?
Have all members of the development team signed a confidentiality agreement with your firm?

By finding answers to the above, you’ll take huge steps toward protecting your firm’s intellectual property.

–> Risk #4: Differing Internal Processes

Each vendor will have somewhat unique processes and methodologies that they follow when developing a project. It’s important to evaluate how this differs from your in-house processes and how the two differing approaches can best be “meshed” during a development project.

It’s best if a development project is guided by a well-defined, common software development and project management methodology. The best vendors follow industry standards, such as CMMI and ISO 9001 QMS. This common methodology should cover libraries, tools used, version control and quality assurance processes, as well as security metrics for each project.

Once the process is agreed upon and established, put monitoring in place to ensure that these processes are being properly followed. Clients should have each project milestone clearly defined, including what deliverables are planned during each phase, with specific deadlines for the completion of each. The client should also have a clear understanding of what its obligations are in regards to reviewing and approving each delivered product, including the requirements documentation, the system design, test cases and any test issues that arise.

In general, the more involved your company is with the project, the more smoothly the project will go. This is why it’s important to have a designated contact within your firm whose role is to communicate with the vendor project manager and/or development teams. This person, as well as key stakeholders in the project, should be available to review progress reports, review finished deliverables and be available for phone conferences. If the vendor has questions related to your firm’s products and applications, which require answers in order to continue development, your designated company contact is responsible for arranging for the proper technical resources to provide answers.

Painless Merging of Methodologies

  • Agree upon a consistent methodology based upon industry “best practices” that your firm and the vendor will follow prior to starting the project.
  • Monitor compliance with the agreed-upon standard.
  • Set up specific times to clarify and answer questions, especially at the outset of any project or outsourcing relationship.

Your company’s project manager or designated contact will need to review the status of any deliverables as well as any testing done, and be available to communicate frequently with the vendor project manager. Most project problems occur to infrequent or poor communication between the client and the vendor. But the “no news is good news” approach is rarely true; in fact, the opposite will often occur. One of the easiest ways to reduce this risk – and to catch problems early on – is to initiate frequent communication, with regular times specified for project reviews.

Differences in development methodology can occur, if one firm prefers a Rational Unified Process approach with exacting specifications while another firm prefers Agile. One firm may have a preferred tool in place for source code control or for coding standards or for testing builds. These issues can often be worked out by communicating the reason for each approach and then choosing a consistent methodology. Most frequently, you’ll ask the offshore team to adopt your in-house methodologies, but you may be surprised to discover that they have methodologies or tools that equal yours, especially if they have significant experience in a technology. This is where teamwork and communication between the project and development team managers is critical.

Related to methodologies is evaluating how the service provider handles sudden requests for large volumes or rapid delivery. Check on how flexible and scalable your vendor is and whether it has processes in place for hiring additional staff as required for larger projects. This includes having sufficient project management staff to ensure adequate monitoring and communication with your firm. Ask, “What is the smallest project you have worked on? The largest project?” to help determine whether they can scale to meet your needs. You’ll also want to check references for projects that are similar to yours.

–> Risk #5: Communication Barriers

Almost every significant study of outsourcing risks in the past decade has brought up the issue of communication and the risks associated with it.

Communication when outsourcing can be a concern for several reasons.

  • English fluency: Not all overseas vendors have staff who are native speakers of English.
  • Time zone differences: When it’s 11 a.m. standard time in New York City, it’s 9:30 p.m. in India. This can make it difficult to communicate with overseas vendors, due to time zone differences, unless they have a project manager onshore. Of course, this can also become an advantage. While your company sleeps, an overseas developer can be creating code for your project, enabling “around the clock” coding when coordinated with in-house staff.
  • Cultural differences: In the United States, we tend to be an “ethnocentric” culture, believing that our management and work styles are adopted around the world. In reality, overseas vendors may operate in a very different cultural context, which can lead to misunderstandings.

How to Reduce this Risk

When selecting a vendor for outsourcing, it’s important to evaluate whether the vendor has in place sufficient onshore staff to facilitate project and relationship management. This includes English fluency, and a strong company commitment to bridge cultural differences. The better overseas vendors provide services through a “best shore” methodology, or one that combines a local presence with access to overseas talent. This offers the best of both worlds: clear communication locally from an individual dedicated to understanding your requirements and the ability to discuss these with the “back and forth” that is only possible through face-to-face communication, with the cost savings possible through using offshore talent.

This model is the best for overcoming many of the problems often associated with outsourcing. This domestic office provides a local point of contact for more rapid communication of and resolution of issues that might arise and demonstrates a higher level of commitment to a personalized relationship when working with clients.

Communication with an overseas development team by phone or teleconference is much easier nowadays, with technologies such as VoIP or online conferencing, that allow you to call overseas at no or minimal cost. Again, your company’s designated contacts will want to hold regular review sessions with company project managers as well as key members of the development team. This can help establish common ground and improve understanding of what you hope to accomplish through project development. It also provides the developers with an opportunity to ask questions and clarify points.

The minutes of any teleconference meeting should be recorded and distributed to all team members after the meeting. The vendor you select to outsource to should have an established communication plan as part of each project. This will include the following:

  • Regular (minimum, bi-weekly) staff meetings with key project managers and project stakeholders.
  • A weekly project status report (by phone, supplemented by email documentation of the project status). This report should clearly identify any issues or roadblocks encountered, as well as the measures taken. Any questions or points that require clarification by the development team should also be raised in the report.
  • Ad hoc communications by email, chat or phone with your company’s designated contact for the project, to ask questions, clarify points or notify the contact of any important milestones or issues that have developed.

Open, frequent communication to discover and discuss the risks related to the project lets you come up with a plan jointly for addressing potential problems. Constantly monitoring these risks is something that goes a long way toward establishing a long-term successful outsourcing partnership.


Offshore outsourcing provides numerous benefits to firms that choose this option, from improved productivity, to reduced costs. But any outsourcing relationship poses risks. The best approach is to acknowledge the risks and communicate openly about them in order to create a plan to mitigate them. With careful planning and evaluation of vendors, you can enjoy an outsourcing experience that’s superior, maximizing the benefits and return for your company.

Useful Links

Hanu Software

Software Engineering Institute