<< . .

( 36)

. . >>

problems, disappointments, and eventually pulling the plug. We often hear stories of fail-
ure. For some clients, India has even become an abbreviation for “I™ll Never Do It Again”.
While a few managers will be thrilled by the challenge of the offshore journey (“Yes,
I want to go to exotic countries.”), they are a minority. For most staff, stepping into the
unknown is scary. It will bring them into contact with companies they have not heard
of before, mostly from countries with which they are unfamiliar. On top of that, journalists
52 The fundamentals

have given exotic labels to offshoring, such as a “Passage to India”, as if today™s IT
manager is going off to the land of the rajs in the 1800s.
Although still a novelty for many organizations, developing software offshore has a
history of more than two decades. In the early period, before the Internet, it was dif¬cult
for the pioneers to ¬nd information, and clients had to rely on a telex, a fax machine,
and on poor telephone connections for communication. It is a wonder that any interna-
tional collaboration could take place at all. Today, there is an abundance of information,
communication is easy, there are thousands of providers to choose from, and we can
quickly learn from the lessons of many companies that have already offshored. Some
of these lessons involve failures, though in general offshoring is not as dif¬cult as some
potential clients fear.
For example, the overhead of managing offshore projects is often overestimated among
companies not using offshore services. The security risks and the nightmares of cultural
and language differences are sometimes overstated. An A.T. Kearney study revealed
that more than 80% of ¬rms surveyed said that the quality of functions sent offshore
was as good as or better than before.1 Even many of the early adopters of offshoring that
contended with less mature markets still succeeded most of the time.
There are, however, some common outsourcing mistakes, such as having overly
optimistic expectations, a lack of internal support, having unclear speci¬cations, or select-
ing the wrong provider. The principal error is underestimating the importance of prepara-
tion. Therefore, this chapter is devoted to preparation for the offshore journey. Journey
preparation, depicted in Figure 3.1, consists of three major phases: laying the founda-
tion, identi¬cation of potential service providers, and assessing and selecting the
provider. Proper journey preparation will not guarantee 100% success, but will cer-
tainly diminish the possibility of failure.

Phase 3:
Phase 1: Phase 2:
Assessing and
Laying the Identifying the
selecting the
foundation providers

Assessing your offshore Locating providers
readiness Country selection
The offshore visit
Setting up a powerful Developing criteria for
Making the
launch team provider selection
Hiring external expertise The request for information
and contract
Creating a strategy and (RFI) and the request for
a plan proposal (RFP)
Select the right project to

Figure 3.1 The three phases of preparation for the offshore journey.
53 Beginning the offshore journey

Many of the tasks encompassed in the journey preparation are those of a general,
well-managed provider selection process that may even be part of a procurement man-
agement methodology.2 In other words, these tasks can also be used when searching for
a domestic partner. However, in this chapter we emphasize the elements that are unique,
or more dif¬cult, or merit special attention when offshoring. Outsourcing is the most
common way for organizations to begin the offshore journey. In fact, roughly 90% of
the companies offshoring to India are outsourcing. Therefore, the focus in this chapter
is on the offshore outsourcing journey.
A key question before journey preparation begins is: How long does it take? It took a
large Dutch organization we know one-and-a-half years to conduct internal discussions,
to select the ¬rst projects, and to ¬nalize the search for suitable offshore partners. In
addition, several trips abroad were needed to convince the managers of the quality of
these offshore ¬rms. While this is an extreme example, it illustrates our contention that a
firm should not be rushed. We have helped ¬rms move diligently through the three
phases while making decisions quickly. Most small ¬rms can do a respectable search in
2 months. Large companies, which intend to outsource large projects and want to assess
different partners, often need more time. For these large ¬rms, it is not uncommon if
the provider selection process takes as much as 6 months or more.

Phase 1: Laying the foundation

Some users begin the offshore journey haphazardly, running off to sign a contract with the
first provider they meet. This sometimes works, particularly with simple, small projects.
In general, however, a deliberate approach based on a vision, with clear targets and
with a proper provider selection process is required for success. The ¬rst phase in the
preparation for the offshore journey is to lay a solid foundation. It includes the tasks of
assessing the organization, setting up a launch team, creating a strategy and a plan, and
selecting a (pilot) project. Some tasks in the phases are largely iterative with lots of “feed-
back loops” and need to be done in parallel; their order here is not always suggestive
of a sequential ordering.

