Cultural challenges involved when applying PMBOK concepts to Enterprise Resource

Planning (ERP) projects in Latin America

Antônio Amaral Júnior
Global Risk Management, Oracle Corporation

Abstract

Information Technology is one of the areas with the greatest increasing demands for Professional Project
Management services. Implementation of ERP software falls into this category – but it is not limited to the
traditional aspects of Information Technology projects. The Critical Success Factors for most of the ERP
implementation projects include (but are not limited to): a business sponsor; willingness to overcome the resistance
to change and shift from the old business processes to the business practices embedded in ERP software; motivated
and engaged end users participating in the project activities; a well defined scope and a firm commitment from the
customer and from the vendor to the original scope; tight management of scope changes (which should be minimal);
agreement on a project deliverable’s acceptance process; and the minimization of software customizations and
extensions.

Introduction

Differently from the past, when technicians developed most of the Information Technology projects (often with
limited end user participation), the current ‘new age’ of implementing those projects is based on the shift, from in-
house developed systems to the acquisition of packaged software products with the best practices embedded. This
shift requires changing the implementation methodology and attitude/participation of end users and Information
Technology professionals. However, this shift, combined with the natural human resistance to change and with the
expectations created by the ‘one size fits all’ ERP philosophy, poses several challenges to the project team – and
Project Management disciplines are imperative for the project success (although, at the same time, many consider
those disciplines as inflexible or bureaucracy).

The main challenges usually found in the ERP projects are: a) having a business oriented sponsorship, who belongs
to the functional area(s) which will invest in the project and will achieve the benefits related to its implementation,
in addition to Information Technology managers; b) balancing the disciplines contained in the PMBOK with the
natural creativeness of Latin American people; c) overcoming the resistances to change usually present among ERP
software end users; d) engaging (and involving) end users during the project activities, succeeding to release them
from their daily/routine job activities; e) facing the difficulties to precisely define project scope in this type of
project/industry; f) meeting customer’s expectations regarding contract types under the circumstances of such
project (an usual expectation is a Fixed Price contract without clearly defined scope); g) managing scope changes
and finding the ways to formalize them in advance; h) implementing a formal project deliverable’s acceptance
process, based on previously defined criteria; i) minimizing the design and build of software customizations and
extensions, which are ‘politically incorrect’ at the project beginning but almost inevitable as the project progresses
towards its completion.

Why do ERP implementation projects falter?

Revealing the real reasons

A frequent thought among many ERP professionals (project managers, sales persons, consultants, technical analysts,
developers) and end users (customer executives, project managers, business analysts, etc.) is that ERP
implementation projects are merely Information Technology projects therefore software and hardware issues are the
only ones that really matter.

Oracle Corporation’s Risk Management group has been finding a different reality after reviewing thousands of
projects throughout the globe. Although technical aspects do have strong relevance, most of the reasons behind
projects’ failures are related to project management and human relations issues.

© 2004, Antônio Amaral Júnior 1

Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires, Argentina
A Quantitative Perspective of the Problem

The Risk Management group assesses the health of Oracle ERP implementation projects through a number of
project reviews known as Project Healthchecks. A Project Healthcheck is an independent assessment of a project’s
health, performed by the Risk Management group, which emphasis is on risk identification and mitigation, in order
to:

1) Identify risks,
2) Recommend actions,
3) Assess the project relationships,
4) Evaluate the financial status,
5) Evaluate performance of project management procedures,
6) Assess whether plans are suitable to achieving objectives.

The following Exhibits (1-3) were excerpted from a Project Healthcheck Satisfaction Survey conducted by the Risk
Management group in North America. Although the sample of projects contained in the survey (40) does not contain
Latin American projects, we firmly believe the issues found in the USA would be fully valid for Latin America.

Top 9 reasons that ERP projects falter

• Failure to manage and match customer and vendor

expectations
• Badly defined and managed scope
• Lack of sponsorship
• Product issues
• Poor change control
• Lack of resources and/or skills
• Inappropriate staffing during early weeks
• Limited focus of vendor’s consultants
• Lack of vendor’s executive involvement with customer
strategic planners

Exhibit 1 – Why the ERP projects falter

© 2004, Antônio Amaral Júnior 2

Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires, Argentina
 But Many Other Issues Exist

red indicates a Project Management issue

Number Issue
of
mentions
19 client resource constraints/gaps
poor team communications
14 scope creep/change control
12 hardware/software environment and management
product stability/maturity/performance
11 aggressive or unrealistic schedule
10 client skill gaps
expectations mis-set or not aligned
9 lack of ownership/decision making
8 vendor resource timing
weak project plan/work plan
7 data integrity concerns
multiple players
vendor skills gap
6 lack of shared vision
poor/incomplete requirements definition
weak project management

(continued)

Exhibit 2 – Why the ERP projects falter

But Many Other Issues Exist

red indicates a Project Management issue

