How a company handles risks says a lot about internal culture. There are those businesses that prefer to pretend risk does not exist. They rarely discuss risks, they do not have risk mitigation strategies in place, and overall they treat discussion of risks as a sign of weaknesses. Within such an environment employees are not encouraged to express their concern about the possible failure of the task or a project. In some extreme exemples, even when staff members realize that they are heading in the wrong direction, they keep the course anyway. Managers meanwhile are either not convinced that there is an issue or remain in the dark about the problems.

When the consultant identifies potential risks of the project during the survey and brings them to the attention of the client, the client’s team often ignores the risks, insisting that it’s not a big deal, and as a result does not take time to properly work on mitigation strategy. When it comes to the risks associated with client’s staff being resistant to changes when implementing a new ERP, this usually goes like this: “We’re not going to worry about improving the team’s willingness and effectiveness to work on this project; We don't think we need to spend our time convincing our employees how important this project is for our business. When the time comes- we will solve everything by executive action and achieve compliance by the agreed deadline.”

Often, the consultants try to do whatever they can to mitigate the negative consequences of the risks from their end of the project. In particular, they develop various KPI and exception reports, regularly execute them and analyze the results. Monitoring KPI’s and various risk statuses gives implementers additional measures of project health and yet-outstanding risk factors. It also provides a timely warning system, to notify the client about the risks that actually did materialize and require immediate attention now.

Types of risks in ERP implementation

There are 5 typical risks involved in ERP implementation projects:

Scheduling mistakes;
Changes in requirements (scope creep);
Changes in project team composition;
Low productivity at all stages (requirements gathering, development, user acceptance testing, document approval, etc);

The client’s employees that refuse to work within the changed processes and sabotage new procedures in small but meaningful ways.

Risk of sabotage by the customer’s team

The most common challenge is sabotage by the client’s team. This translates into breaking the system by either performing the wrong steps or actions or by not performing the correct ones. The majority of automated systems require their users to do very specific activities in terms of task timing or data collection:

Enter or scan only invoice numbers and nothing else;

When driving forklift through RFID gate stop on red & drive only on green

Apply a barcode label to each box being received

Generate PO’s based on replenishment reports

However, no system can automate absolutely everything and users do have much to handle. A person who doesn’t want to work in the new system aims to prove that the system is bad. Such individual will have plenty of opportunities to imitate the incorrect operation of the system by entering incorrect or invalid data, performing tasks out of order and so on.

The more users of the system are in the state of indecision, indifference, frustration, or outright sabotage - the less chances there are for the project to become a success story. And of course, the worst case would be when the person who’s in charge of project implementation on the customer’s side is not on board with this project. Although this never happens to me personally, we all hear stories from colleagues at conventions and ERP summits. And it seems that this kind of situation does happen from time to time. Every so often the individual, who’s appointed on the client’s side to be the head of the project, is not convinced that it's needed or sees the new system as a threat to his own position within the company. When this happens, I’m convinced that chances of the successful implementation would be low to none.

Risk of low productivity

This risk can take various forms, both- on the side of client’s team and on the consultant’s side. On the client’s side, for instance, a requirements gathering is taking longer because not all of the stakeholders can be present for the requirements gathering or cannot agree on the solution that satisfies all stakeholders. Or the document signing stage may get stalled, due to resource availability. UAT testing often gets delayed or slow moving or both due to department’s staff being short handed or having an increased amount of regular work to process.

On the contractor’s side there might be delays due to staff availability or maybe the cascading delays cause the development team to execute tasks out of order. To eliminate these risks, and to assure that development is not sitting around waiting for the action from the client’s side, the project manager works daily with the team members and sets out sprints to achieve the full workload and optimal speed of delivery. The results are assessed by the quality criteria and by means of test cases.

Risk of changes in project team composition

This next risk lies in changes in the project team structure. People take sick leaves, resign or leave 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 team’s progress, so that the new employee spends the least possible time entering the information field of the project. On the client’s side this means all of the business processes need to be carefully documented and staff training sessions are recorded in video format to simplify future training.

Risk of scheduling mistakes

Let’s consider the following example. The implementation team expected the warehouse equipment to arrive within two weeks, but because of the pandemic it took two months instead. The plan was based on an optimistic vision and now the situation must be handled by the project manager. Mitigation strategy might be to switch working on other areas of implementation until warehouse hardware is delivered.

The scheduling mistakes do not happen only due to pandemic, they can arise from much more benign things. For instance, the parties didn’t specify clearly the time of the client’s employees’ vacations. Scheduling mistakes can also lead to cascading delays- due to extended time it took to agree on the requirements it seems that delivery of the module will now happen 3 weeks later - this will push UAT to start at the beginning of the busy season, further delaying the project by an additional 3-4 more weeks.

To avoid scheduling mistakes, all project participants should engage in proactive control of the schedules.

Risk of changes in requirements

When any new requirements arise in the process of work, the risk of the project boundaries extension appears. At the beginning of the project, customers normally do not have the complete knowledge of all the business processes that will be affected. ERPs are implemented in large businesses, and on such a wide scale some details are often missed.

Conclusion

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 discovery of unforseen aspects of the project. Cascading delays can really hurt project timeline and make otherwise successful project delivery seem as a complete failure.

Risk management on the ERP Implementation is not optional, but rather a critical piece of the project that is there to ensure that the implementation is deemed a success. Remember that the customer’s refusal to acknowledge risks does not exclude the possibility of their occurrence.

About Author
Greg is a President at FiduciaSoft, the company he founded in 2015. As a provider of custom software development services, FiduciaSoft helps small and medium-sized businesses keep up with the times. Prior to founding his company, Greg has been working in logistics, manufacturing, and retail businesses as an IT consultant for over a decade and a half.