Assessing your offshore readiness
Is your organization really ready for offshore? For most clients, outsourcing software
work to an offshore provider is not “business as usual” and several questions need to be
answered ¬rst. Has there been offshore experience in the past? How is the maturity of the
project management? Are they capable of managing international projects? How is the
organizational ¬‚exibility? Is staff familiar with working with people from a different
culture? Are they willing to travel? Will the employees of the organization accept this
change in work norms? How is the complexity of the technical infrastructure? Are the
processes stable and in place?
54 The fundamentals

Companies need to consider taking the hardest step early on: improving internal
processes ¬rst. These improvements include instituting mature project management prac-
tices and collecting accurate performance metrics for benchmarking. In a survey among
North American offshore clients, 53% of the respondents reported having challenges in
project management skills, 51% did not have good processes for specifying the work, and
48% did not have the right metrics for managing the performance of the provider.3 Some
of these companies were probably not ready for offshoring or, at best, should move for-
ward cautiously.
When in doubt, the organization should conduct an internal assessment of its offshore
readiness. As part of the offshore assessment, managers need to do a risk assessment
and have an honest discussion about their tolerance for risk. This should take place
during Phase 1 of the offshore journey preparation. If the outcome is negative, a no-go
decision should be made. As a matter of fact, these negative decisions do happen. In
such situations, organizations can consider offshoring at a later time. A Dutch com-
pany decided in favor of offshoring 5 years after a previous no-go decision was made.
The large Dutch bank ABN Amro is offshoring to several providers in India and
Pakistan. It uses a spiderweb chart to assess the offshore readiness of its internal busi-
ness units (see Figure 3.2). The chart is a useful focal point for decision-making dia-
log. Values are given on a scale from 1 to 5, for six internal criteria: the maturity of IT
project management, the complexity of the technical infrastructure, the organizational
¬‚exibility, previous offshore experience, IT operations and support capacity, and the
maintenance capacity.

Maturity of IT project management
(1: none; 5: very high)

Complexity of the technical
Maintenance capacity 2.5
(1: none; 5: very high) 2
(1: very high; 5: very low)

Organizational flexibility
IT operations/support capacity
(1: very low; 5: very high)
(1: none; 5: very high)

Offshore experience
(1: none; 5: very high)

Figure 3.2 Applying the spiderweb chart to a business unit at ABN Amro Bank to assess offshore
55 Beginning the offshore journey

The spiderweb chart shows internal strengths and weaknesses at a glance: the larger
the shaded area, the better the chances to succeed offshore. Low values are warnings,
and Figure 3.2 indicates that the high complexity of the business unit™s technical infra-
structure is a concern. On the other hand, it is strong in maintenance and project man-
agement, and it had some previous offshore experiences. Given these strengths, this
business unit could consider offshoring, provided the weakness can be addressed. For
example, it might be necessary for some of the offshore provider™s staff to work onsite
to master the complex technical infrastructure and to help the bank™s unit adjust.

Setting up a powerful launch team
Since offshoring is more complex than domestic sourcing, it is critical to establish a pow-
erful launch team that builds a strategic vision, demonstrates commitment, and transitions
into implementation. The launch team is responsible for all tasks during the prepara-
tion of the offshore journey. This is the team that creates the plan, builds organizational
support, selects the provider, and negotiates the contract.
The launch team should be small in order to be agile and to make quick decisions. Its
members should include people who are open to offshoring, have an international outlook,
and are willing to travel. The launch team may report to a steering committee, consisting
of the chief information of¬cer (CIO), senior IT executives, business unit managers, and
legal staff. The launch team should also have good networks inside the organization in
order to build internal interest and sponsorship.
The team members need to develop deep expertise in offshoring. Besides the many use-
ful websites and research reports,4 they need to seek knowledge both inside and outside
the organization. There may be people inside the organization with offshoring or other
international expertise that can be tapped for knowledge or brought in as supporters and
sponsors. On the outside, team members can go to professional cocktails, visit seminars
and trade fairs, and attend country-speci¬c events. They can ask around in their own
professional network and talk to other IT shops with offshore experience. The team
should identify organizations similar to their own and ¬nd out about their experiences;
it is not necessary to reinvent the wheel.

Hiring external expertise
Since many offshore countries and providers are not well-known, managers with little
international experience should probably not embark on an offshore journey alone.
Consider buying knowledge from experienced consultants in order to be a more informed
buyer. Proper preparation for the offshore journey is also time-consuming. Hiring external
expertise on a full- or part-time basis speeds up the process and saves valuable time for the
launch team.
Before 2000, there were hardly any specialized offshore consultants. Now there are
many to choose from.5 Some consultants are specialized in one country (which is often
56 The fundamentals

India); others have a more global reach. These companies advise on issues, such as
creating an offshore strategy, identifying projects suitable for offshoring, selecting coun-
tries and providers, conducting due diligence, and arranging site visits. There are so
many offshore advisors that we even know of companies which rate and verify the
expertise of potential offshore consultants.6

