See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/3077076

Rescuing Troubled Software Projects by Team Transformation: A Case Study

With an ERP Project

Article  in  IEEE Transactions on Engineering Management · March 2008

DOI: 10.1109/TEM.2007.912933 · Source: IEEE Xplore

CITATIONS READS
46 4,377

2 authors, including:

Keith C.C. Chan

The Hong Kong Polytechnic University
329 PUBLICATIONS   5,923 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Evolutionary Algorithm for Graphs View project

Multivariate Time Series Analysis View project

All content following this page was uploaded by Keith C.C. Chan on 15 January 2015.

The user has requested enhancement of the downloaded file.

IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 55, NO. 1, FEBRUARY 2008
Rescuing Troubled Software Projects by Team
Transformation: A Case Study With an ERP Project
Kim Man Lui and Keith C. C. Chan
Abstract—Many software projects fail, whether failure is mea-
sured 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 Enter-
prise 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 interna-
tional 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 representa-
tive episodes in a troubled but ultimately successful project. At the
heart of this success is the realization that whereas it can be diffi-
cult and time-consuming to do root-cause analyses, it is relatively
simple to identify problem owners. In this case, the senior manage-
ment 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.
Index Terms—IT project failures, risk management, software
project management, team management.
I. INTRODUCTION
ANY top executives with previously successful leader-
M ship roles in various sizable operations such as merger
and acquisition projects are baffled by an Enterprise Resource
Planning (ERP) project. So often, the implementation problems
not only involve unfamiliar technical implications but also in-
volve organizational changes and internal conflicts. When an
ERP project is slipping behind schedule and team members are
putting a lot of effort into rework, its budget is likely to overrun.
There are a number of approaches that managers may typically
use to respond to these issues, such as traffic light reporting,
in which a project status is reported as “Green,” “Yellow,” or
“Red” according to whether the project has met three basic
project objectives: within budget, on schedule, and achieving
functions/performance as planned [1]. A project gets a red light
Manuscript received March 1, 2006; revised September 1, 2006. Review of
this manuscript was arranged by Department Editor R.T. Keller.
The authors are with the Department of Computing, The Hong
Kong Polytechnic University, Hunghom, Hong Kong (e-mail: cskmlui
@comp.polyu.edu.hk; cskcchan@comp.polyu.edu.hk).
Color versions of one or more of the figures in this paper are available online
at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/TEM.2007.912933
0018-9391/$25.00 © 2008 IEEE
171
if to date it has met just one objective—but does not necessarily
mean it will be abandoned. It could still be partially implemented
in terms of the functions that the system is expected to achieve.
If a software project is both overbudget and overschedule, we
do not generally consider it successful. A Conference Board
Survey [2] reported that 117 companies that attempted ERP im-
plementation found that, on average, the ERP implementation
costs went 25% overbudget. Postmortem reviews, risk manage-
ment, and critical success factors give us guidance on control
actions and preventive actions so that we may stay out of trou-
ble. However, once projects run into trouble, these remedies
and analyses are of little help because corrective actions differ
from others in a way that we are responding to consequences
of the past events and their influences. This paper considers a
recent, (2001–2002) real-life case in which an international beer
company attempted to implement SAP R/3. The project ran out
of control. It was behind the original schedule and the overall
progress was slow, pausing (e.g., not timely feedback), and even
moving backward (e.g., rework). The top management had to
take timely action before the project went overbudget.
With headquarters in Europe and selling in more than a 100
countries, KuDrink (not its real name), is a market-leading inter-
national beverage brand. KuDrink Hong Kong Ltd. developed
its core information system on an IBM A/S400 in the early
nineties to automate its core business processes such as sales,
distribution, and billing. It was a batch-based application in
which the database was updated at night. This meant that the
last overnight processing provided the latest source of infor-
mation. At that time, competitive pressures were not so fierce,
with fewer competitors or outlets, so this application satisfied
KuDrink’s requirements. In the year 2000, KuDrink’s IT strat-
egy for both Hong Kong and China was reevaluated and the
decision was made to implement SAP R/3 in Hong Kong by
2002.
Like many ERP projects, the KuDrink project did not go
exactly as planned. Internally, there were conflicts among the
KuDrink departments; externally, there were disagreements be-
tween the KuDrink users and the supporting vendor. The project
plan was revised four times. Worse yet, the project manager put
it to the vote whether to “go live.” There were problems, but
it was difficult to identify their root causes and dissatisfaction
was evident even at the level of the Board of Directors. This pa-
per reports on the troubled KuDrink ERP project of 2001–2002
and discusses how the top management saved the IT project,
achieving its expected goal within budget.
This paper is organized as follows. Section II reviews the lit-
erature on ERP implementation failures, team composition, and
issues of learning from IT experience. Section III addresses our
172 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 55, NO. 1, FEBRUARY 2008

TABLE I
SURVEY OF FACTORS CRITICAL TO ERP FAILURES

