By Topic

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

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$31 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

2 Author(s)
Kim Man Lui ; Dept. of Comput., Hong Kong Polytech. Univ., Hong Kong ; Chan, K.C.C.

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.

Published in:

Engineering Management, IEEE Transactions on  (Volume:55 ,  Issue: 1 )