Cultural challenges involved when applying PMBOK concepts to enterprise resource planning (ERP) projects in Latin America
Global Risk Management, Oracle Corporation
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.
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.
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 Oracle Corporation's 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.
Exhibit 1 – Why the ERP projects falter
Exhibit 2 – Why the ERP projects falter
Exhibit 3 – Why the ERP projects falter
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:
Exhibit 4 – The Change Curve
Exhibit 5 – The Willingness to Change
“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.
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.
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.
Project Healthcheck Satisfaction Survey, from Oracle Corporation's Risk Management group, North America (2001, May)
© 2005, Antônio Amaral Júnior
Originally published as a part of 2005 PMI Global Congress Proceedings – Panama City, Panama