|
In recent years, increasing numbers of businesses have chosen 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 white paper, we will discuss each risk in turn, as well as methods of mitigating the risks
when outsourcing overseas.
Introduction
Offshore outsourcing has grown exponentially in recent years. Gartner, Inc., a technology
services research firm, estimates that global outsourcing will become a $50 billion industry by the
end of 2007. This growth in the sourcing out of either individual projects, or the development of an
extensive partnership relationship between a domestic firm and one overseas, has been fueled in
large part by the significant cost savings (between 20% and 50%) that are enjoyed by firms that
choose to outsource.
But cost savings are only one reason that companies outsource
overseas, and in recent years has become less important than
other benefits. The number one benefit cited in a recent study1
by Diamond Cluster, an IT research firm, was the freeing up of
internal company resources. By outsourcing, a company was
able to use their on-site staff more effectively on core business
processes. The second most important factor was the ability to
access technological skills of a high quality that were
unavailable or in insufficient supply in-house, with cost running
third.
|
Why do companies outsource?
- Freeing up of company resources to concentrate on core tasks
- Access to quality technological talent
- Reduction in operating costs
- Reduced time-to-market
|
You may have considered outsourcing for any of these reasons. But you may not be able to enjoy
these benefits if problems occur in the outsourcing relationship -- and they can, if risks are not
identified.
Basically, risks during outsourced project development are related to three factors:
- People
- Processes
- 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 U.S. were surveyed recently1, 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 are
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 One: 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, firms that are outsourced 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 are 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, versus 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 be
able to implement it.
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.
Reducing the Risk:
Never force a software vendor to "guess" at what you want built. While engineers are often
talented individuals, they are not mind readers, and as mentioned before, there are many
different paths to building a product, but 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 is 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 you are 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.
|
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
|
The better vendors will make this as easy as possible on you
(or your company's designated contact). They will 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 will know what
questions to ask, and based on their experience, can capture
project details and requirements relatively quickly. It will often
take several discussion, either on-site (for larger projects) or by
phone/teleconference. But it is 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.
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 is
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 a successful outcome
when outsourcing cannot be over-emphasized. A strong initial analysis will significantly reduce
unexpected project costs. Once this phase is completed, you will have a detailed requirements
document, which you and the outsourcing firm will jointly review and sign off on. This becomes
the guideline for development, and will provide clearly defined parameters for project
development.
Risk Two: Quality Assurance
Even the best development teams create code that has "bugs", which is why quality assurance,
whether development is completed onshore or offshore, is important. A major risk when
outsourcing to an unknown vendor is whether they have adequate quality assurance/testing
processes in place. Waiting for product release to find out what bugs are present is not the best
scenario, and taking time to check on the QA processes a vendor uses can reduce this risk.
The three main reasons that quality assurance is not done, or is done inadequately, are:
- The company outsourced to does not have its own QA/testing team, and assumed that the client would complete this in-house.
- The project had a very tight deadline, and so QA testing was done rapidly, or set aside to give development a priority.
- The vendor did not understand fully the system requirements, and so testing did not cover them.
Reducing the Risk
|
Quality Assurance 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
|
One of the first things you will want to evaluate in a possible
software vendor is what quality assurance processes they have
in place. The better vendors have their own quality assurance
team in place that works 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).
It is 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, or one that is bug-filled.
Once development is completed, the quality assurance 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 conduct 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 quality assurance activities,
such as design reviews, can save a firm from three to ten hours in downstream costs. You
should ask your offshore vendor to conduct inspections at each stage of the development or the
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 that is left
undetected until construction or maintenance will cost fifty to 200 times as much to fix as it would
have cost to fix when the system requirements were originally being developed.
Risk Three: Intellectual Property Protection
Your intellectual property is one of your company's greatest assets, and when outsourcing, it is
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.
|
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
|
Make sure that the vendor you are outsourcing to has in place
clear, enforceable policies for protecting the data you share
with them. At the minimum, this includes signing a nondisclosure
agreement, a non-compete agreement, and a nonsolicitation
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 an
outsourced firm uses their proprietary technology, or an Open
Source technology, to develop a new product that will be used
by your new application. In this situation, it is important to
predefine what source code belongs to the vendor, and what
belongs to you, the client, and to clarify any licensing issues.
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 will 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 does not have a documented Information
Security Management (ISM) policy in place, you should search elsewhere for a vendor that does.
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, and implementing them, you will take large steps towards
protecting your firm's intellectual property.
Risk Four: Differing Internal Processes
Each vendor will have somewhat unique processes and methodologies that they follow when
developing a project. It is important to evaluate how this differs from your in-house processes,
and how the two differing approaches can best be "meshed" together during a development
project.
It is 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.
|
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
|
Once the process is agreed upon and established, it is equally
important that monitoring is 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 their 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 is 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 telephone
conference. 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.
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 firm outsourcing, 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 an RUP approach with
exacting specifications, while another firm prefers agile methodologies. 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 will 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 are evaluating how the firm being outsourced to handles sudden
requests for large volumes or rapid delivery. Check on how flexible and scalable your vendor is,
and whether they have processes in place for hiring additional staff as required for larger projects.
This includes having sufficient project management staff in place to ensure adequate monitoring
and communication with your firm. Ask them: "What is the smallest project you have worked on?
The largest project?" to help determine whether they can scale to meet your needs. You will also
want to check references for projects that are similar to yours.
Risk Five: Communication Barriers
Almost every significant study of outsourcing risks in the past decade has brought up the issue of
communication, and the risks associated.
Communication when outsourcing can be a concern because of:
- English fluency: not all overseas vendors have staff who are native speakers of English
- Time zone differences: when its 11:00 am in New York City, it's 7 pm 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.
Reducing the Risk:
When selecting a vendor for outsourcing, it is 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 not only the company project managers, but key members of the development
team. This can help establish common ground, and improved understanding of what you hope to
accomplish through project development. It also provides the developers with an opportunity to
ask question and clarify important 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 to 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 and jointly
come up with a plan for addressing and constantly monitoring these risks is something that goes
a long towards establishing a long-term successful outsourcing partnership.
Summary
Offshore outsourcing provides numerous benefits to firms that choose this option, from improved
productivity, to reduced costs. But any outsourcing relationship will have some risks. The major
risks identified are related to people, process and communication, as defined within this paper.
The best approach is to acknowledge the risks, and to communicate openly about them in order
to create a plan to mitigate potential risks. With careful planning, and evaluation of vendors, you
can enjoy an outsourcing experience that is superior, maximizing the benefits and return for your
company.
References
1. Weakland, Tom, "2005 Global IT Outsourcing Study," © 2005 DiamondCluster International, Inc.
About the Author
Anil Singh is Founder & CEO of Hanu Software.
Anil founded Hanu Software after completing his Master of Science in Information Systems from New York University.
Anil has over ten years of experience as a software developer and technical lead at companies including Fujitsu ICIM,
and Infosys. He completed his bachelor's degree in Electronics from the Institute of Technology, Banaras Hindu University.
Anil is involved in all facets of Hanu's operations from Business Development to Project Delivery, from Sales &
Marketing to Customer Accounts management. Anil is an expert in the Offshore Delivery Model, and he is also author
of various software processes used at Hanu Software.
About Hanu Software:
Hanu Software is a global IT consulting and services provider, with corporate business offices
located in Princeton, New Jersey and engineering campuses located in Gurgaon, India. Founded
in 2002, our firm is dedicated to developing effective outsourcing partnerships with clients in order
to reduce their IT costs, improve process management and reduce time-to-market for new
product ideas. We provide end-to-end software solutions in a variety of industry verticals,
including publishing, finance, real estate, insurance, retail and others.
For more information, please visit our company website at www.HanuSoftware.com.
|