Creating a strategy and a plan
The offshore journey should begin with an offshore strategy and an operational plan.
“Failing to plan, is planning to fail”, is an appropriate proverb for this stage of the journey.
The strategic goals of offshoring should be de¬ned and understood at the outset of the
journey. Of course, in most situations, the goal is simply to achieve cost reduction
based on wage differentials. But, this is too vague a goal to be successful in the long run.
A more speci¬c goal could be: “Reduce the total IT budget by 7% within 3 years by
using offshoring resources”. Companies should also begin to formulate other offshore
goals that are more than merely cost reduction goals. We discuss other strategic goals,
such as an increase in speed and ¬‚exibility, later in Chapter 5.
Once the strategic goals are articulated, they need to be operationalized. Since organ-
izations spend several years learning to manage the offshore cooperation successfully,
an initial long-term plan should be created. The offshore plan should begin to articu-
late the future human resource (HR) needs; more speci¬cally, the skill sets of your IT
staff and the capabilities required from them in the future. The plan will state which
projects are most suitable for offshoring (which we discuss in later in this section). It will
prioritize all activities needing longer lead times (e.g. hardware and software requirements
at the offshore site, additional training for offshore staff and internal staff, and knowl-
edge transfer). The plan will also have an early risk assessment, which includes iden-
tifying risks and planning for mitigating each of these risks.
As part of the offshore plan, the launch team will draw up a budget for all three phases
of the offshore preparation. The preparation costs can be substantial. Search costs
include signi¬cant organizational time in documenting requirements, determining
which projects or processes are to be offshored, and many hours on provider assess-
ment. Search costs also include external costs, such as hiring external advisers, hiring
legal counsel, travel costs, and translations.
In many organizations, launching an offshore initiative will involve preparation of a
business case, which is the ¬nancial justi¬cation for the offshore strategy and consists of
an estimate of the costs, the cost savings, and offshore risks. The business case is usually
a document accompanied by a formal verbal presentation to management. Depending on
the sequence of decision-making, the launch team may want to make a preliminary busi-
ness case for offshoring at the very beginning of the preparation phase. Others will
develop the business case later in the journey preparation stages, after the strategic vision
is accepted, the plan is stable, and perhaps after making preliminary offshore visits.
57 Beginning the offshore journey

The business case needs good data. A preliminary estimate of offshore costs should not
overlook the “extra” offshore costs, such as additional overhead and knowledge transfer,
which is the signi¬cant investment of time and effort in educating the offshore staff about
the system and its uses. The other data are good internal performance indicators (which
were mentioned as part of the assessment of offshore readiness). Performance indicators
are needed to measure success. Organizations must know their real internal costs and pro-
ductivity ¬gures: on-time delivery, user satisfaction, service availability, response times,
and error rates. If these are not quanti¬ed, then it will not be possible to judge offshore
success or failure. The business case also bene¬ts from good qualitative data: the offshore
activities of competitors could serve as a benchmark. Survey the successes and failures of
other organizations and draw lessons from both as they apply to your own company.
Finally, the offshore plan must anticipate a key organizational issue, namely that
people never like change and that organizational resistance is one of the key barriers to
offshoring. There are numerous change management approaches to address such resist-
ance. They include implementing measure and reward systems to motivate offshoring,
the creation of new organizational structures to support change, funding demonstration
projects, and education about offshoring. These and other mechanisms of organiza-
tional change are described in Chapter 7. The HR department should be involved early,
in part to ensure retention of critical people. HR should de¬ne a staff retention plan,
arrange for retraining programs, plan for internal or external transfers, develop redun-
dancy packages, and plan for dialog with trade unions.

Selecting the right project to start
The offshore journey can begin with a methodical, systematic, comprehensive inven-
tory to decide on the right ¬rst project, or follow a more organic decision-making
process and go with a pilot project. We describe each of these approaches here.
Careful preparation for the offshore journey means that the company inventories its
applications and systems. Many questions need to be answered to assess if applications
are suitable for offshoring. Is the scope of the work, and the functional requirements,
clear? Is the technology being used standard or emerging? What is the maturity of the
application? Are the connections with other applications tight or loosely coupled? What
is the size of the work? Is knowledge transfer going to be dif¬cult? Is there suf¬cient
documentation? Can most of the work be done offshore or will it involve an onsite com-
ponent? Is the implementation in a single location or multiple locations, or global?
From such guiding questions, the launch team will get various derived measures,
such as criticality, complexity, annual costs, stability, and size. Applications and sys-
tems should be ranked as having a high, medium, or low potential for offshoring. The
¬nancial impacts of offshoring will also differ for each of these: they can give low,
medium or high savings. Based on the offshore potential and the potential ¬nancial
returns, the most suitable application(s) can be selected and a more detailed cost savings
58 The fundamentals