Number Issue
of
mentions
5 budget issues
education issues (timing, quality, availability, time sufficiency)
low/no contingency
vendor resource constraints/gaps
poor team relationships
post-production readiness
4 project roles & responsibilities unclear
payment delays
product functionality
production readiness
3 contention with/dependencies on other projects
inconsistent processes (risk of things falling through cracks)
lack of sponsorship
missing/inadequate documentation
2 inadequate testing
ineffective software controls for Production environment
internal client conflicts
lack of source systems/data
vendor management team disunited or unsupportive
poor external communications
1 deliverables format and level of detail
poor initial proposal quality

Exhibit 3 – Why the ERP projects falter

© 2004, Antônio Amaral Júnior 3

Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires, Argentina
The conclusion is: it is time to be concerned about project management!!

It is interesting to notice that technical problems represent 1 out of the 9 top reasons why ERP projects may falter
(Exhibit 1). All other 8 top reasons touch at least one knowledge area of PMBOK such as:

1) Integration Management
2) Scope Management
3) Human Resource Management
4) Communications Management
5) Professional Responsibility

Exhibits 2 and 3 provide a greater level of detail of the assessment. The interviewees mentioned 39 reasons for
project failures. Among the total number of mentions in the survey (243), 187 or 77% revealed to be related to at
least one of the following PMBOK knowledge areas:

1) Integration Management
2) Scope Management
3) Time Management
4) Cost Management
5) Quality Management
6) Human Resource Management
7) Communications Management
8) Risk Management
9) Professional Responsibility

It comes the time for the Latin American flavor

The context described in the previous sections is perfectly applicable in Latin America ERP projects. However, it
gets here some specific features, often perceived during the Project Healthchecks performed by the Risk
Management group in Latin America.

No Executive Steering Committees

Unfortunately, this is a quite common situation. Either vendors/consultants are not effective to persuade the
customer about the importance of establishing a Steering Committee or top management acts negligently regarding
this opportunity to be aware about the project progress, to provide support and to make the decisions required:

“I am not interested about it”;

“It is going to be another boring technical meeting. I will defer it to the IT guys”;
“I am too busy. I have to run/manage my business. I do not have time for one more meeting”;
“I am pretty confident it is going to be a successful project – so this meeting is not necessary”.

“I am willing to change. I do not resist to changes – just if they are going to change someone else’s
life”.

Most human beings like their shelters. They rather stay in their comfort zones. They are used to their offices, their
reports, and their screens – the current ways to do their jobs.

Many end users feel excited about ERP projects – but only it they fulfill their greatest desire, or “the ERP will do
everything the current system does – and more”. However, both ERP vendors and customer people in charge of
selecting and/or acquiring the ERP seldom share this mindset – actually, an ERP implementation should promote
greater integration within the customer and leverage benefits for the business, which normally changes the way end
users work before the ERP implementation. The following exhibits illustrate the change phenomena in ERP
projects:

© 2004, Antônio Amaral Júnior 4

Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires, Argentina
 The Change Curve

Go Live
Legacy New
Environment Environment

P1

P1 - Productivity Should
User & Rebound to Higher Levels
Organization
Productivity

D1 D1 - An Initial Drop in Productivity Is Expected

Time

Exhibit 4 – The Change Curve

The Willingness to Change

“As Is”
Business Processes
NEW ERP
and Systems

Enthusiasm
&
Commitment
Reduce Commitment Increase Commitment
to Present Business to Future Business
Processes and Systems Processes and Systems

Time

Exhibit 5 – The Willingness to Change

© 2004, Antônio Amaral Júnior 5

Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires, Argentina
“I am to busy to work in this project”.

Projects can quickly become a nightmare for end users. Their daily jobs are normally based on going activities – or
processes. A project can disturb an end user’s life, as it contains an inherent level of discipline and commitment (“a
project is a temporary endeavor undertaken to create a unique product or service”), which he/she is not used to.

Another fact that magnifies this situation: the end users often receive an “extra job” when ERP projects are
implemented. They are supposed to work on their routine jobs and simultaneously they have to be part of the ERP
project team. Just under exceptional circumstances, the end user employers designate separated groups to work on
routine / operational tasks and to work in the ERP project. One can imagine the impact of a struggled user working
in a project.

What is the project scope?

The answer to this question depends on two variables: a) which altitude you are flying (3,000 or 30,000 feet); b) the
stage you are asking the question.

Both customer and vendor feel very excited when they are discussing a proposal to implement the ERP project.
Their trend is feeling satisfied as soon as possible to initiate the project (‘I do not want to waste time with planning,
let me go to execution and make things happen’). During this stage, the main players tend to be averse to details in
order to create an atmosphere of entrepreneurship.

The stakeholders from both sides (vendor and customer) described in the previous paragraph are normally flying on
an altitude of 30,000 feet. When the project manager is welcome on board, his/her natural instinct is to fly at a lower
altitude – and from this moment he/she can have some surprises if customer expectations were mis-set while people
were flying at a higher ground.

