The way a business manages risk says a lot about the internal culture. There are companies that prefer to pretend that the risk does not exist. They rarely discuss risks, they don’t have risk mitigation strategies in place, and overall they treat the discussion of risks as a sign of weaknesses. In such an environment, employees are not encouraged to express concern about the possible failure of the task or project. In some extreme examples, even when staff members realize they are going in the wrong direction, they still stay the course. During this time, managers are either unconvinced that there is a problem or remain in the dark about the problems.
When the consultant identifies the potential risks of the project during the investigation and brings them to the attention of the client, the client team often ignores the risks, insisting that it is not serious, and therefore does not not taking the time to work properly on the mitigation strategy. Regarding the risks associated with the resistance of the client’s staff to changes during the implementation of a new ERP, it generally looks like this: “We are not going to worry about improving the willingness and efficiency of the team working on this project; We don’t think we have to spend our time convincing our employees how important this project is to our business. When the time comes, we will solve everything with executive action and bring us into compliance within the agreed timeframe.
Often, consultants try to do everything in their power to mitigate the negative consequences of the risks of their end of the project. In particular, they develop various KPIs and exception reports, run them regularly and analyze the results. The monitoring of KPIs and various risk statuses gives those responsible for the implementation of additional measures of the health of the project and of the risk factors which are still exceptional. It also provides a timely warning system, to notify the client of risks that have actually materialized and require immediate attention now.
Types of risks in ERP implementation
There are 5 typical risks involved in ERP implementation projects:
Changes in requirements (creep in scope);
Changes in the composition of the project team;
Low productivity at all stages (collection of needs, development, user acceptance tests, approval of documents, etc.);
Client employees who refuse to work under the changed processes and sabotage the new procedures in small but significant ways.
Risk of sabotage by the client’s team
The most common challenge is sabotage by the client’s team. This results in breaking the system by taking the wrong steps or actions or not doing the right ones. Most automated systems require their users to perform very specific activities in terms of task synchronization or data collection:
Enter or scan only invoice numbers and nothing else;
When you drive a forklift through the RFID barrier, stop in red and only drive in green
Apply a barcode label to each box received
Generate purchase orders based on replenishment reports
However, no system can automate absolutely everything, and users have a lot to deal with. A person who does not want to work in the new system aims to prove that the system is bad. This person will have many opportunities to imitate the incorrect operation of the system by entering incorrect or invalid data, performing out of order tasks, etc.
The more the users of the system are in a state of indecision, indifference, frustration or outright sabotage, the less likely the project will become a success. And of course, the worst-case scenario would be when the person in charge of implementing the project on the client side disagrees with that project. While this never happens to me personally, we all hear stories from colleagues at ERP conventions and summits. And it seems like this kind of situation happens from time to time. From time to time, the individual, who is appointed on the client side as the head of the project, is not convinced that this is necessary or sees the new system as a threat to his own position within the company. When this happens, I am convinced that the chances of successful implementation would be low, if not zero.
Risk of low productivity
This risk can take various forms, both on the client side and on the consultant side. On the customer side, for example, collecting requirements takes longer because not all stakeholders can be present for collecting requirements or cannot agree on a solution that will satisfy all stakeholders. . Or the document signing step may be blocked, due to the availability of resources. UAT tests are often delayed or slow, or both, due to understaffing in the department or an increased amount of regular work to process.
On the contractor side, there may be delays due to staff availability or perhaps the cascading delays cause the development team to complete tasks out of order. To eliminate these risks and ensure that development does not wait for action from the client side, the project manager works daily with team members and sets sprints to achieve full workload and speed. optimal delivery. The results are evaluated by quality criteria and by means of test cases.
Risk of changes in the composition of the project team
This next risk lies in changes in the structure of the project team. People take sick leave, quit, or quit projects for other reasons. Until a new team member is recruited, the project slows down or even stops. The negative consequences of this challenge are mitigated by copiously recording the progress of the team, so that the new employee spends as little time as possible entering the information field of the project. On the customer side, this means that all business processes must be carefully documented and staff training sessions are recorded in video format to simplify future training.
Risk of planning errors
Consider the following example. The implementation team expected the warehouse equipment to arrive within two weeks, but due to the pandemic, it took two months instead. The plan was based on an optimistic vision and now the situation has to be managed by the project manager. The mitigation strategy may be to change work on other implementation areas until warehouse equipment is delivered.
Planning errors don’t just happen because of a pandemic, they can come from much more benign things. For example, the parties did not clearly specify the time of vacation of the client’s employees. Planning errors can also lead to cascading delays – due to the time it took to agree on requirements, it looks like module delivery will now occur 3 weeks later – this will push UAT to start at the start of the busy season, further delaying the project for another 3-4 weeks.
To avoid planning errors, all project participants should engage in proactive scheduling control.
Risk of changing requirements
When new requirements arise during the work, the risk of extending the project limits arises. At the start of the project, clients normally do not have complete knowledge of all of the business processes that will be affected. ERPs are implemented in large companies, and at such a scale, certain details are often overlooked.
Enterprise resource planning systems are complex, large, and mission critical. New ERP implementation projects require careful planning, risk analysis and risk mitigation development. ERP implementation in general and ERP automation projects specifically bring additional levels of complexity and often lead to the discovery of unforeseen aspects of the project. Cascading delays can really hurt the project schedule and make a successful project delivery look like a complete failure.
Risk management on ERP implementation is not optional, but rather an essential part of the project that is there to ensure that the implementation is seen as a success. Remember that the client’s refusal to recognize the risks does not exclude the possibility of their occurrence.
About the Author
Greg is President of FiduciaSoft, the company he founded in 2015. As a provider of custom software development services, FiduciaSoft helps small and medium businesses stay current. Prior to founding his company, Greg worked in logistics, manufacturing and retail as an IT consultant for over a decade and a half.