Table of contents:
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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
In Part 1: Revving your engines, we identified a list of recognized critical success factors for ERP projects. Primary ERP success factors included accurate requirement definition, good project planning, stakeholder commitment, user involvement, and detailed processes. In Part 2, we developed guidelines for maintaining consistent progress in ERP project management. However, the most important factor in working on an ERP project is its successful completion and delivery.
This final ERP transition includes various functional and integration testing, user acceptance testing, deployment and, usually, a period of support for the newly deployed system. It will also generally include a period of performance tuning to establish performance metrics for the ongoing system management.
Now let's make some basic assumptions. To get our project "racecar" well on track, we carefully used integrated teams of ERP implementation experts and user experts. We detailed both "AS-IS" and "TO-BE" processes and workflows in order to fully understand business requirements, and we documented all the business and user requirements. We also identified related risks and issues, mitigated or solved them, and included our stakeholders and critical users in the decision-making process to ensure both the right decisions and customer buy-in.
During development, we stayed on track by working closely with users on data conversion and verification of applicable business rules, as well as actively involving them with evaluating whether solutions would meet their needs. During the development phase, application setups were performed, documented and adjusted as necessary to provide the appropriate solutions. Similarly, the project DBAs and other technical personnel reviewed and performed application, server and database patching as necessary and developed (and documented) custom solutions, or Oracle extensions. It is imperative this information be kept up to date and accurate, so the preparation of the production environment can go smoothly and the user community can be readied for transition.
To bring the project to a successful conclusion, we need to verify that our results meet user requirements. They should meet both the form and function the users and stakeholders expect in order to switch control of the applications and environment to the business users and prepare them to take on the regular maintenance of their environment. I have included some templates for the tasks involved in this section. See "Project Transition and Closeout Activities."
The user community needs to participate in planning Acceptance Tests. This includes what the tests will cover and the data to be used for the test. Data preparation for testing will probably use filters to the data conversion scripts in order to provide the appropriate types of data, but not the full volume of production data. The tests should cover each type of transaction for the particular application. During the test preparation time, the project requirements should be compared with the testing to ensure that all requirements are suitably covered. Your Software Quality Assurance personnel can provide some metric guidance as to the number of data points to be covered. In addition, the test script should include a Pass/Fail column, Actual Results column, and a Comments column to allow for explanation of any questionable behavior or problems.
Trying to achieve a successful test with untrained testers is like trying to win the Indy 500 with flat tires. Prior to initiating Acceptance Tests, user testers should receive hands-on training for the application in order to familiarize them with functionality. Be sure to define the user acceptance test criteria. The details of what constitutes test failure will differ in relation to the organization's tolerance for problems and issues. For example:
- For a test that has 15 scenarios, how many individual step failures are acceptable?
- If a message appears but is not exactly as expected, is it treated as a failure or as a show-stopper? (Clearly, message failures should generally be treated as minor anomalies and easily remedied.)
- Are there some test cases that are critical for success and others that are not?
- If a custom report has fields out of order but all fields present, does the whole test fail or simply the report? Consider having a test summary meeting each day to identify issues that may have occurred, to make a preliminary assessment of any issue, and to decide what additional actions will be taken.
Once your user acceptance tests have been completed and any regression testing performed, a final report of the testing accomplishments should be completed. This report, probably designated as a deliverable at the outset of the project, provides the basis of project acceptance by the appropriate stakeholders or signatory authority.
The date for cutover to the new production system must be selected carefully. The end of the month or year is a critical, tense time. Overlaying that with a new system for users creates significant additional pressure. The wise transition manager will consider the potential for the need to fall back to the "old" system. Consider carefully the significance of the failure of the system at a financially important time. If a particular area of the system does not work as anticipated, are there additional risks to the corporation's customer base? How will you deal with this?
I have seen a number of "good" ERP transitions, but I have never seen a major implementation that executed without a single hitch. This is when the good relationship you have maintained with your users and stakeholders really makes a difference. Users who have worked along with the project team are more likely to view problems as an opportunity to shake out the last few bugs, rather than as a show-stopper. Typically, there will be a transition period where (hopefully minor) problems will be fixed. In addition, during the ERP transition period, technicians may be able to perform some additional applications, database or performance tuning to produce a set of formal baselines, which allow performance comparisons over time.
Lastly, a good practice is to perform a "lessons learned" review, as well as a user-stakeholder review to determine whether the users/stakeholders were as pleased with the final outcome as you were. These should be recorded and included with the final documentation. The Project Assessment Review gives a set of questions you may want to pose to users, to help gauge user reactions to the project and the project team. These questions will need to be tailored to your particular project.
Having completed the ERP project race, you can now ready yourself for the next one.
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