Mitigating ERP Project Risk
Some projects fail. Many others exceed the budget, take too long, or deliver less functionality than the plans called for.
Beacon's number one job is to work with each customer to define and assess the specific risks for each customer project. Risks can and should be identified in the early days of a project. Project plans to mitigate risk, and anticipate other issues can hardly start too soon..
Many of our customers have sophisticated risk assessment and risk management processes and expertise. An ERP project has areas of risk and challenges unique to IT projects in general and additional risks specifically related to the complexities of ERP systems. The next step after organizing and developing a charter is to assess the possible risks,
Managing risk in ERP projects is not just preparing a document identifying areas to take a look at. It is important to identify risk; it is also important to constantly update and monitor identified risk areas and provide mechanisms for early mitigation. Consultants need to have the skills and perspective to lead the assessments with appropriate organization teams and levels.
A new ERP implementation is a once every decade or two activity - which means most customers lack in-house up-to-date, pertinent experience to identify and catalog the specific risks of an ERP project.
How will this specific project work out? New software, with this group of people, within this budget and time frame are just a few of the variables, Companies often underestimate risks, or see them later than they could. Strong internal project managers are best supported by experienced, detailed ERP advisers. The good ones see the whole project before it begins.
The Risk Danger Zone - Real Risk and Perceived Risk
The highest risk in an ERP project comes up front. Unfortunately, these project risks may not be perceived until later on. Another way of saying this is that projects that get off the tracks were never really on the tracks, or fell off the tracks well before the realization of project trouble. The danger zone illustrates the real risks of a project are all in the beginning.
Here's what we mean:
A Successful Project Strategy Phase Reduces Risk
The green line (above) represents costs over time. Early on in the project, few costs have accumulated and changes to define or refine the plan or strategy can be made without much remediation expense.
The red line indicates the level and timing of the real risk for a project. Dealt with and managed properly, real risk declines over the length of the project. Milestones are met, progress is measured and monitored.
The blue line represents the perceived risk of the project. Early on, there is time left, everybody'seems enthusiastic, and energized, Shortcuts or omissions up-front cause just-in-time issue remediation as they come up. By the mid-point of a project, most risks for a project should be under control.
Before the midpoint of a project, project sponsors should see examples of steps taken that mitigate and reduce real risk. This may happen early in a well defined project. Tests are passed, the converted data balances, configurations are reviewed, and milestones are met on time, in budget. Risk is monitored and squeezed out. Most customers still experience the gap of the Wake Up Zone, and the fear of impending deadlines start to take a toll.
If the first half of a project is done well, meeting goals and plans, the second half is mostly done too (Much work may be left, but very little risk remains). Good plans well executed drive successful projects.
Nearly all projects that fail actually fall apart in the early design days. Shortcuts, untested assumptions, lack of project rules and communication, or skipping training do not save much time, but they each add risk. Risk identified and managed late in a project incur greater cost and stress on the project.
A sound design and strategy considers risk and the project charter as heavily weighted input to validate the design for a system that meets needs and enables the business to gain confidence in the deployment. A solid system, built to handle on-going updates and changing markets is the achievable goal of every project.
Design, or an initial high level design, plans the necessary steps to define the Project, measuring the design against the charter. All aspects of the project are defined and scheduled up front—detailed configuration and training plans, detailed unit and system testing plans, integration, conversion, and project communication. Once everything is thought out, decided, agreed upon and assigned, configuration can begin.