The root of this failure is that companies do not manage the patient process of
knowledge transfer. And, perhaps the offshore outsourcing provider is pressured to
deliver quick returns and reluctantly agrees to overly ambitious transition plans that hinge
on rapid knowledge transfer. When complex applications are produced offshore without
sufļ¬cient attention to knowledge transfer, the problems will be discovered during the
costly integration and implementation phases. In such a case, the offshore development
costs are, indeed, cheaper, but they are washed away in the ļ¬nal stages of the project life
cycle when extra resources are required to correct mistakes. Similar dynamics occur when
infrastructure management activities are offshored without patient knowledge transfer.
Many issues will revert back to knowledgeable experts at the home location, thus
negating the labor cost savings.
Some of the knowledge that needs to be transferred offshore can be codiļ¬ed and
written down. This is often called explicit knowledge. These are the facts, principles, and
speciļ¬cations. In general, explicit knowledge tends to be the easiest one to transfer. Such
knowledge may be captured in Knowledge Management Systems that many organizations
have today. But in many organizations much of the knowledge that can be codiļ¬ed is not
documented. So, time and effort must be invested to document this knowledge when the
offshore engagement begins.
The more difļ¬cult knowledge transfer is for tacit knowledge.4 Tacit knowledge is that
which is difļ¬cult to write, document, or codify. It is fuzzy knowledge learned from
practice, exposure, and experience: in other words, the āknow-how.ā It is also the āknow-
whoā of social relations. Much of the tacit knowledge can only be transferred through
learning by doing, through āshow-how,ā when one person learns on-the-job through
mentoring and coaching.
To use an analogy in the game of chess, the game rules can be documented in just a few
pages. These rules represent the explicit knowledge. But this is not sufļ¬cient to become
a strong chess player. The knowledge to play chess well is the tacit knowledge learned
from experience, from trail and error, from coaching, and from very specialized books on
The four types of knowledge that need to be transferred offshore are (see Figure 7.1):
ā— Skills, such as new programming language.
ā— Process, such as harmonizing methodologies between onshore and offshore sites.
ā— Domain, such as business, scientiļ¬c, algorithmic, and artistic.
ā— Work and cultural norms, such as organizational and national culture.
The ļ¬rst type of knowledge transfer is the least problematic: transferring speciļ¬c
skills, such as new tools, special programming languages, or specialized packages. Much
of this knowledge can be transferred in writing. Additionally, classes are offered in
most countries, so travel is not required for transfer.
Transferring process knowledge is somewhat more difļ¬cult. In essence it is about
harmonizing methodologies between the distant units so that they can collaborate effec-
tively. This issue has appeared most prominently in the mismatch between the large Indian
132 Managerial competency
Degree of difficulty of knowledge transfer
Figure 7.1 Knowledge transfer types.
providers practicing advanced process methodologies (such as the Capability Maturity
Model (CMM)) and their clients in which process maturity is low or lacking. In these
cases it is the client staff, rather than the offshore staff, that must acquire knowledge in
order to make the offshore engagement work more effectively. Ideally, the client elevates
its internal software practices to CMM Level 3 or ISO 9001 before beginning the offshore
work. However, this is uncommon because moving up the CMM levels requires, at the
very least, 6 months per level. Most client organizations are not interested in making
such a commitment and instead, a sufļ¬cient alternative is to faithfully comply with the
requirements of the providerā™s CMM processes.
The last two types of knowledge are largely tacit knowledge that cannot be easily
transferred via training and documentation. The ļ¬rst of these knowledge transfer types,
domain knowledge encompasses specialized business, scientiļ¬c, algorithmic, or artistic
Some organizations recognize the difļ¬culty of domain knowledge transfer and are
proactive in managing it. For example, when the internal information systems staff at
Wal-Mart, the largest retailer in the world, embarks on a project, they go through a rota-
tion in the end-user area. If, for example, they are tasked with working on the Point-of-
Sales systems, they go work at the registers for a few weeks helping customers to checkout
Domain knowledge transfer often fails when the offshore engineers do not fully under-
stand how the software will be used. Domain knowledge is vital in nearly all activities
offshored. When application maintenance tasks are transferred offshore, then the new
software engineers need to understand the implicit, tacit link between the code, the data,
the business rules, and the ways they are used. When new software development is con-
ducted offshore, knowledge transfer is straightforward if the software can be precisely
133 Managing the offshore transition
speciļ¬ed but software is rarely speciļ¬ed precisely. Sometimes the difļ¬culty revolves
around usability issues, such as how credit cards are used or how decision-making is
actually conducted. The case study in this chapter (called āEating your own dog foodā)
describes such difļ¬culties.
The last knowledge transfer type is labeled āWork and cultural norms.ā This is the most
difļ¬cult type of knowledge transfer. It encompasses deeply set cultural norms that have
to do with foreign cultures, how foreign clients work, as well as organizational cultures.
The two chapters that follow (Chapters 8 and 9) cover these issues in greater depth.
Since tacit knowledge transfer is primarily about transferring knowledge into the
minds of people (rather than into systems), the principle solution revolves around face-
to-face interactions. Human beings traveling between distant sites are the principle
conduit for knowledge transfer. Travel can be of any duration, but extended rotations may
One large American ļ¬nancial services company institutionalized knowledge transfer
in an interesting way. The ļ¬rm had been working offshore for three years and regularly
rotated offshore staff to the USA every 3 months. Four to eight people would come in from
India every 3 months. Once they returned then another group came to the USA. This
would be repeated every 3 months. Over time, some of the offshore staff had been to the
USA several times. Naturally, this was costly, reducing the offshore savings, but the
company felt that the expense was justiļ¬ed because of successful knowledge transfer.
Offshore providers have recognized that knowledge transfer is a serious difļ¬culty and
needs to be managed properly. One offshore provider developed a knowledge transfer
methodology it called knowledge acquisition process (KAP).5 Such knowledge transfer
methodologies are based on two principles: extensive documentation and intentional face-
to-face interaction. Speciļ¬cally, they call for onsite presence in the ļ¬rst few months, shad-
owing employees to learn their jobs, and documenting the knowledge as much as possible
into service level agreements (SLA), plans, and technical documentation.
Case study Knowledge transfer by āEating Your Own Dog Foodā
One successful approach to knowledge transfer is to use a method with a colorful
expression: āeating your own dog food.ā The term gained wide usage after it was
popularized by Microsoft in the early 1990s. In this method, once the product is
minimally usable, the programmers use the software product on a day-to-day basis,
to synchronize their activities, or as their own development platform. By using the
software product the programmers are able to make better minute design decisions
and are quicker to ļ¬x its bugs.
GroupSystems.com, a small US-based software company, decided to outsource
offshore all software development activities for a major release of its ļ¬‚agship product ā“
a platform that supports collaborative decision-making. In 2001 it was time to
create a new vision for the product and change its underlying architecture. This was
134 Managerial competency
a signiļ¬cant undertaking for this small ļ¬rm. GroupSystems contracted with IISC,
one of the top ļ¬ve Indian offshore providers (IISC is an alias).
The new product included a great deal of tacit, ādomainā knowledge, as Bob, the
GroupSystems R&D Director, emphasized:
āRelative to most software products, the user interface requirements for such a
collaboration tool are more nuanced and sensitive to subtle variation.ā
Problems in transferring knowledge began to surface soon after development began.
While the offshore programmers were skilled at coding, they did not grasp the prod-
uct vision. Technical speciļ¬cations could not capture all the usability possibilities in
full. For example, Bob had written 37 pages of high-level requirements on just one
feature of the user interface. This one feature included subtle usability capabilities:
how to manage selection of shared text blocks on one screen while other users (on
other screens) were simultaneously adding to, modifying, moving, and deleting text
in the same document. Even with such a level of detail, however, he acknowledged
that he was unable to anticipate and specify every small design detail in the user
The written speciļ¬cations and frequent trips across the Paciļ¬c could do only so
much. None of the 25 offshore programmers had any experience using, or develop-
ing, a collaborative product and did not fully absorb when and how it should be
used. Furthermore, the programmers were reluctant to ask clariļ¬cation questions.
Since they did not ask, they were forced to make small, seemingly arbitrary design
choices; these are choices which often thwarted the productā™s intended uses. To
make matters worse, on numerous occasions the offshore programmers resisted
design choices made by the GroupSystems staff, arguing that the speciļ¬cations
were unnecessarily fussy, and that āthere are faster, easier ways to do it.ā
Thirteen months slipped by and the product fell further and further behind. More
than 250,000 lines of code were written that eventually had to be thrown away. The
project was at a crossroads and the future of GroupSystems was in doubt. Managers
from IISC and GroupSystems held a crisis summit. As a result, IISC re-organized the
project team, and assigned Arun, a seasoned Project Manager, to this troubled project.
The new project team, though, had a typical composition: 40 very young, bright
software engineers. Most were just a few years out of the local second-tier univer-
sity. All had engineering or computer science degrees, but none had any training in
business. Nor were they ever involved in the subtle issues of collaborative decision-
making in an organization.
Arun drove his team hard. Most importantly, he taught his programmers how to
ask questions and then how to listen. He taught them to seek clariļ¬cation of any
ambiguity or doubt before they wrote code. The team held trans-continental phone
conferences on a daily basis to review progress and clarify concepts.
135 Managing the offshore transition
It was at this point that GroupSystems hit on an idea. Since the programmers
were still struggling to understand the product, then why not have the team use the
very product that they were developing? In other words, why not have them eat their
own dog food?
As soon as the new code was barely stable, Bob traveled to India and spent a day
creating a rudimentary simulation exercise for the programming team. He created a
ļ¬ctional scenario in which the IISC team would āmeetā using the GroupSystems
product. The goal of this meeting would be to write a proposal in response to a
request for proposal (RFP) for a payroll system that will be bid on by IISC. A mock
script was created for each step, complete with an embedded IISC logo in each
module to make it look as realistic as possible. Thirty team members were then dis-
tributed across the IISC campus and began a distributed meeting using the software
product. The team was walked through ļ¬ve typical steps in proposal writing, mov-
ing through a complete proposal-creation cycle.
āIt was then that I saw all the light bulbs switch on,ā recalled Bob. āNot only
was I deluged with good questions and comments, but I got comments along the
lines of: ā˜Now, I understand why you asked for the drag and drop design the way
you did.ā™ ā
From that point onward, the Indian programmers used the product several times
a week, to see how it felt and how it performed when used as it would be in the ļ¬eld.
The usability problems that had plagued the project now melted away. The quality
of delivered code soared was compared to industry benchmarks. A full commercial
product was released 12 months later.
Organizational Change Management: Making changes in a planned, systematic
fashion with the focus on instilling new attitudes, behaviors, and consensus
building within an organization.
Employees and managers around the world have offered many valid objections to off-
shoring. Here is a smattering: itā™s not secure (our data will be compromised); the savings
are overstated (here is a magazine article about an offshore ļ¬asco); our employees will
be laid off; what happens if our systems go down because of offshore instability? (there
was a terrorist bombing there yesterday); āitā™s core, so weā™ll never offshoreā (my system
is too important to the ļ¬rm); there are too many miscommunication problems (they donā™t
speak English very well). Or, one unspoken objection: āI donā™t really want to deal with
people from that country.ā This is merely a partial list.
136 Managerial competency
In short, offshoring, which represents an organizational change, meets resistance
inside organizations. Such is the case of a major US corporation described in the next
case study later in this chapter.
In order to address such resistance, Change Management approaches include:
implementing measures and reward systems to motivate offshoring, creating new orga-
nizational structures to support change, internal selling, funding demonstration projects,
education about offshoring, and implementing human resource policies to reassure
employees of their positions. We cover each of these approaches below.
Change can be hastened by organizational measures and rewards linked to these mea-
sures. Such measures have been used successfully for offshoring in quite a number of
American companies. For example, a speciļ¬c goal can be set to increase offshore head-
count from 5% to 8% within 18 months. GEā™s famous 70:70:70 mandate for offshoring
was described in Chapter 5 and may be the ļ¬rst of these offshore measures. Once the
offshore goal is established, then executives need to reward and enforce meeting this goal.
Change is also brought about by creating the right organizational structures.
Offshoring is often managed by centralized units within large corporations, sometimes
from within the ofļ¬ces of the Chief Information Ofļ¬cer (CIO) or the Chief Technology
Ofļ¬cer (CTO). We have found that many of these units have adopted the word āglobalā
in their names, and thus: Global Engineering, Global Resources, Global Services.
Global is a word that creates less resistance than offshore. We will refer to this generic
organizational unit as the Global Sourcing Unit. The Global Sourcing Unit may be a
part of a Global Information Ofļ¬ce (see the governance section later in this chapter).
The role of the Global Sourcing Unit is to assist various internal users in assessing and
migrating offshore. It houses offshore knowledge bases, such as provider and country
information. In some instances, the Global Sourcing Unit implements the new mea-
surement and reward systems, mentioned above, that encourage project-level decision-
makers to ļ¬nd the best software resources, inside or outside the corporation. It may
also work with the various corporate divisions in conducting an inventory of the corporate
systems in order to identify the best candidates for offshoring. In so doing it should also
help identify the roughly 20% of IT functions that are truly too complex or proprietary
to be considered for offshoring.
The Global Sourcing Unit is sometimes headed by the āoffshore champion,ā who is
usually a seasoned manager. The offshore champion is the change agent, and plays the
typical evangelist role. She becomes a āsalesperson,ā generating excitement for the
cause and āsellingā the offshore vision internally. She communicates the offshore
vision and strategy to reluctant managers. She sets up seminars and develops internal
sales brochures. Like politicians, the offshore champions do not see any drawbacks in
their cause: it is clearly the way to go. Get on the train! The offshore champion needs
to be well respected. In fact, the most effective change management path is to earn
respect, rather than force compliance.
The Global Sourcing Unit is also the catalyst for demonstration projects to bring
about change. One of the quickest offshore change management programs took place
137 Managing the offshore transition
at a large American company that budgeted several million dollars for such a catalyst
program. The offshore champions roamed around the organization and dangled money
in front of various IT managers saying, in effect: āWeā™ll give you extra budget to do
this project if you offshore it.ā Within less than a year the company completed 80 (!)
offshore demonstration projects and had many offshore converts.
A different approach to change is via internal education about offshoring. Seminars on
offshoring should be informative, motivating, and help prepare for the change. Such
educational opportunities can be targeted at both business managers and IT professionals.
Of course, one of the greatest obstacles to offshoring is the fear that oneā™s job will
be replaced. Americans call this ārestructuringā and the British call this āredundancies.ā
While some organizations have chosen to lay off many employees at once, others have
chosen a slower route, by reducing onshore headcount through attrition. In order to
reduce its employeesā™ offshore anxiety, IBM announced publicly that it would set up a 25
million USD training fund to retrain employees in the USA and UK whose jobs were
threatened by offshoring.6
Yet another backlash-related issue is whether to be open and public about offshoring.
Managers weigh the trade-offs of keeping offshoring plans secret or communicating
them openly to demonstrate honesty to their employees and their communities.
Case study The ups and downs of building support for offshoring at a
giant US corporation
The case of General Marvel illustrates the prolonged journey of offshoring accep-
tance within large organizations.
General Marvel is one of the 100 largest corporations in the USA. The case
of General Marvel is an actual case, but all identifying details have been
General Marvelā™s IT department has one of the longest offshore histories,
having been involved in offshoring since 1990. Nevertheless, 14 years after
beginning IT offshoring General Marvel is still slowly overcoming resistance.
General Marvelā™s offshore saga began entirely by chance. In 1990 one of its software
product providers, PrexiSoft, had developed its product in India. PrexiSoft convinced
General Marvel to try outsourcing a project to India. āWe assumed that since they
were experts at this, that with their help we too would be successful,ā recalls one man-
ager. The project was a disaster and it had to be brought back in-house and redone.
In 1993 General Marvel was growing quickly but about to hit a wall. Its all
important, corporate-wide product codes were only seven digits wide and the com-
pany was about to run out of possible codes. This became the āOverhaulā project.
General Marvelā™s IT managers began shopping for providers to solve this problem.
They decided to divide the work among two US providers and one Indian provider.
138 Managerial competency
Once the work was under way, General Marvel assessed the results and found that
the Indian provider performed this tedious work at higher quality levels and at lower
cost. The two US providers were phased out. At its peak, Overhaul employed 100
offshore programmers in the project.
In 1994, with the Overhaul project completed successfully, General Marvelā™s IT
managers had the foresight to embark on Y2K remediation. The work was offshored
to India and completed successfully within a year. General Marvel had become one of
the ļ¬rst major companies in the world to successfully complete its Y2K remediation!
Thus, by 1995, General Marvel, in spite of its early stumble, had two offshore
successes. It had internal champions in its IT division who had developed relation-
ships with providers and with provider managers. Some of General Marvelā™s man-
agers had already been to India. The offshore successes led to recognition from top
management: the successful managers on these projects were promoted. āI like the
offshore modelā one manager recalls stating to his colleagues.
The principal offshore provider, RMI, had grown to know General Marvelā™s sys-
tems from the inside. RMI proposed that it begin to take over system management
and maintenance. Now, for the ļ¬rst time, the offshore provider was becoming
entrenched, moving into long-term systems support activities. Up until then,
General Marvel was offshoring projects, such as Y2K remediation, that had an end-
ing date and that no one at General Marvelā™s IT department really wanted to do.
General Marvelā™s IT Groups were composed of internal programming crews and
contractors (non-employees with individual contracts) who had worked on com-
pany systems for years. Each crew was ļ¬ercely loyal to its members and to the sys-
tems they serviced. As RMI began to take ownership of some IT systems, individual
contractors were terminated and the long-standing crews began to get nervous.
Resistance to offshoring had begun.
General Marvel had three major IT Groups corresponding to its main business
functions: Production, Distribution, and Finance. The Production IT Group was
managed by Tommy, an old-timer at the corporation. Tommy became an offshore
proponent looking for opportunities to offshore whenever he could. In 2001 he pro-
moted Tandy Danielson, then a young and ambitious software team leader, to man-
age an offshore project. First she managed a small Time & Material project with the
Indian provider. Then, promoted to Project Manager, Tandy managed a $5 million
Fixed Price project with most personnel in India. Both projects were āmassive suc-
cesses.ā Tandy demonstrated that it was possible to manage critical projects in
which most of the developers were in India. Tandy became a āhero,ā receiving the
Presidentā™s Award for Outstanding Junior Manager. She also became an offshore
proponent, though this was short-lived. She was moved out of the Production IT
Group to the Distribution IT Group, which was largely resistant to offshoring, and
her work on offshore projects stopped.
139 Managing the offshore transition
Nevertheless, RMI and other offshore providers were performing more work on
General Marvelā™s legacy IT systems. But the dramatic cost savings were not materi-
alizing. The IT budget was still growing out of control, and IT headcount was growing.
Some IT managers were not comfortable letting go. They were more comfortable
asking the offshore providers to supply them with onsite personnel. The providers
obliged. Indian personnel were arriving at the local airport with their families, teaming
with General Marvelā™s staff and working on projects. Quite a few of them were settling
down, buying homes in the city. Meanwhile, the companyā™s overall costs, instead of
declining, were increasing. IT managers were not being pushed to increase the ratio
of offshore personnel, so they did what was comfortable and familiar, they kept
them onsite. āI cannot get rid of Singh and Aggarwal,ā said one IT manager, āthey
are critical to my system team.ā And so they stayed and stayed and stayed.
Maryann was one such IT manager. She spent most of her professional career at
General Marvel and was a well-respected IT manager with strong technical abili-
ties. One of Maryannā™s strengths was that she was always very involved in carefully
screening individuals to work on her crew. She had a good track record at complet-
ing projects with her hand-picked software engineers. She applied this ethos to her
relationship with RMI. She carefully screened each of the Indian software engineers
and preferred that as many of them as possible be onsite. āI think that for her the
provider relationship is irrelevantā said one of her colleagues, āshe sees the offshore
provider as a supplier of skilled individuals, instead of trusting that the provider will
get the job done.ā
Speaking about Maryann and other IT managers who were not behind offshoring,
one of the offshore advocates said, āYou hear lots of excuses from them about off-
shore failures and the difļ¬culties involved, but it takes hard work and then it succeeds.
You write good requirements, freeze them, and then overlay good project manage-
ment. It is not easy, but it can be done. Itā™s a learning curve.ā
He added, āIt is true that the Production IT Group has always been the leader in