96 A Work Breakdown Structure for Implementing and Costing an ERP Project

Fig 1. WBS for ERP Implementation

Communications of the IBIMA

Volume 6, 2008
Aisha Momoh,Rajkumar Roy and Essam Shehab 97

Fig 1a. WBS for ERP Implementation

Communications of the IBIMA

Volume 6, 2008
98 A Work Breakdown Structure for Implementing and Costing an ERP Project

Fig 1b. WBS for ERP Implementation

Table 1 below illustrates the various levels of project packages, whilst others use the terms phases, entries
activity in the WBS structures above. Each and activities [13]. In this paper, activities are used to
organization uses its own terminology for classifying classify the WBS components. The nodes (in circles)
WBS components according to their level in the A and B indicate continuation of the activities linked
hierarchy [13]. For example, some organizations refer to these nodes
to different levels as tasks, sub-tasks and work

Table 1: WBS Component Levels

Project First Level Second Level Activity Third Level Activity

Activity
ERP Project Preparation Define Project Scope and
Implementation Objectives
Identify Project Team
Identify Stakeholders
System Identify System Environment Technical Infrastructure
Architecture Preparation
Design
Identify Development
Environment
Identify Quality
Assurance Environment
Identify Training
Environment
Identify Production
Environment
Business Blueprint AS-IS Business Process Identify End-to-End
Analysis Current Business
Processes
Identify Process
Integration Points
Map ERP Processes to
Business Processes

Communications of the IBIMA

Volume 6, 2008
 Aisha Momoh,Rajkumar Roy and Essam Shehab 99

Project First Level Second Level Activity Third Level Activity

Activity
Define TO-BE Processes Define End-to-End
Future Business
Processes
Identify Gaps
Propose Gap Solution Define Reports
Define Programs
Define Interfaces
Define Manual
Processes
Document Blueprint
Sign Off Blueprint
Configuration and Configure Solution Write Unit Test Scripts
Development
Configure Solution
Unit test Configuration
Develop Code for Identified Write Technical
Gaps Specifications
Write Unit Test Scripts
Unit Test
Programs/Reports/Interf
aces
Sign Off Configuration and
Development
Define Define Roles in Organisation
Authorizations
Identify Roles for Use of
ERP
Define Authorisations
Test Authorisations
Sign Off Authorisations
Data Conversion Define Fields in ERP
Solution
Map ERP Fields to Legacy
System Fields
Convert Legacy Fields to
ERP Fields
Define Data for Cleansing
Cleanse Data
Sign Off Data Cleansing
Data Migration Develop Migration Program
Program
Development
Unit Test Migration Program
Sign Off Data Migration
Program
System Testing Define Test Scripts
Test ERP Solution End-to-
End
Sign Off System Tests

Training Define Business Processes

Based on Roles

Communications of the IBIMA

Volume 6, 2008
100 A Work Breakdown Structure for Implementing and Costing an ERP Project

Project First Level Second Level Activity Third Level Activity

Activity
Document Training
Train Users on Business
Processes
Train Users on ERP
User Acceptance Define Business Scenarios
Testing
User Acceptance Test Create Fault Report
Documents Sheet
Define User Acceptance Test
Scripts
Test ERP functionality
Sign Off
Cutover Migrate Cleansed Data
Go Live

5. WBS Activities and Potential Challenges team is not responsible for the technical infrastructure,
it is essential that it is flagged in the WBS as a
The WBS project activities in table 1 will be described dependency.
in this section. They have been derived from the
ASAP project methodology, literature review on Potential challenges in this activity are: (i)
project methodologies and SAP implementation unavailability of technical infrastructure, (ii)
experience. Certain activities that are already technology complexity[4], (iii) failure in attempt to
embedded as sub-tasks in ASAP project activities are link legacy applications, (iv) and minimal
illustrated as First Level activities for transparency understanding of architecture requirements and
and more effective planning. Such activities are design.
System Architecture Design, Define
Business Blueprint
Authorizations, Data Conversion, Data Migration
Program Development, System Testing, Training, and This activity has been described in section 4 of this
User Acceptance Testing. First Level activities will be paper. Some of the likely potential challenges during
the focus of this section as well as the potential the execution of this activity are: (i) minimal
challenges that could emerge during the execution of understanding of business processes, (ii) business
each activity. requirements to customize the ERP application
beyond its standard functionality, (iii) lack of business
Project Preparation process reengineering, (iv) employee resistance to
change, (v) use of inexperienced consultants, and (vi)
This activity has been defined in section 4 of this minimal understanding of the ERP application
paper. Some of the challenges that may present functionality. Further challenges are being unable to
themselves in project management and control, which comply with the standard which ERP software
is part of project preparation, are: (i) lack of supports, and a lack of integration between enterprise-
agreement on project goals, (ii) lack of senior wide systems [4].
management involvement, and (iii) a lack of effective
project management methodology [4]. Configuration and Development

