Table of contents:
Revving your engines: Tuning up your ERP project plan
Part 2: Maintaining your place in the race -- ERP project management
Part 3: The final ERP transition: Crossing the finish line successfully
A quick search of CIO magazine's website turns up more than 200 entries for the term "Project Plan" and even more for "Project Success" and "ERP Project." Many of these articles point out that "scope creep" and the failure to assess customers' real requirements are the biggest reasons projects fail. Other articles focused on selling users a particular tool for project management. A recent blog asserts that ERP project success may be defined as completion, regardless of the ROI or performance improvements which may or may not have been achieved. There are more than a few legendary ERP project failures, so how can we mere mortals hope to build successful projects?
In a series of three articles, we hope to show you just that by examining specific practices designed to lead to successful ERP projects. Part One, entitled "Revving your engines: Tuning up your ERP project plan," looks at some of the things to consider when getting started.
Not that I know a lot about Formula One cars, but it seems to me there's a reason racers maintain teams of superb mechanics. These experts know every nuance of their car's engine; the sound, vibrations, even the smell of the car as it careens around a track. They've spent time building their knowledge.
Initial ERP project planning requires the same kind of dedication. Considering that each ERP project has its own goals, environment and challenges, each project will have a different look and feel, although each should go through the same planning steps. These ERP project planning steps apply to both in-house efforts and projects using contractors. I have not included tips on selecting contractors, although companies should be wary of the lowest-cost contractor or contractors whose first response is to customize code or applications.
In a recent survey of ERP implementation, participants across many projects revealed the following insights:
Critical Success Factors
- 22% cited accurate requirements definition as a primary factor in success or failure.
- 16% cited upfront project planning.
- 16% cited Project Stakeholder commitment and alignment.
- 16% indicated Subject Matter Expert involvement.
- 13% identified and detailed the AS-IS processes as well as the TO-BE processes.
The successful ERP project plan must address these issues; you can classify them in three major categories:
- Defining the overall structure of the ERP project
- Designation of project staff and interrelationships
- Definition of major challenges, risk factors and high-level requirements
The ERP project plan identifies standards to be used throughout the project, such as project phases, high-level milestones, and strategic policy and goals. An ERP project plan is collaborative. First, there is too much detail for a single person to do it all. (See the Project Startup Checklist and the example Project Plan Outline.) Second, in order to identify possible risks and challenges, you need to include both stakeholders and SME or project leads for the specific applications.
During this effort, you will be building critical relationships with your customers, as well as developing their trust. While the project plan will not actually develop the AS-IS or TO-BE process analysis, it will identify when these tasks will be performed. Some projects, in order to "save time," determine that AS-IS processes are not sufficiently important. This has always seemed to me to be a false savings. The AS-IS process is important for identifying business rules that are not readily apparent, as well as customizations that may not have been recorded.
For Oracle's E-Business Release 12 (R12) implementations or upgrades, there are specific areas of concern. First, R12 supporting "Global Business" has introduced considerable changes to the technical infrastructure. In General Ledger (GL) alone there are 36 new tables, 14 changed tables and 40 obsolete tables. These result from R12's change from Set of Books (SOB) to Ledger Sets and Sub-Ledger Accounting.
Additional functional changes such as Multi-Org Access features and Trading Community Architecture (TCA) changes to incorporate Suppliers/Vendors have resulted in significant table changes. From the supply-chain side, Inventory Convergence (the combination of process and discrete inventory) adds more technical infrastructure change. For this reason, existing customizations will need to be examined thoroughly to determine changed/obsolete dependencies. Considerable risk exists with regard to custom reports, or with business intelligence warehouses. Technical challenges aside, stakeholders and users need to be prepared for process changes; history has shown that existing customizations can be made obsolete by new, standard functionality. In order to assess the level of risk, your IT team will need to work with Subject Matter Experts (SMEs) to identify the level of customization and identify reports which will need to be changed. In this case, you are assessing the level of effort that will be needed as well as working to set customer expectations.
Another critical area to consider is the level of documentation to be required for the project. In the ERP project plan, identify all required documentation. You should create a documentation plan and assign an administrator/controller of that plan whose responsibility is to ensure that documents comply with expected standards and a common look-and-feel or standard format and are completed and internally reviewed and approved on schedule. An example Documentation Index is given.
Risks identified during the ERP project initiation phase should be recorded in a Risk and Issue Log, which should be maintained throughout the project, along with a summary shown in the project plan. Don't forget to assess the amount of testing or how much training individuals may need. Your SMEs may need to be trained in R12's new functionality in order to help determine optimal setups; users who participate in Conference Room Pilots (CRPs) or testing will also need training. See these examples of a Risk Management Checklist as well as the sample Risk and Issue Log.
Depending on the overall scope of your project, your planning phase may take considerable time. The Project Plan outline example associates a series of 40+ tasks within four sections. The fourth section includes project kick-off and represents ongoing project plan activities throughout the project lifecycle. While written from the subcontracted project manager point of view, the tasks are equally applicable to an in-house effort. In-house efforts may require additional training time for potential project leads in R12 applications and differences. Because you will be leading and attending many meetings during this project initiation phase, I have included a copy of my preferred project meeting notes format.
Recommended Reading for Requirements Analysis:
- Getting It Right: Business Requirement Analysis Tools and Techniques. Kathleen B, Hass, PMP, Don Wessels PMP, and Kevin Brennan, PMP, Management Concepts, 2008
- Mastering the Requirements Process (Second Edition), Suzanne Robertson and James Robertson, Pearson Education, 2006
- Unearthing Business Requirements, Elicitation Tools and Techniques, Rosemary Hossenlopp, PMP and Kathleen B Haas, PMP, Management Concepts, 2008
About the author: Carol Francum has more than 20 years of global experience in IT, including quality and systems engineering, project management, and ERP business consulting. As a business analyst, she synchronizes and aligns applications and technology to meet customer needs. Carol has recently been named Sales Director for Ashford Global IT, providing "The Best in IT Training", and specializing in ITIL, Security and other business training. Carol can be reached at carol@AshfordGlobalIT.com