SEO Marketing Research

SEO Marketing Research header image 2

Unsuccessful offshore outsourcing

34 Comments · Business outsourcing

This article concludes by examining an offshore outsourcing initiative that did not work as planned.

The leader at the initiative was discouraged by the outcome of the particular project, but he is not discouraged by the prospect of using an offshore strategy in the future.

Quite the contrary, he believes that the lessons learned as a result at the failed project provide greater prospects ton success for the next project.

Not all business process outsourcing (BPO) projects work is planned, but the promise that BPO holds for most companies makes the hard knocks at failures and lessons learned worth tolerating.

Wesley Bertch and his team learned a few lessons about offshore outsourcing through the hard knocks academy.

Bertch leads the software development group at Life Time Fitness, a high-growth, national health and fitness chain.

Life Time offers its customers health clubs; spas and salons; member services, such as personal training and swimming lessons; a nationally distributed magazine; and energy bars, powders, and other consumer goods.

Life Time also has a corporate wellness unit that sells products and services to thousands at companies.

In addition to supplying these various divisions with information technology systems, Life Time provides services to its internal real-estate group. Keeping pace with the growing software needs of so many diverse business units is a huge challenge.

Bertch’s internal staff at 15 programmers was able to produce only about one-third of the output he needed.

With a limited budget and demand for greater output, he reasoned that offshore software development was the ideal solution. Bertch needed to augment his internal team in a cost-effective way, without sacrificing quality.

From an organizational perspective, Life Time met the key criteria for offshoring: centralized IT, process maturity, and years of experience working with Indian companies and technical workers, both in the United States and offshore.

Life Time had executive sponsorship and commitment. It even had the perfect project to test the outsourcing waters: a small, low-risk Web application for its real-estate division.

The application’s purpose was to pro-vide screens for entering new location information.
The vendor Life Time invited to implement the project was an Indian firm that had been successfully supporting the company’s sales-farce automation implementation.

With this prior history of working together, both sides thought the Web application project would he relatively easy. The vendor agreed to take on the project for a fixed fee of $20,000, with a nine-week timeline.

Both panties agreed that the vendor should perform all phases of the project, from gathering business requirements through quality assurance.

Life Time’s internal staff was to monitor and participate as necessary. If the project proved successful, Life Time promised the offshore vendor that there would be much more project work in the future.

The project got off to a good start. The vendor’s business analyst met frequently with the real-estate division’s users and, with the on-site liaison, worked to document all of the functional and user interface requirements within four weeks.

By week three, however, Life Time’s software manager noticed problems in the software. His review of the functional specifications revealed problems in the requirements, particularly in the interface specifications.

For instance, the user interface as laid out forced the users to reenter data they had previously entered, and the screen flow was confusing.

The on-site liaison countered that although the interface had problems, it complied with the documented business requirements.

To ensure that Life Time would get what it needed, Bertch extended the project timeline, agreed to a cost increase of $7,000 to allow ton additional analysis and better interface design, and dedicated internal Life Time analysis and user interface experts to guide the final version at the documentation.

After the vendor’s business analyst finalized the documentation, he returned to India and, in an effort to exploit his knowledge of the project requirements, was reassigned as the offshore project manager.

By this point, the offshore technical manager had lined up the offshore project team, so the coding design began in earnest.

Once offshore, however, the project started to unravel. Upon receiving the offshore vendor’s database design, Life Time’s lead data architects declared it to be the worst he had ever seen.

There were so many critical database Haws-more than 100-that Life Time’s architects were unable to log them all within the scheduled one-week review period.

The database was not the only problem. Determined to impress Life Time with their programming prowess, the offshore developers insisted on completing the entire code design before allowing Life Time to review it.

Confident in their original code design, the offshore team had launched immediately into writing Java code before Life Time’s review.

Unfortunately, the eventual review determined that the offshore team’s design patterns were not in accordance with the standards Life Time follows, invalidating all of the offshore team’s Java code.

In two weeks, the offshore team had gone from proud and eager to embarrassed and dejected. Once the reality at the logged defects sank in, the team knew there was no way it could straighten out the code design and then code and test the applications within the set time frame.

Frustration levels were high on the offshore team, and the on-site liaison became increasingly defensive.

The internal Life Time team was disappointed and annoyed as well, but accepted the fact that mistakes were bound to happen on the first end-to-end offshore project. The life Time team valued a quality final product much more than timeline precision.

Nevertheless, as Life Time learned later, the offshore team began working extra-long hours to avoid asking for a time extension.

Given all the problems up to that point, Bertch sensed the project was at risk, so he flew to India to meet with the offshore team. The visit was informational and warm feelings prevailed, hut by this time the application was in the testing phase and nearly complete.

Not long after Bertch’s trip to India, the offshore team delivered the tested and “finished” application. According to the on-site liaison, all Life Time needed to do was perform a user-acceptance review and sign off on the project’s successful delivery.

Instead, Bertch decided to perform some quality assurance with his internal team. In less than a day, one Life Time tester and one developer found more than 35 defects, many at them fatal.

The offshore team categorized the hundreds of newly found detects as “in scope” (these they fixed) or “out of scope” (these were deemed Life Time’s problem).

Even after the vendor fixed the “in scope” defects, the application was unusable. And fixing it meant it would be late and even more over budget.

At this point, Bertch decided the best course was to take delivery of the application and overhaul the code internally. Reflecting on his offshoring experience, Bertch said:

You might assume that, given our dismal experience with offshore development, we have written off this model completely. Not so. Offshore may still hold promise as a way to cost-effectively extend our current team. What would we do differently?

Instead of relying on the vendor to institute the offshore processes and team, we would set that tip ourselves.

Ideally, we would have a developer from our internal team relocate to India to build and manage a competent offshore team, perhaps within leased space at an existing development facility.

This ease is a good example of the challenges associated with working with an offshore development team.

Offshore vendors are often overconfident of their own abilities and eager to take on new projects, the scope of which may lie beyond their current level at expertise.

The overconfidence at the vendor also leads to a desire to impress the buyer with rapid turnaround and seemingly impossible schedules and deadlines.

To avoid that problem, companies working with offshore vendors must control the pace at the project and must ensure that specifications are carefully developed and understood before allowing the work to begin.

Then, it is advisable to work on projects in stages, reviewing the work produced by the offshore team in discrete stages. Controlling the pace at wonk and reviewing the finished product as it is delivered will enable the buyer to stay in control and avoid additional costs and time.


34 Comments so far ↓

Leave a Comment