Rescuing Troubled Software Projects - IEEE Xplore

IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 55, NO. 1, FEBRUARY 2008

171

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 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. Index Terms—IT project failures, risk management, software project management, team management.

I. INTRODUCTION ANY top executives with previously successful leadership 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 involve 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

M

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; [email protected]). 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

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 implementation found that, on average, the ERP implementation costs went 25% overbudget. Postmortem reviews, risk management, and critical success factors give us guidance on control actions and preventive actions so that we may stay out of trouble. 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 international 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 information. 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 strategy 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 between 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 paper 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 literature on ERP implementation failures, team composition, and issues of learning from IT experience. Section III addresses our

0018-9391/$25.00 © 2008 IEEE

172


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 resolution 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.

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

II. LITERATURE REVIEW Although there are a number of postmortem studies on abandoned IT projects [3]–[5], with the focus on key lessons learned from the successful IT projects [6]–[8], classifications of troubled IT projects [9], [10], and risk assessment, usually conducted 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, turning 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

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 Table 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 necessarily or sufficiently be the factors critical to project failures. We also include a list from in which Zhang et al. have consolidated 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 positional (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 different 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 slipping, failure to keep to the budget, and low morale among team members [26]. It has been confirmed during a CRM development 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 organizational levels. Those who are in higher ranks in the company

173

hierarchy can contribute their experience and exercise more positional 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 requirements during implementation may lead to the ultimate abandonment 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 purposefully. Forer [30] found that people with the belief that their temperaments are considered to be governed by the relative positions 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 difficulty 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 apply 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 solutions. 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 incorrect. Postmortem reviews may include much incomplete and/or incorrect information, and invalid conclusions about causal relationships may be drawn. However, they suggest how learning mistakes can be avoided by using statistical techniques to support our learned experience, by considering alternative perspectives 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 between 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


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 manufacturing unit, selling its alcoholic drinks, distributing other indirect competitors’ alcoholic drinks, providing supporting services, marketing promotion activities and sponsoring various activities. 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 production 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 timebased rebate agreement between KuDrink and each individual customer (which are typically wholesalers rather than end consumers), 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 resources 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 breweries around the world as the adoption of SAP was a KuDrink Cooperate IT policy. Thus, KuDrink Hong Kong decided to implement SAP R/3 and hired MirageTech Ltd. (not a real name), a company that in 1999 was certified as a TeamSAP partner collaborating 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. Problematically, 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 Director of MirageTech. The project team was headed by a Project


Fig. 2.

175

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 deliverables 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 managed 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, interface 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-

tomer Statements). Both the Module Owners and MIS Programmers 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 details 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 implementation project into five phases, each of which indicates a specific purpose contributing to the achievement of project goals. “Project Preparation” provides initial planning and preparation 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 describing 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 Preparation” 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 completion 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. 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

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, training, 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 important 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 consultants 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 implementation team is formed. However, it was not known whether SAP could provide users with assessment programs after each

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 reported 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 “Realization,” 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


177

B. Meeting Minutes

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 standard 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 problems during testing. Process Supports often reported that previous 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.

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 example, 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 situation. The MIS programmers did not know how to issue an invoice from the SAP. They only knew how to develop the invoice 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 Programmer, it was not possible to identify many problems related to reports. D. Decision Support The ERP manager and consultants were not able to provide 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 measured after applying the technique. The following e-mail demonstrated a way in which the ERP manager gave professional advice. Note that the parallel run was a system implementation approach in which a new ERP system was operated along with

178

Fig. 6.


Work allocation and workflow.

Fig. 7.

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

Parallel run versus the straight cutover.

formally announcing their refresh plan to all the project members. 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 providing 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


179

might be considered quite inflammatory as it created an impression that nonaccountants were challenging accounting practices. The following response came from the KuDrink’s Process Owner. H. Analysis

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 argued 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 unexpectedly 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 PowerPoint 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 members after the Steering Committee meeting. One slide (saying the concept of accounting accruals having been over used)

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 opinions 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 problems 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) negative user characteristics, (2.1.18) a lack of user involvement, (2.1.20) data conversion behind time, (2.1.21) inadequate technical 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 estimated staff learning curve, KuDrink recruited two MIS programmers, who just had very basic knowledge of SAP ABRA (SAP report writing language) and knew little about SAP applications. Thus, no one in KuDrink had SAP applications experience 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 implied that workload would be heavier during high season and at that time, internal resources would be harder to reallocate.

180


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 resources 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 demonstrated 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 competitive market and changing can be for both excellence and surviving. 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 management 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 software 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 interchangeable [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 problems 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 considered 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 report 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 responsible 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 example, problem A shown in Fig. 9 involves both user acceptance


Fig. 9.

181

Team composition by either functional module or process area.

testing and report development. Problem B involves three functional 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 structure 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 acceptance 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 single owner responsible for it. Thus, a team structure should be changed to link with the situation. On June 1, 2002, the KuDrink management formally announced 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 programmer 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.

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 deemphasized 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 issue 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


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 information 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 leaders/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 implications. Drawing incorrect conclusions from problems in IT projects can be disastrous for a project. 3) Usual Practice 2: Executives who have engineering/science backgrounds tend to prefer determining causality in a failing project, and then, to immediately take remedial actions to rescue the project. The importance of root-cause analysis has been mentioned in Agile Software Development Management [46]. But, as in failing 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 management 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 structure 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 functional modules the (technical/nontechnical) problems occur (see Fig. 9), rather than what the problems could actually be. Appropriate 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 responsibilities. 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 experiences 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 benefits: it rebuilds the team spirit, resolves any politics among team members, and produces a positive influence on team effectiveness 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 emphasized 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 dimension 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


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 Abandoned 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.: PrenticeHall, 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 impacted 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 planning: 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 methodologyfor 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 affecting 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 implementation: 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 demography, 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 workgroups,” Administ. Sci. Quart., vol. 44, pp. 741–763, 1999. [30] B. R. Forer, “The fallacy of personal validation: A classroom demonstration 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 explanatory 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 Productive 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 technology in Singapore organizations: Do CIO characteristics make a difference?,” 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 Witwatersrand, 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 commercial sector in Hong Kong and China. Currently, he is responsible for the setting up of a software development center in China. The center adopts agile software 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), respectively. His latest book, which is titled Software Development Rhythms: Harmonizing Agile Practices for Synergy will be published by Wiley in 2008.

184


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 Associate Professor, and in 1994, he joined the Department of Computing, Hong Kong Polytechnic University, 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 engineering, data mining, and bioinformatics.