Aisha Momoh,Rajkumar Roy and Essam 1

A Work Breakdown Structure for Implementing and Costing an ERP Project

Aisha Momoh, Decision Engineering Centre, Cranfield University, Bedford, UK,[email protected]
Rajkumar Roy, Decision Engineering Centre, Cranfield University, Bedford, UK, [email protected]
Essam Shehab, Decision Engineering Centre, Cranfield University, Bedford, UK,[email protected]

Abstract in research. Based on the primary author’s in-depth

experience in ERP implementations, predominantly
This paper presents a Work Breakdown Structure SAP, she recognizes that some project methodologies
(WBS) for a phased implementation of an Enterprise are not detailed enough. Regardless of how effective
Resource Planning (ERP) solution. The key activities a methodology may appear, should it lack the relevant
that constitute an ERP implementation project are detail, the project in question may not yield the
discerned in detail, each in its entirety. Each activity anticipated success. In order to achieve a successful
illustrates the tasks required to fulfill each part of a implementation, this paper proposes the use of a work
project. The potential challenges that are usually breakdown structure (WBS) to guide an ERP project.
encountered in every selected activity are discussed.
Finally, using a WBS to cost an ERP project is A Work Breakdown Structure is a project
proposed. management tool. It is defined as an enumeration of
all work activities in hierarchic refinement of detail
which organizes work to be done into short
manageable tasks with quantifiable inputs, outputs,
Keywords: Work Breakdown Structure; WBS; ERP; schedules, and assigned responsibilities [14]. A WBS
Project Activities is also used for project costing. This paper discusses
using a WBS to organize an ERP project,

Literature review reveals that ERP implementations

1. Introduction are fraught with numerous problems. ERP
implementations are notorious for taking a longer time
ERP has been referred to as a business operating
and taking more money than is projected [12]. Most
system that enables better resource planning and
of the literature studied indicates a variety of issues
improved delivery of value-added products and
inherent in executing an ERP project. However, there
services to customers [10]. They automate core
is hardly any mention of failures based on poor project
corporate activities such as manufacturing and the
planning and methodology. Based on in-depth ERP
management of financial, and human resources and
experience and use of various project methodologies,
the supply chain [10]. Major business drivers behind
the primary author recognizes that several projects fail
ERP implementations are: improving productivity,
as a consequence of poor planning. This area requires
providing competitive advantage, and satisfying
significant attention.
customer demands [5].

Although ERP applications have been widely adopted

by a variety of industries worldwide, the challenges
2. Research Methodology
faced during and post-implementation remain a
growing concern. ERP systems are complex pieces of The methodology that was employed in this research
software [5]. Consequently, many such was based on the following:
implementations have been difficult, lengthy and over
budget, were terminated before completion, and failed  Information gathered on company-specific
to achieve their business objectives even a year after project methodologies, ERP
implementation [5]. Researchers and practitioners implementations, Accelerated SAP (ASAP)
alike are still in the process of studying and project methodology used in SAP R/3
understanding the causes of these hurdles. As part of projects and Work Breakdown Structures
this research, an in-depth literature review highlighted based on primary author’s ERP project
numerous project challenges. Based on the Risk experience.
Factors of ERP, one of the risks identified in project  Literature review on ASAP
management and control, is a lack of effective project
management methodology [4]. However, very little is
mentioned about ERP project planning methodologies

Communications of the
IBIMA
2 A Work Breakdown Structure for Implementing and Costing an ERP Project

 Identifying project activities that are system, an overall test, and the release of the
excluded from ASAP based on knowledge of system for live operation.
company-specific project methodologies.  Final preparation – the purpose of this
 Using a WBS to amalgamate the identified phase is to complete the final preparation,
project activities with the ASAP project including testing, end user training, system
activities management and cutover activities. The final
 Based on literature review of ERP challenges preparation phase also serves to resolve all
