It has been said that implementing an ERP system is like performing open heart surgery on a company. The project is complex and rife with foreseeable and unforeseen risks. The risks are ever present within the lifecycle of the project and should not be ignored. Recognizing and considering how to address these risks is often overlooked or minimized and can result in delays, cost overruns, and organizational upset. Furthermore, as the project evolves and changes occur in the scope and timing, new risks can arise and previously identified risks may shift in severity or likelihood.
Therefore, incorporating risk management into your ERP project is a recommended best practice. Consider that an effective project incorporates the following elements:
- Scope and Vision
- Essential Success Factors
- Roles and Responsibilities
- Change Management
- Project Control and Procedures
Although the last item on the list, acknowledging that risks exist, developing mitigation strategies, and encouraging risk assessment throughout the life of the project are critical elements to an effective risk management process and successful implementation.
If risk management is so important to success, why is it overlooked or minimized? It may be due to lack of expertise with risk identification, assessment, and mitigation. It is human nature to be optimistic, and it may even be viewed within an organization as counterproductive to dwell on what can go wrong. The most effective project leaders, however, will confront this at the project inception and build a protocol and a culture to explicitly review risks throughout the project lifetime.
To quote Benjamin Franklin—“By failing to prepare, you are preparing to fail.”
What is Risk Management?
So, what are these risks that we refer to above? They are events, factors, or actions that can negatively affect the success of an ERP implementation. They maybe foreseeable, e.g., there may be bad data buried within the legacy database in which case we recommend some testing to determine its magnitude. Or it could be unforeseeable, e.g., a key project team member is no longer available due to illness or a new opportunity. Some may seem highly unlikely, but it is best to identify and categorize these as part of the process.
Risks can be grouped within the following four categories:
Environmental risks could include the economy, regulations, competition—they are largely external factors that may affect the project. E.g., if there is a regulatory requirement that can affect the business function, has that been considered as part of the system requirements?
Resource risks include organizational structure, governance, people, partners and stakeholders. E.g., if there is a subcontractor involved, what would happen if the contractor could not deliver?
Process risks are the most familiar and relate to governance, development, and deployment. E.g., what if a project sponsor departs the company, what if there is a cost overrun? What if the project is delayed—might part of the system be deployed?
Technical risks are also more obvious. E.g., what if a key piece of technology is unavailable or not reliable? What if there is a security breach?
It is very useful to establish a process for identifying and managing risks for the project and with the involvement of the project team. The process would include the following steps:
- Identification of risks
- Assessment—by severity and likelihood
- Mitigation—plans to reduce or respond
Identification of risks begins with a list of all possible risks, both from public sources and from internal discussions. No matter how unlikely, list them all as during the assessment process the team can determine importance.
Categorization of risks into the four categories (environmental, resources, functional, and technical) will allow for delegation of responsibility for assessment, mitigation and monitoring. A risk register is a tool used to list and categorize all identified risks. A project team may start with an available base list from previous projects or a trusted, outside consultancy. Here is a sample of a risk register for environmental risks from OnActuate’s risk template library:
|Risk Category||Risk Description and Consequence (if/then)||Phase When Risk Typically Occurs||Trigger Event Indicator|
|Environment||Availability/responsiveness of customer in providing documentation||Analysis|
|Environment||Dependence on other projects or systems||–|
|Environment||Availability, commitment, and knowledge of user community||Analysis|
|Environment||Availability, commitment, and knowledge of key users (including System Administrator)||Analysis|
|Environment||Availability, commitment, and knowledge of IT staff||Analysis|
|Environment||Strength of customer sponsorship, management commitment, and leadership||–|
|Environment||Flexibility, commitment, and a generally supportive political environment||–|
|Environment||Logistical complexity of the relationship (part-time resources, split projects, travel, etc.)||–|
Assessment of risks should consider both the severity of the risk and the likelihood. It is okay to agree to the definition of the ratings. E.g., ‘high’ severity might mean the project could be delayed by weeks or result in 20%+ additional costs. Likelihood is the probability of the occurrence and again should be well defined. More sophisticated methods might include scoring of risks through a combination of severity and likelihood. In the example matrix (below), ‘high’ severity is scored as 3 on a 1 to 3 scale and ‘very likely’ is scored a 3 on the same scale, the product yielding the highest possible risk score of 9.
|Likelihood||High – 3||Medium – 2||Low – 1|
|Very – 3||9||6||3|
|Somewhat – 2||6||4||2|
|Rare – 1||3||2||1|
Mitigation plans or protocols should be developed for the highest impact risks. These may include scenario plans, dry runs/simulations, cross training of key people, identification of alternative partners identified agreed upon, and documented and approved management.
As the project gets underway and regular project meetings take place, risk reviews should be incorporated within these meetings. The purpose is to understand what has changed and how these changes may affect the project goals. New risks may also be identified and these should be incorporated into the overall project through the change management process. It is a best practice for each risk to be owned by someone, or at least by a group with a role in the project. The owner, or group of owners, will be responsible for updating the risk status, developing mitigation activities, and preparing and reporting on progress.
What Good Risk Management Looks Like
An effective risk management function within the ERP implementation project includes:
- Risk register—at the project initiation and ongoing updates with a weekly review for accuracy
- Budget to actual and projected budget to actual reports—for both costs and timeline with weekly reviews
- Procedure for capturing new or revised risks and passing to the change management process
- Periodic internal audits to confirm accuracy and timeliness
Incorporation of risk management within the overall project management function should be ongoing and not an episode. If the organization has limited experience establishing risk management within a project, it may benefit from external assistance. Establishing a culture and process for identifying and assessing risks is core to maximizing the overall project success, as measured by costs, timing and end user satisfaction.
Contact us for more information about how OnActuate can support your Microsoft Dynamics ERP implementation and mitigate risks.