System Architecture Design This activity is equivalent to the Realisation part of

the ASAP methodology. It involves configuring the
The essence of this activity is to agree on and define ERP application based on the business blueprint. It is
the environment upon which the ERP application will essential the application is configured using to the
be installed. At this stage, the environments in which standard functionality in the system. Other activities
the application will be configured, quality assured and under the umbrella of this main activity are the
operate in a live situation are also critical development of reports, interfaces and additional
considerations. Furthermore, even though the project programs.

Communications of the IBIMA

Volume 6, 2008
 Aisha Momoh,Rajkumar Roy and Essam Shehab 101

Some of the likely challenges in this activity are: (i) The type of challenges that may be faced during
unclear and misunderstanding of changes in system testing are: (i) discovering that a substantial
requirements, (ii) lack of an effective methodology, amount of the configured functionality does not meet
and (iii) poor estimation and failure to perform the business requirements, (ii) allowing scope creep due
activities needed [4]. Customization is usually to sudden changes, (iii) the tendency to carry on
associated with increased IS costs, longer testing beyond its specified, and (iv) lack of
implementation time, and the inability to benefit from understanding of the ERP application.
vendor software maintenance, and upgrades [5].
Another key challenge is a lack of understanding of Training
the ERP application by the consultants. Additionally,
lack of resources represents a major concern in ERP Training involves imparting knowledge of the
implementation [5]. implemented solution to the users before the system
goes into live operation. This activity entails defining
Define Authorizations business processes for the respective roles and
defining business scenarios to suit these processes.
The purpose of this activity is to define the roles of the These scenarios enable the users to understand the
respective ERP application users once the application system functionality better.
has gone live. These roles will be used to define
access rights for each of the users. This way, Insufficient training of end users could be a potential
unauthorized users will not be allowed access to challenge during the Training exercise [4]. Other
information in the ERP application that is not within potential challenges are: (i) lack of user commitment
their jurisdiction. The main challenge in this activity and ineffective communication with users, and (ii)
is incorrect definition of roles and authorizations. conflicts between user departments [4].

Data Conversion User Acceptance Testing (UAT)

This activity involves converting the format of the This activity involves the users whom will utilize the
data in the legacy system to suit the data format of the ERP application in a live environment, ensuring that
ERP system. This process also entails cleansing the all the business requirements are met in the system
data in the legacy system. This means that the users and are functional. The users define business
will filter through the data in their old system, and scenarios for testing.
eradicate any discrepancies.
Potential challenges in UAT are: (i) lack of user
A fundamental requirement for the effectiveness of training, (ii) lack of understanding of the business
ERP system is the availability and timeliness of processes and requirements, and (iii) resistance to
accurate data [5]. They further advise that the change.
management of data entering the system is a critical
issue throughout system implementation. Data-related Cutover
challenges include finding the proper data to load into
the system and converting disparate data structures This activity means going live by migrating from the
into a single, consistent format before system use [5]. legacy system to the ERP application. This
application becomes operational in a live
Data Migration Program Development environment. It involves migrating live data from the
legacy system to the new system.
The Data Migration Program Development activity
involves coding the program that will transfer the data Typical challenges that may be presented whilst
from the legacy system to the ERP application. executing this activity are: (i) unavailability of a
Potential challenges that could be presented during the complete set of data for migration, (ii) failure of data
execution of this activity are: (i) lack of coding skills, migration program, (iii) unavailability of operational
and (ii) improperly defined data. environment for data to be migrated into, and (iv) lack
of business readiness.
System Testing
6. Discussions and Conclusion
System Testing entails the consultants that
implemented the ERP application ensuring that the Researchers and practitioners concede that ERP
system works end-to-end. The entire system is tested, implementations are fraught with problems.
process by process across all functions of the system. Literature review reaffirms this fact, and illustrates a

Communications of the IBIMA

Volume 6, 2008
102 A Work Breakdown Structure for Implementing and Costing an ERP Project

