Rescuing Troubled Software Projects by Team Transformation: A Case Study With an ERP Project

Many software projects fail, whether failure is measured in terms of budget, schedule, or some other requirement. The causes of such failures are many, but are not always easily recognized. This is not the least due to the human dimension of corporate activities, as spurious or misdiagnosed issues i...

Full description

Saved in:
Bibliographic Details
Published in:IEEE Transactions on Engineering Management 2008-02, Vol.55 (1), p.171-184
Main Authors: Kim Man Lui, Chan, K.C.C.
Format: Article
Language:English
Subjects:
Budgeting
Business
Companies
Computer programs
Enterprise resource planning
Failure
Fast moving consumer goods
Information systems
Information technology
IT project failures
Management
Project management
Risk management
Schedules
Software
software project management
Studies
team management
Transformations
Citations: Items that this one cites
Items that cite this one
Online Access:Get full text
Tags: Add Tag
No Tags, Be the first to tag this record!
Description
Summary:Many software projects fail, whether failure is measured in terms of budget, schedule, or some other requirement. The causes of such failures are many, but are not always easily recognized. This is not the least due to the human dimension of corporate activities, as spurious or misdiagnosed issues in Enterprise Resource Planning (ERP) projects can take on a life of their own and become a magnet for company politics. This paper reports an industrial case in which the senior management attempted to deal with a troubled ERP implementation (SAP R/3) in an international fast moving consumer goods (FMCG) company during 2001 and 2002. This paper reflects this dimension as it uses original emails and PowerPoint slides to recount a number of representative episodes in a troubled but ultimately successful project. At the heart of this success is the realization that whereas it can be difficult and time-consuming to do root-cause analyses, it is relatively simple to identify problem owners. In this case, the senior management without IT backgrounds turned around a failing project by reorganizing the team structure according to process areas so that issues in each process area had one problem owner. We summarize the management's actions into a troubleshooting framework, and in addition, suggest three actions for rescuing troubled projects: keep the project manager but narrow down the manager's scope of responsibility to one or two process areas; assign the right people to be responsible for other process areas; and have the General Manager chair the ERP meetings.
ISSN:0018-9391
1558-0040
DOI:10.1109/TEM.2007.912933