Transcript Outsourcing Lessons From India

Outsourcing Lessons From
India
Outsourcing specialist Hugh Walcott has learned his
lessons the hard way - so you won't have to.
These lessons come from helping an Australian
company manage a large offshore project with a
business partner in India.
On the surface the decision seemed entirely sound
– the Indian partner boasted strong expertise in the
desired project area
– claimed to have more than 16,000 engineers
based in Bangalore, India
– operating at CMM Level 5.
But…
However, down at the project level things quickly
started to go wrong.
The project simply did not go well, Walcott says so much so that even today it still struggles in
the face of that troubled history.
Key deliveries failed to be met.
The veneer of commitment and ownership
promoted by the outsourcer started to crumble.
Problems were magnified by
– distance
– cultural difficulties
– accusations
– lies started to flow.
It was even worse than that…
During the project, Indian team members
seemed so relentlessly incapable of meeting
deliverables that the company felt it had to
arrange short-term visas for a portion of the
Indian team to come to Australia in the hope
of achieving some oversight and improved
accountability. But if the camel's back was
shuddering from the discovery that many of
those so-called 16,000 engineers sported
bogus CVs and lacked the necessary
technical knowledge, the final back-breaking
straw turned out to be the revelation that the
much-vaunted CMM Level 5 rating was only
applicable on site.
Lesson One:
Offshoring Taxonomy 101
"Understanding how to structure an
offshore project first involves
understanding the associated risks and to
structure the outsource agreement to
manage these risks. For example, if the
biggest risk to an organization is loss of IP,
then an outsourcing agreement that
ensures no complete solution is ever
assembled offshore may be necessary."
Taxonomy Categories:
Top level or solution level agreements
System level agreements
Sub-system level agreements.
Unfortunate Surprise
On the project in question, the organization thought it
was going for a system level agreement, but as
problems started to occur it found itself with a subsystem level agreement almost by default. Inevitably,
Walcott says, the vast physical distances between
team members caused problems, not least in the
challenges associated with expectation management.
"We never had the contingencies built into our
agreement from the beginning. We were stuck: Our
project deliverables were dependent on theirs and in
order for the whole solution to succeed we had to help
them out. Merging the two teams and consolidating
the control of ownership of the project seemed to be
the only way to get out of our nightmare."
Lesson Two: Cultural
Differences Are Important
When the deadlines first started to slip, the
Indian team began lying about the
progress being made, continually insisting
all the work was on track. Walcott believes
the problem was compounded as much by
cultural differences as by the vast
distances between the two teams at that
point, with those lies inextricably tied up
with the concept of "not losing face".
Herculean Effort: Now in Order
It was in an attempt to overcome these problems
[of saving face] that a portion of the Indian team
were eventually given three-month working visas
to come to work on the project in Australia. "That
turned out to be a monster headache," Walcott
says, "but we got the visas and put them up in a
hotel in Sydney. With the visas sorted,
everything seemed perfect. [We thought:] the
Indians should be here for the expected length
of the project. But integrating the two teams
turned out not to be as easy as first thought."
But, … More Cultural Issues:
Different attitudes towards time
Different work ethics
Different attitudes toward quality
Different attitudes toward cooperation: The
Indian team chose to work in isolation and
not accept help when it was offered.
And “Status”: Maintaining the
“Power Distance”
Walcott says companies must ensure that
everyone understands the project reporting
structure before engaging in an outsourced
project. This needs to apply from the top all the
way down the project hierarchy, including
developers and tester. India, in common with
many Asian societies where offshoring is
prevalent, places greater emphasis on so-called
"power distances" or status: the distance
between members of an organization.
Bugs?!? Oh, NO!!!
The next challenge involved resolving the
technical difficulties. This is usually
managed through some form of change
management system, used to report bugs
or enhancements, getting it fixed and
ensuring that it works.
Lesson Three: Choosing the
Right Development Methodology
Countries like India place a much greater
emphasis on teams over the individual. In India,
as in much of Asia, it is the team that gets
thrown a problem, not an individual. In Australia
it is more likely that a trusted individual will be
given carriage of a problem.
"Choosing a development methodology that can
adapt to offshore and local working habits while
also complying to your outsourcing agreement
commitments is an important step."
This “Group” Challenge Begets:
FDD: Walcott says Feature Driven Development
(FDD) - a short-iteration process framework for
software development projects - is a crucial tool
in overcoming difficulties of culture and distance
because it allows the project manager to break
projects down into features, be they
presentational or back-end, with each feature
representing about two weeks' work.
FDD
FDD starts with the creation of a domain object model in
collaboration with Domain Experts.
Using information from the modeling activity and from any
other requirements activities that have taken place, the
developers go on to create a features list.
Then a rough plan is drawn up and responsibilities are
assigned.
Now you are ready to take small groups of features
through a design and build iteration that lasts no longer
than two weeks for each group and is often much shorter sometimes only a matter of hours - repeating this process
until there are no more features.
FDD: The Perfect Match for a
Multinational (Offshoring)
Walcott describesProject
himself as a "huge believer" in
FDD, which is typically used in conjunction with
agile development methodologies. "FDD was a
perfect match for our multinational project," he
says. "By assigning feature sets according to a
project reporting structure, a project is able to
maintain the correct cultural 'power distances'
while maintaining individuals' accountability
within the team.
Lesson Four: Audit Your
Progress . . . Carefully
"Outsourcing your project offshore is like
a box of chocolates, you never know what
you are going to get," says Walcott. "We'd
seen the resumes of the staff we were
working with, but when they eventually
arrived on site they turned out to be
completely different."
So, whose anxious to play in this
sandbox?
Audits Keep Honesty in the
Game
Walcott says audits can be an invaluable tool in
helping an organization expose and overcome
such difficulties, although care is needed to
maintain the business relationship. Audits can
also be used to assess other aspects of the
project, including both technical and cultural
aspects. "Running an audit allowed us to expose
shortcomings in both the resources we had
assigned and how we were managing our
project, allowing us the opportunity to rectify the
problems before it was too late," he says.
This isn’t easy, either
"With reverse engineering tools we were
able to ascertain exactly what caused some
of the problems we had experienced and
what best practices we thought were
missing.
So we did what we hadn't done at early
stages, which is to say: 'We will not accept
anything from you if it doesn't comply with
best practices.'
This is something we should have done at the
outset, and in future I would make that a part
of best practice agreements."
Picking and Auditor
In order to best protect the business relationship, an
independent auditor should be agreed upon early and
service level contingencies put in place as part of the
initial outsourcing agreement, Walcott says. Depending
on the type of agreement, organizations should look at
including a clause demanding an independent audit of all
work should deliveries fail to be met. Sub-system or
collaborative outsourced projects required most
attention, as it is the long-term objective of an
organization to own, support and hence maintain the
solution in-house.
Does this sound like it’s going to be less expensive?
And the final result?
"After the end of the three months, when the
Indians were about to leave, we still had a
service level agreement with them but we did not
feel confident from the experience that we had in
even sending anything back to be fixed. The
audit had helped expose just what a mess it
actually was so a small team of us created a
new project called the Refactor Project to
rewrite almost everything they had done.
This could get complicated
Managing the flow of work between
enterprise and outsourcer is another area
where audits are a useful tool. Areas such as
change management, document control and
build migration are all cross-cultural sensitive
areas and are often overlooked by business
audits. A technical audit can optimize these
processes while
– maintaining the correct reporting structure,
– power distances and
– self-honor (“face”).
Walcott’s Conclusion
With offshoring likely to be around for some
considerable time, due partly to the skills
shortage, more and more organizations are
going to engage in offshore agreements.
Walcott's experience leaves him confident that
companies that have been forewarned to likely
difficulties, and who adopt a rigorous approach
to audits, should be able to do so with greater
confidence in future.
What is your conclusion?
Cautions to consider (and plan and
budget for) before
outsourcing:
Demoralizes
local work
Value of time
Cooperation/team wk issues
Work ethic issues
Quality of work issues
Face-saving cultural issues
Power distant issues
complicating communication
Time-zone issues
Less flexibility due to
contracted specifications
Risks our I.P.
No courts to control contract
violations
Most companies don’t see
savings for 3 years
force
Language barriers
Loss of control (not
transparent, not directable)
Increased testing burden
Increased P.M. at detailed
levels
Better specs required (more
time consuming)
Trust issues (honesty
issues)
Difficult to assess true
quality of offshore source
due to bait-&-switch
Added expenses of third
party audits