Defining scope is really a challenge in ERP projects (although it sounds obvious for many). My favorite situation: I
interviewed a Billing end user from ‘Meal Tickets company A’ (who came from ‘Meal Tickets company B’) and he
said that the Billing processes on those two companies are quite different!

IT/ERP industry can be considered ‘novice’ if compared to other ‘mature’ industries (such as Construction).
Therefore, a scope statement such as “Implement a standard billing system for a Meal Tickets company” is so vague
that it will create many problems to manage the project scope (although it looks like a nice scope statement for those
ones flying at 30,000 feet). It is a great challenge to define precisely the scope of an ERP implementation project –
and the trade-off between ‘starting the project quickly’ and ‘detailing the scope’ will generate an inevitable tension
among the stakeholders.

“I want a Fixed Price Contract”.

Time and Materials (T&M) contracts are becoming more and more unpopular among ERP customers in Latin
America (USA customers are more likely to accept T&M contracts than the Latin Americans). Although everyone
reminds the classic discussion about which is the riskiest contract for whom, the real problem is not the contract type
– but signing a Fixed Price contract at 30,000 feet!

“Change Request? I cannot stop the project because of insignificant details. I promise I will sign
this for you later. Let’s have the job done”.

Many people think in terms of scope changes as a separated thing. PMBOK chapter 4 (Project Integration
Management) can be forgotten (for lack of knowledge or for convenience). They may impact schedule, cost,
contracts, communications, and resources. A few stakeholders tend to be averse to accept formal written
commitments in the name of “flexibility” and “fast results”.

Deliverable Acceptance Criterion: to achieve perfection until a state of total customer happiness.

© 2004, Antônio Amaral Júnior 6

Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires, Argentina
Can a project like this be successful?

“Do my project have risks? I was not expecting project risks! Let’s call an urgent meeting with the
CEO”.

Stakeholders of ERP projects in Latin America consider the word ‘risk’ as a sin that should be avoided and
postponed at any cost. Although risks can represent either opportunities or threats, Latin American instinctively
recognize just the negative connotation of the word ‘risk’.

“This is going to be a zero-customizations project”.

This is the classic pitch during the 30,000 feet flights and the project ‘opening parties’ (known as project kick-offs).
As the project evolves from definition to analysis, design and construction, people use to forget what has been told
in the kick-off and the customizations and extensions to the software may arise crazily.

Some Recommendations

My assumption is that everyone attending this congress is a strong believer in the Project Manager profession. I
would like to make some useful recommendations for both customers and vendors:

1) Accept and endorse a discipline which embraces formal written communications. Act and provide example to
your teammates. Remove the word “bureaucracy” from your dictionary.
2) Always implement Steering Committee meetings. Schedule meetings once a month. Apply the good techniques to
plan and execute meetings. The persons who will seat in the Committee meetings should be designated according to
the project scope and to the expected level of decision-making. Have a sponsor!
3) Do not ‘squeeze’ your end users. Assign some end users to work exclusively in the ERP project (whenever it is
possible).
4) Communicate the project progress throughout the organization accordingly. Choose the most appropriated
communication media for each stakeholder. Encourage commitment to the project objectives.
5) Agree on changes before executing them. Do it formally in written, as suggested in recommendation #1.
6) Establish a reasonable timeframe to accept project deliverables. Modifications to a deliverable after its acceptance
period should be treated as a change request. Avoid subjective deliverable acceptance criteria (a good acceptance
criterion would be ‘Delivery of System Test Scripts used to test the configuration of the Configurator module, in
accordance with the accepted Applications Setup Document’).
7) Be receptive to the ‘phased bid’ approach. Signing a Fixed Price contract at 30,000 feet without a detailed scope
definition for the entire project (since initiation until post-production support) can undermine scope management
and can be a serious threat for both parties in the project. Phase 1 should cover Definition and Operation
Analysis/Functional Design stages; then phase 2 would encompass the Construction stage until Post-Production
Support (but with much better scope detail, including customizations and extensions sufficiently specified).
8) Do not cut project management time from your estimates. Do not think that just technicians, analysts, developers
and DBAs will complete the project. Define the project management structure for your project accordingly,
including program managers, project manager, project support specialists/PMOs, taking the time and size of the
project into consideration.
9) Have the Steering Committee (or a specific Change Control Board – CCB) to assess and approve the design and
development of customizations and extensions to a minimum possible extent.

References

Project Healthcheck Satisfaction Survey, from Risk Management Americas, Oracle Corporation. Elizabeth Johnson
and Mike Monaghan (2001, May)

© 2004, Antônio Amaral Júnior 7

Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires, Argentina
 This material has been reproduced with the permission of the copyright owner.
Unauthorized reproduction of this material is strictly prohibited. For permission to
reproduce this material, please contact PMI or any listed author.