Case Example: Life Time Fitness

Defining the project scope sets the stage for developing a project plan. Project scope is a definition of the end result or mission of your project—a product or service for your client/customer. The primary purpose is to define as clearly as possible the deliverable(s) for the end user and to focus project plans. As fundamental and essential as scope definition appears, it is frequently overlooked by project leaders of well-managed, large corporations (Gray-Larson, 2006, p. 100).

In 2003, Life Time Fitness’s IT department decided to use offshore development to write software for the company’s internal real-estate department. The senior management staff met and looked at all the reasons why offshore development would work for the company. They decided that offshore development would work for the following reasons:

1. They possessed a centralized IT department

2. Have acquired years of experience working with Indians both in the United States and Offshore

3. Life Time Fitness had executive sponsorship and an IT commitment (Bertch,2003)        

The process began well. Life Time Fitness selected a well-respected Indian vendor to write their new software. A team comprised from both Life Time Fitness’ and the Indian Vendor was formed and the project went underway. The team worked diligently for the first few weeks to document user review and the progress it was making. By the end of the first few weeks, though, an internal analyst for Life Time Fitness noted some concerns. He stated there were sections of the program that were confusing and distorted. Information was not being clearly organized, and there were lines of coding that had been entered in twice.

Life Time Fitness supplied additional funding and extended the project time line to accommodate the set backs. The analyst returned to the job site to share their findings with the team writing the code. Work on the project resumed. After a couple more weeks, the Life Time Fitness IT department chairs requested an early design sample to review what form the project was taking. Life Time again sent an analyst and their lead data architect to the job site to review the progress. Upon review, “the architect declared it was the worst he’d ever seen. There were so many critical database flaws—more than100—that the team of architect was unable to log all of the defects within the scheduled one week review” (Bertch, 2003). In order to attempt to salvage the project, the Quality Assurance manager and the IT department chair flew to India personally to meet with the offshore team members. The meetings were highly informational and many of the issues the offshore team was having were reconciled. The project was able to be put back on track. The Indian vendor and the Life Time Fitness IT department finally putout a new software program that met all Life Time Fitness’ needs—despite being weeks past the time line and thousands of dollars over budget.

Wesley Bertch, the Director of Software Systems for Life Time Fitness, has expressed elements of organizational communication that would be approached differently. Despite Life Time Fitness’ analysts and data architects acting as a communication vessel, information was still not effectively communicated back to the board of individuals in charge of the overseas endeavor. “Our offshore vendor uses a comprehensive project-tracking system, and its employees are reviewed and rewarded based on customer-satisfaction surveys. You would assume, therefore, that this project's problems and our dissatisfaction were evident to the vendor's management, right? Wrong. During our visit to the vendor's development center, the offshore project manager showed us data on our project. I was astonished to find that the data indicated things were perfectly on target, and the number of hours worked during each phase was precisely in line with the vendor's original estimate. The coding snafus and overtime hours weren't evident, nor did we detect any inkling that the project was at risk” (Bertch, 2003).  This scenario validates the importance of communication when pursuing offshore ventures. It also validates the fact that outsourcing does not always work out as intended.

References:

Bertch , W. (2003, October 16). How Offshore Outsourcing Failed Us. Retrieved November 10, 2008, from Network Computing Web site:http://www.networkcomputing.com/showArticle.jhtml?articleID=15201900

Gray, C., & Larson, E. (2006). Project Management: The managerial process. New York: The McGraw-Hill Companies.