Scope (1: none; 5: very clear)
Maturity (1: 1st release; 3
Functional requirements
5: small maintenance) 2.5
(1: none; 5: very clear)

Size (1: very large; Solution direction
5: very small) (1: none; 5: very clear)

(1: very high; 5: very low)

Figure 3.3 Applying the spiderweb chart at ABN Amro Bank to assess which project is suited for

analysis can be done. This is the core of the offshore “business case”. The summary
¬ndings will become part of the “scope de¬nition document”, which can be used to
internally sell and communicate to management and staff.
Figure 3.3 shows another spiderweb chart used by ABN Amro Bank “ this one is
used to assess which project is best suited for offshoring. Values are given on a scale from
1 to 5, for six criteria (scope clearness, functional requirements, solution direction, risk
and complexity, size, and maturity of the application). The spiderweb shows that the
maturity of the application is a reason for concern since, in this case, it will be a ¬rst
release. This requires speci¬c attention: it might be necessary to hire speci¬c offshore
expertise, or to build a prototype ¬rst.
The Offshore Stage Model, introduced in Chapter 1, reveals that most ¬rms move
through an experimental phase as they begin their offshore journey. They start slowly and
test the waters for a year or more. In the spirit of starting slowly, consider ¬rst offshoring
your company™s less critical projects and systems. These are small, structured, and non-
strategic jobs, such as programming, testing, or conversion work. For example, you can
start with support activities and move later to new development work. It is easier to off-
shore a migration project, where functionality is stable, and only the technology plat-
form differs, than a new application to be built from scratch. Another approach is to start
with tedious work, such as maintenance. This will foster internal support, since it gives
employees the opportunity to work on more interesting tasks, such as new technologies,
and to learn new skills.
If your company has no experience with offshoring, conducting a pilot project is rec-
ommended. A pilot project is useful to test if your company is ready for offshoring, but
also to test a certain country, or to assess a new provider. It also allows you to set another,
59 Beginning the offshore journey

more advanced milestone, before the ¬nal go/no-go decision is made on offshoring. If
the pilot proves satisfactory it can be used internally to communicate its successes and
to learn from its problems.
A pilot project should be a low-risk task that is allowed to fail. It should have a relatively
low level of complexity in an isolated environment (e.g. no interaction with legacy sys-
tems). Some companies select a project which they already did themselves in-house. A
pilot must have the right size in order to be meaningful: one that is too small is useless; too
large is not appropriate for a test. A pilot can run from several weeks to 6 months.
Measurement and tracking are needed to conduct a proper pilot. The pilot could con-
tain intermediate products (detail designs, prototypes) to track performance. Overall
performance should be measured using the following criteria:
— Quality, both technical (e.g. number of bugs) and functional (e.g. does it meet

— Cost and productivity (a provider might not have the lowest rates, but can be faster).

— Project cooperation, such as project style, communication, responsiveness,

problem solving capabilities, documentation, and planning discipline.
Some clients have been quite creative and disciplined in inventing offshore pilot meth-
ods. We illustrate this with two clever cases. The ¬rst is a small American software ¬rm,
SSI, which attempted to conduct parallel pilot projects in India, Russia, and China in
order to choose a country: the detailed case study appears in Chapter 4. The second is
the case of Sogeti Netherlands, a large IT services provider, which wanted to test an
offshore provider. In order to do so, Sogeti developed the same project twice: both
in-house and by contract with the offshore provider:

Sogeti™s goal was to decide if Indian provider NIIT would be a suitable partner.
Sogeti decided to conduct a comparison and perform much of the project life
cycle twice (from low-level design through integration): both in-house at the
Dutch Sogeti of¬ce and offshore at NIIT in India.

Sogeti chose a real-life project that it was conducting for one of its clients: a
web application involving document imaging and business rules supporting
work¬‚ow, running on a .NET/Citrix platform. The pilot™s size was 700 Function
Points. One Sogeti staff member made a visit to India for knowledge transfer,
though it was not required by the Indian team to make any onsite visits. A
knowledge portal was created for communication between the two teams. This
served as a single repository for technical documentation and deliveries, query
resolution, and project management documentation. Processes were de¬ned for
project planning (e.g. weekly teleconferences), quality assurance, metrics
management, requirements management, and delivery management.

<< . .

( 36)

. . >>

Copyright Design by: Sunlight webdesign