problem statement for rescuing IS projects. Section IVprovides
the background to the KuDrink project and discusses a SAP
implementation model. Section V offers a number of anecdotes
that illustrate the problems of the project. Section VI describes
the solution implemented by the KuDrink management. The res-
olution was an exemplar of the art and science of management,
illustrating the crucial point that it is not as important that the
top management know about IT project problems as it is that
they know about the owners of the problems. The final section
offers our conclusion.
II. LITERATURE REVIEW
Although there are a number of postmortem studies on aban-
doned IT projects [3]–[5], with the focus on key lessons learned
from the successful IT projects [6]–[8], classifications of trou-
bled IT projects [9], [10], and risk assessment, usually con-
ducted at the beginning of the projects, to avoid IT project
failures [11]–[14], little attention has been given to the not so
uncommon problem of dealing with a troubled IT project, turn-
ing the project around, and completing it. Often, troubled or
failing IT projects do not start with good risk management. In
this case, data collected from the projects can be incomplete
and inaccurate. Snow and Keil report that the riskier the project
is, the more inaccurate the status reports are. Reassessing risk
factors is, therefore, difficult. As a matter of fact, rescuing an
ERP project demands more than risk management; it involves
the psychology behind social behavior.
This section will review three diverse subject areas as the
background of the work. First, we look at difficulties that may
cause ERP project failures. Second, we briefly consider team
composition from a social perspective. Third, we consider how
we might go about learning from failing projects, perhaps the
most challenging aspect of handling a troubled IT project.
A. ERP Project Failure
The literature on the key factors required for success and
failure of an ERP implementation is diverse. Jiang and Klein
report that IS project risk is a multifaceted issue with different
interacting parts. Table I provides a checklist of ERP issues as
reported in the literature as they relate to critical success factors
(CSF). Note, however, that for purposes of comparison (see Ta-
ble I), we list the opposite of the CSF for ERP implementation
in and SAP implementation in, with the understanding that no
literature has reported that the opposite of CSFs would neces-
sarily or sufficiently be the factors critical to project failures.
We also include a list from in which Zhang et al. have consoli-
dated a number of ERP factors in [15]–[21]. Table I also shows
factors from five real ERP failure cases in China reported by
LUI AND CHAN: RESCUING TROUBLED SOFTWARE PROJECTS BY TEAM TRANSFORMATION: A CASE STUDY WITH AN ERP PROJECT
Xue et al. [22]. For comparison, we also include problems
discovered from empirical studies on software development
failures [3] and from gap analysis between organizational needs
and ERP functionality [23].
Strong management support is sufficient to successfully
implement ERP; however, when dealing with troubled IT
projects, the top management plays a dominant role in rescuing
such projects. Management involvement is, thus, a necessary
condition.
B. Team Composition
Past research has suggested that heterogeneity in the ages
of team members is associated with higher individual turnover
rates [24] while demographic diversity enhances creativity [25].
Drawing an analogy between demographic diversity and po-
sitional (or functional) diversity in an organization, it can be
quickly noticed that the ERP team composition influences team
performance. Any ERP project must start with the establishment
of a project team in which the members are selected from dif-
ferent positions in major functional units of the company. Such
heterogeneity in a team will, on the one hand, contribute to a
staff member’s functional expertise in reengineering a business
process and designing an integrated system, and, on the other
hand, will cause conflicts of interest among different functional
departments, which, to some extent, may lead to schedule slip-
ping, failure to keep to the budget, and low morale among team
members [26]. It has been confirmed during a CRM devel-
opment cycle (e.g., inception, process design, implementation
and go-live) that team morale is lowest at the implementation
stage [27].
Regarding team composition and team effectiveness, a survey
of the ERP implementation was conducted in mid-February
2003 in Taiwan. A total of 102 questionnaires were returned,
of which 88 were analyzed and the following conclusions were
drawn.
1) Empirical finding 2.2.1: Functional diversity is negatively
associated with team performance [25].
Team members from different functional areas (e.g., sales
and marketing, finance, distribution, information systems, etc.)
may bring different viewpoints to a team and this may not be
desirable. This finding is consistent with a previous study [28],
[29] in which functional diversity was the main source of task
conflicts.
2) Suggestion 2.2.2: The study recommends that the ERP
package training should be taken into consideration as
soon as an ERP team is established [25].
The project’s effectiveness can be increased and task conflicts
reduced if staff understand the functions of an ERP package
early in the life of a project.
3) Empirical finding 2.2.3: Positional diversity has a positive
influence on team performance [25].
Heterogeneity in terms of job position and positional diversity
may lead to lower levels of conflict within a team and greater
effectiveness.
4) Suggestion: Involve staff from a broader range of organi-
zational levels. Those who are in higher ranks in the company
173
hierarchy can contribute their experience and exercise more po-
sitional power to resolve task conflicts, whereas the end users
can contribute their hands-on experiences.
C. Issues in Learning From Experience
The central difficulty in learning from our experience of a
software projects comes with the fact that, due to the dynamic
and multifactor nature of many software project problems, the
immediate or even timely identification of the root causes of
problems may be impossible. For example, changing require-
ments during implementation may lead to the ultimate aban-
donment of a software project and this may arise from many
causes, such as misunderstanding system limitations owing to
ineffective user training; a lack of user involvement at the user
requirement stage; or/and lengthy implementation requiring a
review of potentially out-of-date business requirements. Given
that the immediate identification of root causes is not always
possible, it would be wise for problem solvers to take the
Hippocratic approach and to first ensure they do no harm by
offering premature solutions.
We interpret facts, reports, events, and perceptions purpose-
fully. Forer [30] found that people with the belief that their
temperaments are considered to be governed by the relative po-
sitions of stars tend to accept general personality descriptions as
uniquely applicable to themselves and ignore the fact that such
descriptions might be applied to everyone. Even though we may
try to avoid intentional belief, what we perceive greatly depends
on what we learn and expect [31].
From an engineering management point of view, it would
be interesting for project managers to know whether the diffi-
culty of learning from both software projects and engineering
projects (e.g., building a tunnel) is the same. Engineers must
solve technical problems using models, which, in the field, may
be necessary to further simplify. Experienced engineers can ap-
ply their experience from one project elsewhere on another.
In contrast, software engineering involves technical problems,
which are based on artificial rules and which can have many so-
lutions. It is by no means clear whether a particular problem is
typical or representative or that we will see that kind of problem
again.
Jørgensen and Sjoberg believe that much IT learning is incor-
rect. Postmortem reviews may include much incomplete and/or
incorrect information, and invalid conclusions about causal re-
lationships may be drawn. However, they suggest how learning
mistakes can be avoided by using statistical techniques to sup-
port our learned experience, by considering alternative perspec-
tives of the same event, and by understanding the biases and
limitations of our learning about a particular event.
Brehmer [32] reports that there is a very low correlation be-
tween length of IT experience and the quality of professional
judgments. Five factors may contribute to this: 1) we do not
always understand our own decision-making process [33]. For
example, French or German music was played on alternate days
from an in-store display featuring French and German wines.
The results were that German wines outsold French ones when
German music played on that day and vice versa. However, only
174 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 55, NO. 1, FEBRUARY 2008
one out of 44 wine customers could mention the music [34];
2) learning correctly from experience is difficult; 3) we may not
be aware of a fact that we learn nothing from project issues that
have no clear root-cause relationships and what we actually do is
formulate hypotheses or establish beliefs that can explain those
issues, justifying to ourselves our false beliefs. These beliefs
become valuable to us once they can serve as explanations of
our observations of the project events [35]; 4) project events are
fragmented in nature but they are often recalled and reorganized
by us in order to make sense of a whole picture from the flow of
events, thereby distorting our understanding; 5) what we have
learned from one project is so unique that the knowledge is hard
to generalize from and apply in other situations.
III. RESCUING IS PROJECTS
Table I shows many project issues that can give a project a
red light. Although we collect exciting project data, interview
project members, and conduct risk assessments before taking
remedial actions, a study shows that many troubled projects are
already in trouble early in the lifecycle. If so, data collected
from these projects are inaccurate. How project members tell
about the project can be biased as project members will speak
out of self-interest, rather than with the goal of identifying real
problems with the project.
In many software projects, a small problem often becomes a
big issue because there is no problem owner or there may be
more than one problem owner. When the problem is one of a
conflict-of-interest between two parties, the situation can create
political fighting. Moreover, once the project gets into trouble,
project members may be firefighting with (or even hiding) their
own problems and be unconcerned as to how these problems
might create other problems. And then, there is also the problem
of social loafing [36] in which people contribute less to achieve
a goal when they work in a group than when they work alone.
This paper considers a real case in which a troubled IS project
is rescued by reviewing and changing an existing project team
structure so that every project issue always has one problem
owner to follow up.
IV. KUDRINK AND SAP
KuDrink had a versatile business in the Hong Kong market:
purchasing their products from KuDrink’s China manufactur-
ing unit, selling its alcoholic drinks, distributing other indirect
competitors’ alcoholic drinks, providing supporting services,
marketing promotion activities and sponsoring various activi-
ties. Fig. 1 provides a cost breakdown for the major activities
of the Hong Kong operation in 2002. Administration and staff
salary were fixed costs. They did not vary depending on produc-
tion or sales levels. Product costs were related to sales volume.
“Customer Fund/Outlet Promotion” and “Free Beer/Discount”
were two incentives offered by KuDrink. The first was a time-
based rebate agreement between KuDrink and each individual
customer (which are typically wholesalers rather than end con-
sumers), in which a sales (or volume) target must be achieved
in a specific period. The latter was a trade discount, including
discount by percentage and free beer (e.g. buy ten get one free).
Fig. 1. Total annual costs of KuDrink (U.S.$44 million in 2002).
This incentive had no specific target beneficiary. KuDrink had
as many as 4000 clients.
Incentives constituted nearly 40% of the total annual costs,
implying there should be a proper control over how these re-
sources were allocated, in particular, to high repeat customers.
The legacy ERP application on IBM A/S 400 in KuDrink could
not provide an analysis of past performance, e.g., profitability
on operational transactions of outlets, which would provide a
rational way for making decisions and would serve as a baseline
for judgment. Thus, a project goal was clearly established by
KuDrink Senior Management; the new ERP application must be
able to handle rebates, customer sales contracts, logistic costs,
promoter bonus, etc., which altogether produce a profit-and-loss
statement for each customer. This sheet would allow KuDrink
to better allocate its resources and determine the right level of
service, pricing, and distribution.
SAP has been implemented in a number of KuDrink brew-
eries around the world as the adoption of SAP was a KuDrink
Cooperate IT policy. Thus, KuDrink Hong Kong decided to im-
plement SAP R/3 and hired MirageTech Ltd. (not a real name),
a company that in 1999 was certified as a TeamSAP partner col-
laborating with SAP to deliver business solutions and services to
SAP clients. Veterans from SAP and MirageTech established an
on-site hybrid consultancy team for the KuDrink Project, with
MirageTech as team leader. In this paper, we refer to this hybrid
team as “the ERP consultants” and the team leader as “the ERP
manager” (see Fig. 2).
Sections IV-A–IV-C will provide background to the KuDrink
project and briefly review the project team structure and a SAP
methodology called AcceleratedSAP [37].
A. Project Team Structure
As in many SAP projects, roles and responsibilities were
clearly addressed in the Project Charter by the ERP vendor,
including skills and experience required to do the job. Problem-
atically, however, at the beginning of the project, neither the
ERP vendor nor the project manager assessed the criteria for
qualifications for each role according to the Project Charter. As
a result, the team structure failed to reflect the actual competence
of KuDrink’s team.
Fig. 2 shows the project organizational chart containing brief
descriptions of each role. The Steering Committee consisted
of senior executives of KuDrink, the Managing Director from
Europe, the General Manager (HK), and the Managing Direc-
tor of MirageTech. The project team was headed by a Project
LUI AND CHAN: RESCUING TROUBLED SOFTWARE PROJECTS BY TEAM TRANSFORMATION: A CASE STUDY WITH AN ERP PROJECT
Fig. 2. Project team structure by functional module.
Manager, who provided management direction, resolved issues
in the project team, and ensured adequate project resources were
allocated for all the tasks to be undertaken at each phase of the
project.
The ERP Manager from MirageTech assisted the KuDrink
Project Manager in the definition and execution of project de-
liverables and the weekly management of the entire project.
The ERP consultants provided SAP software expertise. There
were five application consultants mainly responsible for SAP
application setup and problem solving according to Blue Print
Documents (see Fig. 3). As mentioned, there were consultants
from both SAP and MirageTech.
A Process Owner had ownership of the process area(s) and
the project deliverables, along with day-to-day management of
the business area(s). In SAP, Material Management includes
both warehouse and purchasing functions, which were man-
aged by two departments in KuDrink. Thus, there were two
Process Owners for Material Management. The position titles
of four Process Owners were Sales and Marketing Director,
Group Finance Controller, Senior Manager of Warehouse, and
Group Purchasing Manager.
A Process Support was responsible for the execution of
the detailed process design, master data configuration of the
company’s business processes with SAP, and develop Business
Blueprint Documents (see Fig. 3). Process Supports were either
line managers or KuDrink supervisors.
A Module Owner had the technical ownership of the process
area(s).
An MIS Programmer was responsible for the data mapping,
design, development, and testing of conversion programs, in-
terface programs, SAP custom reports, and forms. Before the
project’s inception, KuDrink recruited two programmers with
one and a half years of work experience in writing SAP ABAP
customized reports (e.g., Ageing Analysis Reports and Cus-
175
tomer Statements). Both the Module Owners and MIS Pro-
grammers were from KuDrink’s IT Department.
B. Project Methodology: Accelerated SAP
The ERP consultants provided detailed electronic documents
describing how to implement a SAP R/3 called Accelerated SAP
(ASAP). The method required the project team to define de-
tails of project scope, to establish a project organization for
roles and responsibilities, to produce a set of business process
blueprint documents, and to control project progress including
quality management, acceptance procedures, regular meetings,
and distribution of the minutes.
The ASAP framework shown in Fig. 3 divides an imple-
mentation project into five phases, each of which indicates
a specific purpose contributing to the achievement of project
goals. “Project Preparation” provides initial planning and prepa-
ration for a SAP implementation project. This includes defining
a unique objective, scope, priorities, and so on. The purpose of
the “Business Blueprint,” as the name suggests, was to create
a business process map, which is a detailed document describ-
ing how the company ran its business before it implemented
the SAP applications and how it intended to run it afterward.
“Realization” involves implementing the blueprint or realizing
the planned business processes. The phase ends by signing off
on an integration test that simulates a reengineered business
model and confirms that it works as expected. “Final Prepara-
tion” finalizes everything in readiness for going live with the
new systems and processes. This covers end-user training, data
migration, and “cut over” activities, etc. On successful comple-
tion of this phase, a client is ready to run their business with
their live SAP system. “Go Live and Support” is the last phase
of the AcceleratedSAP roadmap [38].
176
Fig. 3. Overview of SAP implementation (where • denotes quality check and
signing off at the end of the process).
C. Project Budget
Fig. 4 provides a final breakdown of the spending in
KuDrink’s SAP project, but it is being presented here for its
cautionary value, as a static picture of spending of this type can
be quite misleading as the tendency of costs is to expand and
contract as project conditions change. Here, for example, train-
ing, and software and hardware equipment were almost constant
but two items, consultancy and temporary staff, were prone to
vary widely in range if the project schedule slipped. This is im-
portant to know because it suggests that it would be prudent to
also control the consultants’ activities against the plan, rather
than as sometimes happens, treating them as being above or
outside the plan. The breakdown also shows that consultancy
was the largest portion of the project budget. Since the consul-
tants were paid per hour, so when a project schedule slipped, it
was likely that the consultancy costs would quickly exceed the
original budget. This is problematic even without regard to the
conflict of interest which is implied in paying someone more to
fix a problem the longer that they take to fix it. A final cost to
note is the 5% markup, which was allowed on top of the total
budget in case of unforeseen contingencies.
The team members received the SAP R/3 training from SAP
before the project actually started. This is consistent with the
recent recommendation on taking team learning behaviors into
consideration in training packages as soon as the ERP imple-
mentation team is formed. However, it was not known whether
SAP could provide users with assessment programs after each
IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 55, NO. 1, FEBRUARY 2008
Fig. 4. Costs of a 1.1 million SAP project (in U.S. Dollars).
training course. Nor did SAP provide any feedback to the
KuDrink management as to the exact benefits that KuDrink staff
are presumed to have gained from the training courses, which
cost U.S.$99, 000. Our findings with regard to ERP training can
be summarized in two points: start training as early as possible
and have training postassessments.
V. TROUBLED IT PROJECT
The Consulting Services Agreement between MirageTech
and KuDrink was signed in September 2001. The Agreement
had an estimated productive operation date at the end of March
2002. Seven months after the kickoff meeting, the project re-
ported a number of problems to KuDrink’s senior management.
Many project issues seem to be intuitive and nontechnical,
as if they might be easily understood by non-IT executives yet
may require or assume an unexpected or unperceived technical
knowledge. For example, suppose two man-months are required
to build a house. We may calculate the proportion of resources
required to build n houses as a linear relationship. However,
because of the factors of software complexity and reusability,
such a linear relationship cannot, however, be used to estimate
the efforts of writing 20 SAP ARAP reports. The KuDrink’s
senior executives, having educational backgrounds in Law and
Business Administration, did not necessarily understand every
point of the issues outside their fields, in this case, business
control and project management implementation, but especially
those relating to the resolution of ERP issues.
Sections V-A–V-H provide anecdotes from the project, each
of which reflects one or more of the projects’ wide array of
problems. Each of these sections is independent. These sections
mainly serve as recounts of what happened in the KuDrink
project. We include original email texts and PowerPoint slides
for reference. Section V-H provides our analytical discussion
about those projects events in connection with factors critical to
ERP Failures shown in Section II-A.
A. Project Plan
Fig. 5 shows the original plan, which estimates the project
as lasting for 7 months, from September 2001 to March 2002.
The system SAP would go live on April 1, 2002. During “Real-
ization,” the project schedule was revised and extended several
times: in January, early March, late March, and May 2002.
The reported reason for extending the length of the project
was that Process Support could not complete their tasks
LUI AND CHAN: RESCUING TROUBLED SOFTWARE PROJECTS BY TEAM TRANSFORMATION: A CASE STUDY WITH AN ERP PROJECT
Fig. 5. Project schedule (∗ denotes revision of the project plan).
on schedule. The tasks were to develop business blueprint
documents, change their requirements, request non-SAP stan-
dard reports, perform system tests, and sign off on their work.
Yet, Process Support complained about their heavy workload in
producing lengthy documents and drawing flow diagrams, and
also reported encountering unknown SAP configuration prob-
lems during testing. Process Supports often reported that previ-
ous testing cases tested okay but, that the same cases failed after
the ERP consultants changed some settings. They felt frustrated
and lost confidence in the system (or, rather, in the consultants
and the Module Owners).
In March 2002, an announcement was formally made by the
General Manager of KuDrink that a special project bonus would
be awarded to the whole project team if the system could go
live in July. However, no significant progress was subsequently
achieved. By the end of April, not only did the project schedule
seem tentative, but team members were confused as to their
responsibilities and the overall schedule, because April, May,
June, and July had formerly been proclaimed as an unchangeable
project deadline (see Fig. 5).
At the end of April, the KuDrink Project Manager asked all
Process Supports and Module Owners to vote for the date of the
system going live. Her e-mail follows.
177
B. Meeting Minutes
The ERP Manager suggested that Process Supports should
take the minutes for their own areas. However, this created
an unnecessary workload (or confusion) because it meant that
two Process Supports would in all likelihood both record the
same event and this would, in turn, mean two follow ups to
the recorded event. For instance, many inventory operations
would involve both FI (Finance) and MM (Logistics) Process
Supports. Taking minutes in the suggested way would cause
some confusion. In addition, different parts of the duplicated
minutes also had to be consolidated on a single record for filing
and distribution. Following is the email regarding the meeting
minutes. Later, it was agreed that the project manager would
take all the minutes.
C. Work Allocations
Work allocation involves intergroup coordination. As an ex-
ample, Fig. 6 shows a detailed flowchart for how an invoice note
was developed in the KuDrink project.
Such a clear-cut work allocation caused an unexpected sit-
uation. The MIS programmers did not know how to issue an
invoice from the SAP. They only knew how to develop the in-
voice note. As a result, they could not perform step 11 (a unit
test) by themselves and could only test their programs with
sample data prepared by the Module Owners. Moreover, the
Module Owners had never programmed a report. Thus, even
in the presence of both the Module Owner and MIS Program-
mer, it was not possible to identify many problems related to
reports.
D. Decision Support
The ERP manager and consultants were not able to pro-
vide many supporting points for decision making and direction
guidelines. They always said, “From my previous experience,
my clients also encountered the same situation and they used
this technique to solve it.” Unfortunately, the ERP manager
could not provide more information about how the previous
case was related to KuDrink and how the result could be mea-
sured after applying the technique. The following e-mail demon-
strated a way in which the ERP manager gave professional
advice.
Note that the parallel run was a system implementation ap-
proach in which a new ERP system was operated along with
178 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 55, NO. 1, FEBRUARY 2008
Fig. 6. Work allocation and workflow.
the old system for a short period before the old system was shut
down. In contrast, the straight cutover was to implement a new
ERP system in operation after shutting down an old system [39].
The two approaches are depicted in Fig. 7.
E. Consultant Management
In a Process Owner meeting at the “Realization” Stage
(February, 2002), the ERP Manager addressed the necessity for
a system refresh (i.e., reinstallation) due to significant changes
in the Chart of Accounts, which was defined in the “Business
Blueprint.” The refresh would take four working days and incur
extra costs (from U.S.$3500 to 18, 000).
The case was challenged by a Process Support staffer who was
responsible for the Chart of Accounts while both managers were
Fig. 7. Parallel run versus the straight cutover.
formally announcing their refresh plan to all the project mem-
bers. On the same day, the Process Support staffer wrote an email
explaining that changes to the Chart of Accounts did not cause
any conflict with the previous version of the Chart of Accounts.
Overnight, the issue disappeared without the two managers pro-
viding any explanation of how it was resolved. Changing the
requirements was not expected in Realization. In conclusion, it
is hard to know whether changing the requirements caused the
trouble, or ERP consultants made mistakes owing to the change
of the requirements, or whether the problems had some other
source.
F. Overwhelming Documentation
In a regular meeting at the Business Blueprint stage, a
Process Support requested a hard-copy system manual for
their reference. The ERP manager replied that manuals were
available only on CD. She strongly advised that they should
ask on-site ERP consultants for help as this would be
faster and better. The same Process Owner also requested
LUI AND CHAN: RESCUING TROUBLED SOFTWARE PROJECTS BY TEAM TRANSFORMATION: A CASE STUDY WITH AN ERP PROJECT
Fig. 8. PowerPoint slide presented to the Steering Committee.
some references such as another companies’ “Business
Blueprint” at the Business Blueprint Stage, “SAP Business
Processes and Procedures (BPP),” and “End-user Training”
documents at the Realization Stage. The ERP manager ar-
gued that these works were irrelevant because they involved
different businesses and KuDrink Process Supports might be
misled or be accused of plagiarism. This could be unex-
pectedly detrimental to successful SAP implementation, and
thus, the request was denied. Ultimately, Process Support
had to develop substantial amounts of documentation from
scratch.
G. Internal Conflicts
On March 11, 2002, the ERP manager reported the status
of the project, showing PowerPoint slides on human resources
and potential issues. These galvanized Senior Management into
accepting the difficulties. For reference, a full set of the Power-
Point slides is given in the Appendix.
The slide in Fig. 8 supports the idea that the project suffered
from a human resource problem arising from users requesting an
overwhelming number of reports. The solution could be either to
increase existing resources sevenfold or to prolong development
by 7 months.
A full set of slides was distributed to the project mem-
bers after the Steering Committee meeting. One slide (say-
ing the concept of accounting accruals having been over used)
179
might be considered quite inflammatory as it created an im-
pression that nonaccountants were challenging accounting prac-
tices. The following response came from the KuDrink’s Process
Owner.
H. Analysis
This section discusses the project events reported in
Sections V-A–V-G according to Section II-A. When no evidence
from the events in the KuDrink’s project is related to a factor
that is critical to a project failure, we can only conclude that
factor is not an issue in the project. We also provide our opin-
ions as to what type of problem the project was suffering from.
KuDrink’s project objective was clear and realistic: the ERP
application can produce a P&L statement by the customer. User
involvements did not appear to be any problem throughout the
project. The KuDrink project appeared not to suffer from prob-
lems with (2.1.2) an unrealistic project objective, (2.1.3) wrong
ERP strategy, (2.1.4) unsuitable ERP software and hardware,
(2.1.6) difficulty aligning to specific requirements, (2.1.17) neg-
ative user characteristics, (2.1.18) a lack of user involvement,
(2.1.20) data conversion behind time, (2.1.21) inadequate tech-
nical knowhow, or (2.1.22) problematic technology base.
It may not be straightforward to justify whether the project
encountered the other issues shown in Table II. For example,
in (2.1.15) unqualified personnel and (2.1.16) incorrectly es-
timated staff learning curve, KuDrink recruited two MIS pro-
grammers, who just had very basic knowledge of SAP ABRA
(SAP report writing language) and knew little about SAP ap-
plications. Thus, no one in KuDrink had SAP applications ex-
perience or SAP project management before. The team got the
knowledge through the SAP training courses, but how much
they actually learnt depends on the individual’s capabilities.
Furthermore, there was no assessment after training. As we
could not know how SAP knowledgeable the team members
were, we could not tell whether some problems could have been
prevented if the KuDrink team had been comprised of staff that
had 3–5 years of SAP application experience. But one thing
is certain: the success or failure of the KuDrink project would
depend on the staff’s learning curve.
The original project schedule was perfectly timed for
KuDrink. Alcoholic drinks were seasonal products in Hong
Kong, as shown by the monthly beer sales volume. This im-
plied that workload would be heavier during high season and
at that time, internal resources would be harder to reallocate.
180 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 55, NO. 1, FEBRUARY 2008
TABLE II
FACTORS CRITICAL TO THE KUDRINK’S ERP PROJECT
In this case, Months 1–6 and 11–12 were opportune periods
to implement ERP systems for KuDrink. Interestingly, ERP
vendors’ resources would normally be tight around the end of
year because they needed to help almost all clients work on
year-end closing. Neglecting seasonal effects on a project might
contribute to an unrealistic schedule that would suffer from re-
sources deadlock and load imbalance (i.e., 2.1.7. reallocating
tight internal resources).
Voting for a “go-live” date appeared to be politic as it was
not anonymous and the purpose was not for effort estimation.
What came along with the voting would be rumors (i.e., 2.1.19
dishonest Information Policy).
It is normal practice that meeting minutes be taken by only
one person [40], although it may not always be the same person
at each meeting. Considering the ERP manager had years of SAP
project management experience, we conclude that she would not
make such a mistake. However, her intention in asking Process
Owners to take minutes was unclear.
KuDrink’s problem with work allocations was an example of
bureaucratic project organization (2.1.14), which often occurs
in a sizable project. The bureaucratic culture was also demon-
strated when KuDrink Hong Kong failed to try to second one
or two IT staff from other KuDrink breweries (for example,
KuDrink Malaysia) where they already ran SAP.
There was no mechanism for measuring the quality of the ERP
consultants’ work products and services. As shown in Sections
V-D and V-E, the ERP vendor’s unilateral suggestion did not
sound reasonable to the Process Supports. From a user point of
view, this is a problem with the ERP consultant (i.e., 2.1.10). It
appeared that mutual trust was not building and distrust could
undermine both productivity and morale.
When ERP implementation takes more than one and a half
years, changing requirements during the implementation period
seems unavoidable. Business needs to respond to the competi-
tive market and changing can be for both excellence and surviv-
ing. The KuDrink project was not a long project, just 7 months
in the original plan. Therefore, COA should be clearly defined
at the Business Blueprint and the users should not revise COA
at the later phases. As expected, the ERP consultants would be
reluctant for any change because rework would be a must. What
came along with such changing would be conflicts between the
users and the ERP consultants.
In Section V-G, the project manager reported to the man-
agement in the steering committee meeting a project dilemma
between more resources without 7 month delay and existing
resources with 7 month delay. The project manager may have
intended to simplify the calculation for presentation or she may
have been unaware of some of the salient characteristics of soft-
ware project management. It is true that building one house for
one man-month, we build seven houses for either 7 man-months
or 7 month men. But, men and months are not interchange-
able [41] in software projects.
The unwillingness of project managers to report negative
news is a contributor to the phenomenon of troubled software
projects. Tan, Smith, and Keil [42], [43] report that people from
collectivistic cultures (i.e., China and Hong Kong [44]) may
be disinclined to report bad news about software projects when
they believe that more time given could help the team to get
the projects back on track. In the KuDrink project, we could
not conclude that the project manager failed to report the prob-
lems to the top Management early enough. It might be equally
possible that the top management were not equipped to fully
recognize all of the implications of IT project issues.
Although the IT department reported that they did not have
the full support of top management (2.1.1), this may not be the
case. It may just have been that when management had doubts
about the practices adopted by the project manager, they delayed
making a decision as to whether to support the IT department.
VI. TEAM TRANSFORMATION
Many project problems can be classified into different types
of issues (Section V-H). The KuDrink problems might be con-
sidered in terms of factors critical to ERP failures, although the
root causes of the problems have not yet been addressed. It is
easier to group an event or a problem by type than to identify
its cause. In this way, we can identify a problem by its type and
place it in a 2-D matrix: process area and functional module.
For example, a problem like user disagreement with new re-
port formats may correspond to three functional modules, but it
will only correspond to one process area for SAP, APRA report
development.
The process area and functional module can link up with two
types of team structures. A team can be established according
to the functional model shown in Fig. 2. This is a common
ERP implementation model. The drawback is the main source
of task conflicts, which has been discussed in Section II-B. A
team can also be structured with process areas. Many software
development teams are formed in this way: this team is usually
composed of three or more subteams, one of each being respon-
sible for business requirements, development, and testing.
A 2-D matrix of process area and functional module can be
formed. Problems can be identified in the matrix. For exam-
ple, problem A shown in Fig. 9 involves both user acceptance
LUI AND CHAN: RESCUING TROUBLED SOFTWARE PROJECTS BY TEAM TRANSFORMATION: A CASE STUDY WITH AN ERP PROJECT
Fig. 9. Team composition by either functional module or process area.
testing and report development. Problem B involves three func-
tional modules. The matrix provides an analytical tool for use in
decision making. When the ERP project problems are oriented
to more functional modules than process areas, the team struc-
ture should be organized by process area so that each problem
is managed by one subteam. For example, in problem B (see
Fig. 9), a team structure by functional module (see Fig. 2) says
nothing about which subteam is responsible for dealing with the
problem B. However, when a team structure is formed by process
area, the problem B belongs to the subteam of the user accep-
tance test. The team and its subteams can concentrate on their
commitment to accountability, responsibility, and transparency
in the way the team manages and operates the ERP project.
A. KuDrink’s Management Decision
At the end of May, KuDrink was still at the Realization
stage. The senior management had a formal meeting with the
Managing Director of MirageTech and discussed the approach
to completing their late ERP project. The management sketched
a diagram (i.e., Fig. 9) on the whiteboard. It would seem that the
KuDrink management did not pay due regard to that fact that
problems can recursively cause other problems. This contrasted
with the usual practices of IT project managers. As a matter
of fact, the more IT experience a person has had, the more
chance he/she likes to work out what problems might arise. The
KuDrink management found that many problems belonged to
System Configures and UAT. Each problem should have a sin-
gle owner responsible for it. Thus, a team structure should be
changed to link with the situation.
On June 1, 2002, the KuDrink management formally an-
nounced a restructure of the project team shown in Fig. 10. Tasks
in Realization and Final Preparation were combined into just one
stage. The Finance Director was appointed to take over all the
responsibilities of user acceptance testing. One Module Owner
would be in charge of the report writing. The project manager
would only be responsible for data migration and one MIS pro-
grammer was responsible for technical server problems. These
four team leaders and the ERP manager reported directly to the
General Manager. With this structure, the team leaders managed
their resources with the direct support of the top management.
181
Fig. 10. Project team structure by process area.
A weekly meeting chaired by the General Manager was held as
usual to report and monitor the progress of the project.
The structure would be of assistance for a General Manager in
coordinating operation flows (i.e., user acceptance testing) and
information flows (i.e., report customization and data migration
from A/S400). In addition, whereas the previous team structure
had six reporting channels to the Project Manager, the new
structure had only four and these flowed to the General Manager.
The project plan was revised based on the decision made by the
four team leaders.
It should be noted that the KuDrink management deempha-
sized the title of Project Manager in the new structure. The
General Manager of KuDrink (Hong Kong) was not the project
manager because he only chaired the ERP meeting and he had
no time to track the project progress on a daily basis.
Accountability is clarified. Team leaders can solve project
problems by function. For example, in the anecdote of work
allocations reported in Section V-C, the reporting team leader
can simplify the report development workflow.
When accountability and responsibility are crystal clear, we
can achieve higher project visibility. Ideally each problem or is-
sue would be bound to one process area, and hence, be managed
by one team leader. This would assign every problem to a single
owner. KuDrink management believed that problems that had
no owner or more than one owner could not be solved quickly
no matter how simple they might be.
SAP went live on September 1, 2002. After a month, the
legacy system A/S 400 ceased operation. Although the project
was 5 months behind the original go-live date, April 1, 2002, the
project was completed within budget and the system achieved
its goal, a customer P&L statement.
182 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 55, NO. 1, FEBRUARY 2008
B. Discussion
This section generalizes some principles from action the
KuDrink’s management took to rescue their troubled project.
The principles are conclusively demonstrated in comparison
with usual practices.
In a survey of 122 projects, project managers in 8 of 76
successful projects and 11 of 48 failed projects were changed
during the projects. However, the study did not provide infor-
mation as to whom these project managers reported as there can
be a difference between a decision made by a Chief Executive
Officer (CEO) and a Chief Information Officer (CIO). CEOs
who know little about the complexity of IT projects may just
replace the project manager. This would be like trying to turn
around a losing company by finding a new CEO [45].
1) Usual Practice 1: Senior management pulls the plug on a
leader who fails to drive the project (i.e., the project manager)
as far as the management is able to put another right person in
charge.
However, CIOs who are expected to be ERP literate believed
that failing team leaders/members should not be replaced until
the project is completed or cancelled. Removing team lead-
ers/members from a late project is counterproductive since we
lose the valuable experience they have gained in the project.
Neither adding people nor replacing team members made the
KuDrink project faster.
When to ask a team leader to leave his project is as much
art as it is science. The KuDrink management understood that
asking team members to leave the project would be of no help.
The management decided to narrow down the responsibilities
of the project manager to one particular area. Changing the
team structure resolves (or relieves) existing conflicts between
Project Manager and Process Supports, as in the case described
in Section V-G.
2) (KuDrink Management) Action 1: Senior management
should narrow down the responsibilities of the driving staff
(e.g., project managers) so that they need to focus on only one
or two process areas.
Most senior executives were uninformed about technical im-
plications. Drawing incorrect conclusions from problems in IT
projects can be disastrous for a project.
3) Usual Practice 2: Executives who have engineer-
ing/science backgrounds tend to prefer determining causality
in a failing project, and then, to immediately take remedial ac-
tions to rescue the project.
The importance of root-cause analysis has been mentioned in
Agile Software Development Management [46]. But, as in fail-
ing projects, the most secure way to do root-cause analysis is to
base it on project data, rather than causal reasoning. Overcoming
the temptation to think in a cause–effect way is particularly hard
for CIOs who are able to combine information technology skills
with an understanding of the organization across all functions
from problem solving to strategies [47]. The KuDrink manage-
ment knew nothing about IT, and hence, would not bother to
understand the causality. What the management looked at was
not remedial actions, but the connection between the team struc-
ture and problem domains. The management tried to understand
who owned the problem rather than what the problem could
be. If there is no owner or more than one owner, restructure the
team so that for each problem there is always one owner.
4) (KuDrink Management) Action 2: In a failing IT project,
executives should concentrate on what process areas and func-
tional modules the (technical/nontechnical) problems occur (see
Fig. 9), rather than what the problems could actually be. Ap-
propriate actions can then be taken.
Some executives may promote a project member of staff to
take over some major part of a project manager’s responsi-
bilities. The reason is obvious: the project member who has
participated in the project and has understood the organization’s
operations will be highly motivated and committed as such expe-
riences provide a valuable opportunity for professional growth.
5) Usual Practice 3: Senior Management assigns a person at
the same rank or just below that rank as the project manager
in the company to take over the functional title of the project
manager.
To deal with a troubled project, it is advised that the senior
executive sit in all regular meetings. This has three major ben-
efits: it rebuilds the team spirit, resolves any politics among
team members, and produces a positive influence on team effec-
tiveness through positional diversity, as mentioned in empirical
finding 2.2.3.
6) (KuDrink Management) Action 3: Senior Management
should assign a person with a higher rank than the project
manager in the company to take the chairperson role for each
project meeting.
VII. CONCLUSION
The paper contributes to our understanding of the process
of rescuing a troubled ERP project. Past studies have em-
phasized problem analysis [3]–[14], but this merely provides
a postmortem rather than a feasible solution to a troubled IT
project. We have also considered why it is difficult to learn from
failing IT projects. Without understanding what has caused a
project to fail, enforcing software process control and changing
current practice are little more than trial-and-error approaches
and should be implemented only as last options. However, the
KuDrink case has shown that it is not necessary to spot the root
causes of problems when rescuing troubled IT projects. When
a problem involves two or more subteams, there is a need for
greater transparency. It may, in fact, be a better approach to
first confine the problem to one process area under one team
leader, and then, to restructure the project team along a dimen-
sion in which accountability, transparency, and responsibility
are in connection with the problem.
Although team transformation is not a silver bullet that cures
IT project troubles of all kinds, in our view, the principles behind
KuDrink’s team transformation are certainly sufficiently generic
within the corporate-industrial environment that they should be
applicable to many, if not all, other failing software projects.
Keeping the project manager in place but narrowing down the
scope to one process area, making people responsible for other
process areas, and having the General Manager chair the ERP
meetings are ultimately steps that reflect the corporate nature of
contemporary software development, which ultimately puts an
LUI AND CHAN: RESCUING TROUBLED SOFTWARE PROJECTS BY TEAM TRANSFORMATION: A CASE STUDY WITH AN ERP PROJECT
essentially nontechnocratic and business-oriented emphasis on
accountability, transparency, and responsibility [46].
REFERENCES
[1] A. P. Snow and M. Keil, “The challenge of accurate software project status
reporting: a two-stage model incorporating status errors,” IEEE Trans.
Eng. Manage., vol. 49, no. 4, pp. 491–504, Nov. 2002.
[2] D. Cooke, L. Gelman, and W. J. Peterson, “ERP trends, the conference
board,” Rep. R-1292–01-RR, 2001.
[3] K. Ewusi-Mensah, Software Development Failures: Anatomy of Aban-
doned Projects. Cambridge, MA: MIT Press, 2003.
[4] J. Verner and W. Evanco, “In house software development: What software
management practices are needed for project success,” IEEE Softw.,
vol. 22, no. 1, pp. 86–93.
[5] M. Jørgensen and D. Sjoberg, “The importance of not learning from
experience,” in Proc. Eur. Softw. Process Improv., Copenhagen, Denmark,
2000, pp. 2.2–2.8.
[6] C. P. Holland and B. Light, “A critical success factors model for ERP
implementation,” IEEE Softw., vol. 16, no. 3, pp. 30–36, May/Jun. 1999.
[7] N. Welti, Successful SAP R/3 Implementation: Practical Management of
ERP Projects. Reading, MA: Addison-Wesley, 1999.
[8] Z. Zhang, M. K. O. Lee, P. Huang, L. Zhang, and X. Huang, “A framework
of ERP systems implementation success in China: An empirical study,”
Int. J. Prod. Econ., vol. 98, no. 1, pp. 56–80, 2005.
[9] J. Smith, Troubled IT Projects: Prevention and Turnaround. Stevenage,
U.K.: Institution of Electrical Engineers, 2001.
[10] E. Yourdon, Death March, 2nd ed. Upper Saddle River, N.J.: Prentice-
Hall, 2004.
[11] T. DeMarco and T. R. Lister, Waltzing with Bears: Managing Risk on
Software Projects. New York: Dorset, 2003.
[12] D. Remenyi, Stop IT Project Failures Through Risk Management.
London, U.K.: Butterworth Heinemann, 1999.
[13] R. Schmidt, K. Lyytinen, M. Keil, and P. Cule, “Identifying software
project risks: An international delphi study,” J. Manage. Inf. Syst., vol. 17,
pp. 5–36, 2001.
[14] J. J. Jiang, G. Klein, and R. Discenza, “Information system success as im-
pacted by risks and development strategies,” IEEE Trans. Eng. Manage.,
vol. 48, no. 1, pp. 46–55, Feb. 2001.
[15] M. Al-Mashari, A. Al-Mudimigh, and M. Zairi, “Enterprise resource plan-
ning: A taxonomy of critical factors,” Eur. J. Oper. Res., vol. 146, pp. 352–
364, 2003.
[16] J. S. K. Ang, C. C. Sum, and L. N. Yeo, “A multiple-case design methodol-
ogyfor studying MRP success and CSFs,” Inf. Manage., vol. 39, pp. 271–
281, 2002.
[17] P. Bingi, M. K. Sharma, and J. K. Godla, “Critical issues affect-
ing an ERP implementation,” Inf. Syst. Manage., vol. 16, pp. 7–14,
1999.
[18] O. M. Burns and D. Turnipseed, “Critical success factors in manufacturing
resource planning implementation,” Int. J. Oper. Prod. Manage., vol. 11,
pp. 5–19, 1991.
[19] J. F. Cox and S. J. Clark, “Problems in implementing and operating a
manufacturing resource planning information system,” J. Manage. Inf.
Syst., vol. 1, pp. 81–101, 1984.
[20] K. K. Hong and Y. G. Kim, “The critical success factors for ERP im-
plementation: An organizational fit perspective,” Inf. Manage., vol. 40,
pp. 25–40, 2002.
[21] V. A. Malbert, A. Soni, and M. A. Venkataramanan, “Enterprise resource
planning: Managing the implementation process,” Eur. J. Oper. Res.,
vol. 146, pp. 302–314, 2003.
[22] Y. Xue, H. Liang, W. Boulton, and C. A. Snyder, “ERP implementation
failures in China: Case studies with implications for ERP vendors,” Int.
J. Prod. Econ., vol. 97, pp. 279–295, 2005.
[23] C. Rolland and N. Prakash, “Bridging the gap between organizational
needs and ERP functionality,” Requirements Eng., vol. 5, pp. 180–193,
2000.
[24] C. A. O’Reilly, D. F. Caldwell, and W. P. Bamett, “Work group demog-
raphy, social integration, and turnover,” Administ. Sci. Quart., vol. 34,
pp. 21–37, 1989.
[25] J. Pfeffer, “Organizational demography,” in Research in Organizational
Behavior, vol. 5, L. L. Cummings and B. M. Staw, Eds. Greenwich,
CT: JAI, 1983, pp. 299–357.
[26] Y. J. Yeh and H. W. Chou, “Team composition and learning behaviors in
cross functional teams,” Soc. Behav. Pers., vol. 33, no. 3, pp. 391–402,
2005.
183
[27] J. Anton and N. L. Petouhoff, Customer Relationship Management : The
Bottom Line to Optimizing Your ROI, 2nd ed. Upper Saddle River, NJ:
Prentice-Hall, 2002.
[28] L. H. Pelled, K. M. Eisenhardt, and K. R. Xin, “Exploring the black box:
An analysis of work group diversity, conflict, and performance,” Administ.
Sci. Quart., vol. 44, pp. 1–28, 1999.
[29] K. A. Jehn, G. B. Northcraft, and M. A. Neale, “Why differences make a
difference: A field study of diversity, conflict, and performance in work-
groups,” Administ. Sci. Quart., vol. 44, pp. 741–763, 1999.
[30] B. R. Forer, “The fallacy of personal validation: A classroom demonstra-
tion of gullibility,” J. Abnorm. Psychol., vol. 44, pp. 118–121, 1949.
[31] S. Plous, The Psychology of Judgment and Decision Making. New York:
McGraw-Hill, 1993.
[32] B. Brehmer, “In one word: Not from experience,” Acta. Psychol., vol. 45,
pp. 223–241, 1980.
[33] R. E. Nisbett and T. E. Wilson, “Telling more than we can know:
Verbal reports on mental process,” Psychol. Rev., vol. 84, pp. 231–259,
1997.
[34] A. C. North, D. J. Hargreaves, and J. McKendrick, “The influence of
in-store music on wine selections,” J. Appl. Psychol., vol. 84, no. 2,
pp. 271–276, 1999.
[35] J. Preston and N. Epley, “Explanations versus applications: The explana-
tory power of valuable beliefs,” Psychol. Sci., vol. 16, no. 10, pp. 826–832,
2005.
[36] J. M. Jackson and J. M. Harkins, “Equity in effort: An explanation of
the social loafing effect,” J. Pers. Soc. Psychol., vol. 49, pp. 1199–1206,
1985.
[37] S. M. Stewart, AcceleratedSAP: Implementation at the Speed of Business.
New York: McGraw-Hill, 1998.
[38] K. M. Lui and K. C. C. Chan, “Capability maturity model and SAP:
Toward a universal ERP implementation model,” Int. J. Enterprise Inf.
Syst., vol. 1, no. 3, pp. 69–95, 2005.
[39] B. D. Hiquet and A. F. Kelly, SAP R/3 Implementation Guide: A Manager’s
Guide to Understanding SAP. Indianapolis, IN: Macmillan Technical,
1998.
[40] M. E. Haynes, Effective Meeting Skills: A Practical Guide for More Pro-
ductive Meetings. Menlo Park, CA: Crisp, 1997.
[41] F. P. Brooks, The Mythical Man-Month: Essays on Software Engineering,
Anniversary ed. Reading, MA: Addison-Wesley, 1995.
[42] H. J. Smith and M. Keil, “The reluctance to report bad news on troubled
software projects: A theoretical model,” Inf. Syst. J., vol. 13, pp. 69–95,
2003.
[43] B. C. Y. Tan, H. Jeff, H. J. Smith, M. Keil, and R. Montealegre, “Reporting
bad news about software projects: Impact of organizational climate and
information asymmetry in an individualistic and a collectivistic culture,”
IEEE Trans. Eng. Manage., vol. 50, no. 1, pp. 64–77, Feb. 2003.
[44] D. W. Karolak, Global Software Development: Managing Virtual Teams
and Environments. Los Alamitos, CA: IEEE Computer Society, 1998.
[45] J. Collins, Good to Great: Why Some Companies Make the Leap—and
Others Don’t. New York: Harper Collins, 2001.
[46] K. Beck, eXtreme Programming Explained, 2nd ed. Boston, MA:
Addison-Wesley, 2005.
[47] Y. Li, C.-H. Tan, and H.-H. Teo, “Innovative usage of information tech-
nology in Singapore organizations: Do CIO characteristics make a dif-
ference?,” IEEE Trans. Eng. Manage., vol. 53, no. 2, pp. 177–190, May
2006.
Kim Man Lui received the Bachelor’s degree from
Tamkang University, Tamsui, Taiwan, R.O.C., the
Master’s degree from the University of Witwater-
srand, Johannesburg, South Africa, and the Ph.D.
degree from the Hong Kong Polytechnic University,
Kowloon, Hong Kong.
He has held a number of IT positions in the com-
mercial sector in Hong Kong and China. Currently, he
is responsible for the setting up of a software devel-
opment center in China. The center adopts agile soft-
ware practices and is funded by a city government.
His research interests include agile software development and e-marketing. He
is the lead author of two Chinese books on CMM (published by the Tsinghua
University Press, Beijing, China, 2002) and eXtreme Programming (published
by the Publishing House of Electronics Industry, Beijing, China, 2005), re-
spectively. His latest book, which is titled Software Development Rhythms:
Harmonizing Agile Practices for Synergy will be published by Wiley in 2008.
184 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 55, NO. 1, FEBRUARY 2008

Keith C. C. Chan received the B.Math. degree in

computer science and statistics, and the M.A.Sc. and
Ph.D. degrees in systems design engineering from the
University of Waterloo, Waterloo, ON, Canada.
From 1989 to 2003, he was with IBM, Canada
Laboratory, Toronto, ON, where he was engaged in
research on software engineering tools. In 1993, he
joined the Department of Electrical and Computer
Engineering, Ryerson University, Toronto, as an As-
sociate Professor, and in 1994, he joined the Depart-
ment of Computing, Hong Kong Polytechnic Univer-
sity, Hong Kong, where he is currently a Professor and Head. He is also a Guest
Professor of the Graduate University of the Chinese Academy of Sciences,
Beijing, China. He is active in consultancy and has served as a consultant to
government agencies and various companies in Hong Kong, China, Singapore,
Malaysia, and Canada. His current research interests include agile software en-
gineering, data mining, and bioinformatics.

View publication stats