Things 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 (kaccox@att.net) 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 are few."