and previous case study, identifying open issues.
challenges associated with each project  Go live and support – the purpose of this
activity in the WBS. phase is to move from a pre-production
environment to live operation. A support
organization must be set up for end users to
3. ASAP Project Methodology provide long-term support. This phase is also
used to monitor system transactions and to
SAP introduced the ASAP implementation
improve overall system performance.
methodology with the goal of speeding up SAP
Finally, the completed project is closed.
implementation projects [9]. ASAP
implementation is a structured implementation Each phase is composed of a group of work packages
approach that can help managers achieve a faster [9]. These work packages are structured in activities,
implementation with quicker user acceptance, and each activity is composed of a group of tasks [9].
well-defined roadmaps, and efficient For each task, a definition, a set of procedures, results
documentation at various phases [9]. The ASAP and roles are provided in the ASAP methodology
methodology phases are [9]: documentation [9]. Implementations where ASAP or
Powered by SAP methodologies were used averaged
 Project preparation – the purpose of this only 8 months, compared to 15 months for standard
phase is to provide initial planning and implementations [9].
preparation of the SAP project. The steps of
this phase help identify and plan the primary
focus areas to be considered such as: 4. Work Breakdown Structure for ERP
objectives, scope, plan and definition of Implementation
project team. The outcome is the project
charter. A complex project is made manageable by first
 Business blueprint – the purpose of this breaking it into individual components in a
phase is to create the business blueprint, hierarchical structure, known as Work Breakdown
which is a detailed documentation of the Structure [13]. Such a structure defines tasks that can
organizational structure and business be completed independently of other tasks, facilitating
processes gathered during requirements resource allocation, assignment of responsibilities, and
workshops/meetings. It will allow the measurement and control of the project [13].
implementation project team to clearly define
their scope, and only focus on the SAP This section depicts the use of a WBS in Figures 1, 1a
processes needed to run the organization and 1b to plan an ERP project. The various levels in
business. the WBS are illustrated in Table 1.
 Realisation – the purpose of this phase is to
actually configure SAP R/3 based on the
specifications of the business blueprint as
well as taking further input into account
(Questions and Answer database). The
objective is the final configuration of the

Communications of the
IBIMA
Aisha Momoh,Rajkumar Roy and Essam 3

Fig 1. WBS for ERP Implementation

Communications of the
IBIMA
4 A Work Breakdown Structure for Implementing and Costing an ERP Project

Fig 1a. WBS for ERP Implementation

Communications of the
IBIMA
 Aisha Momoh,Rajkumar Roy and Essam 5

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
6 A Work Breakdown Structure for Implementing and Costing an ERP Project

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
 Aisha Momoh,Rajkumar Roy and Essam 7

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
8 A Work Breakdown Structure for Implementing and Costing an ERP Project

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
 Aisha Momoh,Rajkumar Roy and Essam 9

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
[3] Labuschagne, C., Brent, A.C. “Sustainable Project Structure. Retrieved June 7,
Life Cycle Management: the Need to Integrate Life 2008,
Cycles in the Manufacturing Sector”, International from:
Journal of Project Management (23), 2005, pp. 159-
168. //www.netmba.com/operations/project/wbs/

[4] Huang, S., Chang, I., Li, S., Lin, M. “Assessing [14] Tausworthe, R.C. The Work Breakdown
Risk in ERP Projects: Identify and Prioritize the Structure in Software Project Management.
Factors”, Industrial Management & Data Systems Retrieved June 8, 2008,
(104:8), 2004, pp. 681-688. from://md1.csa.com/partners/viewrecord.php?requeste
r=gs&collection=TRD&recid=A8133550AH&q=Wor
[5] Somers, T.M., Nelson, K.G. “A Taxonomy of k+Breakdown+Structure+Tausworthe&uid=79289263
Players and Activities Across the ERP Project Life 1&setcookie=yes
Cycle”, Information and Management (41), 2004, pp.
257-278.

Communications of the
IBIMA
10 A Work Breakdown Structure for Implementing and Costing an ERP Project

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

Communications of the
IBIMA