to consider before outsourcing a project offshore
Opinion by Katherine Cox
MAY 14, 2003 ( COMPUTERWORLD ) - If your company is considering outsourcing
IT development or maintenance of its software applications, there are
a few things you should consider before you do. Otherwise, you may wake
up to a nightmare.
A previous employer sent me to Hyderabad, India, to audit an offshore
software development project that it had undertaken for a client. My trip
proved to be a forecast of the outcome of the project. Flights were canceled,
connections were missed, and I arrived 15 hours later than scheduled.
I had planned this trip. I had done a lot of analysis. I had even communicated
the plan. But it was still a mess. I represented a company that was certified
at Capability Maturity Model (CMM) Level 4 and was practicing total quality
management (TQM) ad nauseum, and it still had as much trouble with the
project as I had in getting to Hyderabad. What happened?
My 86-year-old father, who is computer-literate, had trouble understanding
the potential problems caused by outsourcing until I arrived at an analogy.
I asked him where most of his clothes were made. He said most weren't
made in America, and the quality varied quite a bit. Some of them are
poor quality material. Some of them show poor workmanship, which means
patching or replacing a button. They cost less initially, but they have
to be replaced more frequently. Well, Dad, I said, consider what the effect
of that poor quality, poor workmanship and frequent replacement would
be on business applications, financial institutions and just about any
kind of business?
What may be the root cause of the poor product? There could be one or
many contributing factors. Any one has the potential to close the doors
of your business. Here is a list I have drawn up from personal experience.
How will you select a company? What factors will contribute
to the company you select for outsourcing? What selection criteria have
you established? Industry knowledge is critical, but some CEOs and CIOs
may be more impressed with CMM, ISO9000, SAS70 or TQM certifications.
Ask the tough questions. Find out what they really know about your industry.
What's the degree of cultural diversity? If you are truly
going offshore, varying degrees of cultural diversity most likely do exist
between the two countries. Those differences may appear to be minimal
in initial conversations. Watch out!
Is your business analysis thorough enough? Make no assumptions!
Did your business analysts specify that each and every one of those sexy
data entry screens require an Exit button? An industry standard in the
U.S. may not exist in the company and country have selected. Adding requirements
that you assumed were obvious will cause cost overruns and missed commitment
dates. Surprised? Maintain your business-analysis functions in-house.
Value your own employees' company and product knowledge. Who really knows
more about your business?
Are the roles and responsibilities communicated? Who
is doing what and when? This seems fairly straightforward to those of
us here. If each team member's roles and responsibilities aren't communicated,
agreed upon and documented, assumptions are made. Programmers are programming
what? Business analysts are analyzing what? Is the entire on-site/offshore
team involved in design reviews, quality reviews and inspections? This
involvement is critical, but the implementation of these activities adds
to the bottom line.
How big of a footprint do you want offshore? I was fortunate
to be allowed the luxury to travel business class for the 35 hours my
flight took to India. (A normal flight averages 20 hours.) Upon my arrival,
I stayed at a five-star hotel. I had at my disposal my own driver and
car available 24 hours a day. At the time, the cost for my 10-day trip
was roughly $18,000. I don't think this included the cost of expediting
my visa or other miscellaneous costs. Most companies have eliminated the
"comfort" travel options. If you have opted for offshore development,
ask yourself what role and responsibility you want your own people to
have. There could be some costs of doing this kind of business that you
did not anticipate. We "parked" two business analysts and two
developers at the offshore location for six months and paid all expenses.
Because of undefined roles and responsibilities, it's still uncertain
what the contributions were. One employee contracted malaria. Another
developed a severe paranoia disorder from the antimalarial medication.
Are the architectural platforms, operating systems, tools and
configuration management in sync? "Oh yes, we are all using
the same operating platforms and development tools on-site and offshore."
Exactly the same tools? Exactly the same versions? Configured exactly
the same way? You may be unpleasantly surprised at the discrepancies that
will result in your software application performance and results and the
dollars it will cost to debug if there is anything out of sync between
onshore and off-site operating platforms and software tools.
Is there a communication plan? The average time-zone
difference between the U.S. and most countries in Asia that do software
development is 13 hours. If you are communicating between India and Colorado,
the time difference is 13.5 hours. Both companies will have to commit
to doing business and be available at some odd hours during the life of
the project. How often do you communicate? What's the agenda? Is it published
throughout the project life cycle? Do you have videoconferencing capability?
Is this plan documented, again with roles and responsibilities, and communicated?
So how does it all work in the real world? I'd like to leave you with
a case study to show how a simple thing like the definition of a term
can affect the quality of a project.
A project to develop asset management/property management software was
sent offshore to cut down on costs. However, various types of rental properties
were never documented or defined when the project was shipped overseas.
There was an underlying assumption that the terms hotel, apartment and
condominium were universally understood as being unique in terms of service
and housekeeping rules.
In India, the terms apartment and condominium do not exist. These were
referred to as "flats." But there were more problems than just
confusion about terms. Issues arose about expectations as well. For instance,
in the U.S. people expect daily housekeeping services in a hotel room,
minimal housekeeping in a time-share condo rented for a week and none
in an apartment rented for six months or longer. These nuances, together
with the confusion about the terms, led to a software package being returned
to the U.S. that would have required property managers to provide clean
linens and full housekeeping every day for hotels, condos and apartments
regardless of the length of the rental agreement.
But this serves as an example of how nuances in meaning and experience
can lead to problems with a project. It also points out the need for strict
quality testing and detailed communication. Both of which can increase
the cost of the project.
I have just captured a few of the issues that may contribute to dangerous
business practices. But, again, any one single scenario and its ensuing
repercussions may and probably will make you question the benefit.
Katherine Cox (firstname.lastname@example.org) has had opportunities to travel, witness
and audit attempts at outsourcing software development. In her travels,
she has developed an inherent respect for those who practice and participate
in offshore development successfully. To date, she says, "those successes