variety of ERP implementation challenges. However, [6] Daneva, M. @Lessons Learnt from Five Years of
not much is mentioned about poor project planning Experience in ERP Requirements Engineering”,
being one of the challenges encountered in ERP Proceedings of the 11th IEEE International
project execution. The methodologies used in project Requirements Engineering Conference, 2003.
planning and the way that they are used go a long way
in determining the success or failure of a project. [7] Gable, G.G., Scott, J.E., Davenport, T.D.
“Cooperative ERP Life-Cycle Knowledge
A good project methodology known as ASAP, which Management”, Proceedings of the Ninth Australian
is used in SAP implementations, was studied. Conference on Information Systems, September –
However, in order to ensure that all aspects of an ERP October 1998, pp. 227-240.
implementation are addressed, it is advisable to extend
ASAP and other methodologies into a WBS. The [8] Leopoulos, V., Kirytopoulos, K., Voulgaridou, D.
WBS will be used to define the ERP project activities “ERP Systems as a Component of the Electronic
so that the lowest level of activity is accounted for. Supply Chain: Classification of Implementation
This paper illustrated the use of a WBS in defining Risks”, Proceedings of the 2005 International
project activities. Additionally, based on a previous Conference on computational Intelligence for
case study and literature review, the challenges that Modelling, Control and Automation, and International
likely to be encountered in ERP implementations were Confe Intelligent Agents, Web Technologies and
highlighted. Going forward, further research should Internet Commerce, 2005.
be conducted to link these challenges to the WBS
using a Risk Breakdown Structure (RBS). This [9] Esteves, J., Chan, R., Pastor, J., Rosemann, M.
exercise will guide an organization implementing ERP “An Exploratory Study of Knowledge Types
against the potential risks that are likely in project Relevance Along Enterprise Systems Implementation
activities. Phases”, 4th European Conference on Organizational
Knowledge and Learning Capabilities, April 2003.
A further area for research is the costing of ERP
project activities using a WBS. This will guide [10] Chang, S. “ERP Life Cycle Implementation,
organizations in preparing realistic budgets for their Management and Support: Implications for Practice
ERP implementations. and Research”, Proceedings of the 37th Hawaii
International Conference on System Sciences, 2004.
7. References
[11] Esteves, J., Pastor, J.A. “A Framework to
[1] Kovacs, G.L., Paganelli, P. “A Planning and Analyse Most Critical Work Packages in ERP
Management Infrastructure for Lare, Complex, Implementation Projects”, International Conference
Distributed Projects – Beyond ERP and SCM”, on Enterprise Information Systems, 2002.
Computers in Industry (51), 2003, pp. 165-183.
[12] Mabert, V.A., Soni, A., Venkataramanan, M.A.
[2] Wei, C., Wang, M.J. “A Comprehensive “Enterprise resource planning survey of US
Framework for Selecting an ERP System”, manufacturing firms”, Production and Inventory
International Journal of Project Management (22), Management Journal (41:2), 2000, pp. 52-58.
2004, pp. 161-169.
[13] Work Breakdown Structure.
[3] Labuschagne, C., Brent, A.C. “Sustainable Project Retrieved June 7, 2008,
Life Cycle Management: the Need to Integrate Life from:
Cycles in the Manufacturing Sector”, International //www.netmba.com/operations/project/wbs/
Journal of Project Management (23), 2005, pp. 159-
168. [14] Tausworthe, R.C. The Work Breakdown
Structure in Software Project Management.
[4] Huang, S., Chang, I., Li, S., Lin, M. “Assessing
Retrieved June 8, 2008,
Risk in ERP Projects: Identify and Prioritize the
from://md1.csa.com/partners/viewrecord.php?requeste
Factors”, Industrial Management & Data Systems
r=gs&collection=TRD&recid=A8133550AH&q=Wor
(104:8), 2004, pp. 681-688.
k+Breakdown+Structure+Tausworthe&uid=79289263
[5] Somers, T.M., Nelson, K.G. “A Taxonomy of 1&setcookie=yes
Players and Activities Across the ERP Project Life
Cycle”, Information and Management (41), 2004, pp.
257-278.

Communications of the IBIMA

Volume 6, 2008
 Aisha Momoh,Rajkumar Roy and Essam Shehab 103

Copyright © 2008 by the International Business

Information Management Association (IBIMA). All
rights reserved. Authors retain copyright for their
manuscripts and provide this journal with a
publication permission agreement as a part of IBIMA
copyright agreement. IBIMA may not necessarily
agree with the content of the manuscript. The content
and proofreading of this manuscript as well as and any
errors are the sole responsibility of its author(s). No
part or all of this work should be copied or reproduced
in digital, hard, or any other format for commercial
use without written permission. To purchase reprints
of this article please e-mail: admin@ibima.org.

Communications of the IBIMA

Volume 6, 2008