As an implementation partner of Odoo, we have been carrying out implementations of all types and sizes in various industries with varying complexity for 12 years. At the start of each project, we always get the same question, 'What are the risks that could hinder the success of this project?'. In this blog, we list the 3 most significant risks to the success of a project.
Employee engagement
Implementing an ERP-system is often not the choice of the employees who will have to work with it. In many cases, these employees are accustomed to the package that will be replaced and know how to do their daily work (often with a lot of 'workarounds'). There is a risk in the eyes of these employees that this will change and that they will be held accountable for it. In our implementations, we try to take this into account from the quotation stage.
It starts with a strong vision from management. There is a reason for choosing to work with new software, and it's important that the management conveys to the employees that this is the future of the company. When employees understand the importance of the implementation and know that the choice has been made, this naturally leads to more employee engagement.
When we talk about engagement, people will always work harder for something they are part of and have a stake in. If something is imposed without asking for input, it will always lead to resistance. Try to ask for input from several key users during the package selection and highlight the positive points of the current package for the users. These are the points that we can consider in the training and implementation by anticipating as much as possible and focusing on these aspects of the software.
Finally, resistance often actually stems from uncertainty. Someone may currently be very good at their job and now suddenly has to work with software they do not know at all. It's always a mistake to try to replicate the old system, so the employees will have to get used to the new system. This is also why we place enormous emphasis on training and the transfer to the employees. We use the 'train the trainer' principle. The advantage of this is that there is at least one person within the organization who can provide first-line support and if this person can explain it to a colleague, we have also validated that the knowledge has been well transferred. It is also advisable to start writing work instructions by and for the employees early on. An acceptance test, go-live support on-site, and support after go-live are all part of the implementation, so the employees can start with confidence in the new system.
Scope creep and customization
Before the start of the implementation, we always try to give a realistic budget. This budget is based on the preliminary discussions, but undoubtedly new wishes will arise during the implementation. Progressing insight and feedback from employees, for example, can lead to changing requirements. Accommodating all wishes always leads to budget overruns, but not necessarily a better system.
First, we always start with as small an implementation as possible. We stick close to the standard and implement the applications with which your company makes money. We will not simply go along with the wishes but want to be convinced of the necessity. By first learning to use the new package as intended, future wishes can be identified much better, and it can be prevented that we are simply replicating the old package.
Our approach will always be to minimize customization. An extensive explanation of this can be found here in the pros and cons of customization . A brief version is that it is cheaper, more manageable, easier to train, and better to migrate to a future version.
After a period of 3-6 months of working with the system, our experience is that at least 50% of the custom work made is seen as redundant, therefore we always advise to give the standard version a chance first and expand later.
Validating project tasks
When we start a project, we create a project plan based on the given quote. This project plan forms the basis for the implementation. It serves as a communication tool between the parties, as a record of progress, as a guideline for the remaining work, and plays an important role in budget monitoring. When all tasks are completed, this means that the project has been delivered.
Completing the tasks is not when the consultant is done with the work, but when the customer has validated the work and given approval of the result. This is also one of the biggest risks for the project.
When someone is asked to approve the work, they also bear a certain responsibility for the result. This is extremely important for us, but for some employees, it can also be quite exciting. This can lead to a build-up of tasks that still need to be validated, potentially containing a large amount of work that is impossible to plan.
To prevent this, we try as much as possible to emphasize the validation of the tasks. Sometimes this means that we perform the tests together with the respective employee or escalate when validation does not happen. It is therefore extremely important that the members of the project team can perform the validation and have sufficient mandate to make decisions.
It is also advisable to appoint a good project manager at the customer. This person is responsible for guiding the implementation and internally motivating the project members to test and validate. This person must also have enough mandate within the organization to escalate when action needs to be taken. We also refer to this person as the SPOC or 'single point of contact'.
By thinking well about these risks before the start of the implementation and putting the right people in the project team and doing the implementation with an experienced partner like Odoo Experts, the project gets the best chance of success.
The three biggest project risks