Worse than Brexite, Trump and Trade War ...

The tool, the chosen software, is not primarily responsible for problems.

But any of the following reasons can cause the implementation of an Enterprise Resource Planning system to fail spectacularly ...

(Human) ressources

• Every ERP implementation needs human support. The project teams are usually heterogeneous. This means that specialists from the implementation service provider work together with employees of the company concerned who, as key users, (should) have special background knowledge about the respective processes in the company.
• Often, initial difficulties arise here if the management does not clearly and unambiguously separate the additional tasks of its employees from the other tasks in day-to-day business. Without a clear division of the work for the project team, frustration, dissatisfaction and lack of support in the project are pre-programmed. Absolute transparency must prevail here! The division can vary across different project phases: when the project is ramped up (so-called ramp-up), a high proportion of 70/30 employees (project to day-to-day business) are involved in the conception or a BluePrint. During the implementation phase, for example, this involvement is reduced to 20/80 and then increased again to 80/20 for the integration and acceptance tests towards the end.
• Transparency and clarity regarding the respective expenses to be incurred are the be-all and end-all of the project, which requires careful coordination not only with the employees concerned but also with the respective team leaders (day-to-day business). Especially in the early phases of the project, sufficient time should be planned for the necessary clarifications and, if necessary, the necessary training and further education of the employees concerned.

Project Know-How

• Most of the time, the theoretical background for project management methods is available. However, we often find that there is a lack of practical experience and close cooperation with the management level. Unfortunately, due to a lack of seniority, people often fail to communicate unpleasant truths, openly discuss mistakes and address problems in time. As a consequence, the project status is talked up for a long time and the decision makers often wake up rudely because the problems can no longer be concealed.
• In these cases, an external project manager or leader or even project controller provides valuable support. With his seniority and professional background, he creates the eye level between service provider and decision-makers. He is not subject to any internal dependencies and can therefore act in an open and focused manner.

Standards versus Customizing

• The classic of all delays: There is no detailed specification (often called BluePrint)! Instead, the order is given to the implementer with numerous "standards". Often technical standards & methods are mixed with "best practice" approaches from the respective industry. What is often overlooked is the fact that this "Best Practice" represents only a sum of all modules selected and implemented by other market & industry participants. An examination of the matching for the own processes or corresponding adjustments in advance (conception / BluePrint) is omitted. Often because of the associated financial implications.
• In the course of the project, the key users come from the field with their own understanding of the internal processes, which they naturally want to find 1:1 in the new solution. Appropriately, the argumentation follows that the respective process is ultimately a special feature of the company (without which one would never have been so successful). It is clear that if everything is solved in a standard way and the wishes of the users are ignored, resistance arises which slows down the introduction or leads to blockades.
• A clear positioning of the company is also decisive here. Ideally, this is combined in advance with a detailed concept (BluePrint) involving the relevant key users from all areas. A stringent, emphatic project manager takes the employees along this path and always finds the balance between deadlines, costs and results. This also includes the technical expertise to make the respective effects of adjustments transparent.
• If there are relevant decision-making bodies to decide on such changes (a so-called Steering Committee), factually documented decision papers belong to every change, moderated by the project manager.

If Customizing ... you need a clear change process!

• This essential component of any more complex IT project is often completely underestimated. Changes are often and wrongly put into the "IT topic" drawer. In fact, most of the time it is about new processes and procedures that challenge the entire organization and require careful coordination with the departments and teams involved. When employees are given new roles and tasks, and possibly even activities are dropped, the works council is also on board.
• This requires a clear process methodology including stringent leadership by the project manager. All open issues and TODOs should be documented electronically and continuously updated in a way that is transparent for all parties involved. The differentiation between changes and problems detected in the course of the project (errors in the process or software) is crucial for sustainable handling and correction (bug fixing).
• A clear differentiation is also decisive for the cost side, as far as the contractual agreements with the implementation service provider allow. Changes are usually considered to be chargeable, while problems with necessary bugfixing can be considered "included" depending on the contract terms and thus do not cause any further costs for the customer.

Migration of Master data

• The decisive factor for a successful introduction is to take along all the data that has accumulated over many years or even decades in the previous system.
• In most cases, the expectations of decision-makers regarding the quality of this previous data must be significantly reduced. In the worst case, there is no master data or master data with completely different structures, which is distributed over several (historical) systems or databases, has been neglected for many years and is consequently very outdated. Duplications, different spellings or different versions are only some of the problems associated with old data.
• For modern ERP systems, master data must be elaborately prepared or even additionally generated in order to be used in the new structures. A solid data stock is also an absolute prerequisite for the software tests to be carried out at a later stage in order to find and eliminate data-induced errors in the software at an early stage.
• To this end, it is important that clear procedures and a master data manager and, if necessary, experienced programmers are allocated and determined early in the project. Appropriate roles and responsibilities must be clearly defined. The support by appropriate experts that is essential for the success of the project must be organized in good time and implemented at the right time. Additional tools such as Excel with an experienced programmer are used quickly and pragmatically to ensure the necessary checking, correction and transformation of legacy data.

Clear priorities

• Most companies are subject to dynamic developments from day-to-day business, the effects of which require a flexible adjustment of priorities. A new major customer, pressure from competitors, new product requirements or the acquisition of another company. Conceivable reasons are manifold and justified, but they also challenge the project participants in their daily business and require a clear commitment from top management.
• If the priority of an ongoing implementation project is changed during the course of the project, massive effects on deadlines and costs must always be expected. Whether it is due to a lack of support/participation of key users or to new deadlines, which lead to delays and additional costs for the implementation service provider.
• These changes must be made transparent by the project manager with all implications and communicated to top management. There must be no excuses in the sense of "... we can do it ...". A new project plan, taking all premises into account, must be drawn up at short notice and signed by all decision-makers of the parties involved.
• If possible, additional external resources can be used to compensate for the lack of support from employees. If there is sufficient project time "left" at the time of planning (new priorities), the use of additional resources makes sense. At a late point in time (e.g. shortly before GoLive!), the supporters must have the perfect prerequisites to become productive quickly and without much training.

Implementation strategy

• The strategy and timing of the introduction must be precisely planned and communicated in good time. Environmental conditions (holidays, seasonal periods, etc.) as well as possible risks (failure of service providers, delays in implementation) must be taken into account. Difficult to find and often not feasible under cost pressure, the balance between an agile strategy with small interim results (so-called "sprints") and a waterfall "big shot" introduction at an all-decisive date is a challenge.
• There are good arguments for both strategies. The challenge for an experienced project manager is to find the right mix in the form of a modern, often hybrid strategy.

Solution testing ... and testing

• Complex software solutions in connection with new processes and procedures require that the testers from the key user environment become deeply familiar with the new system. A frequent mistake is the insufficient preparation phase of the projects. On the verge of a serious conception, the BluePrint ideally already contains the relevant test cases (so-called "UseCases"), with which the correct implementation of the specifications is checked later.
• A lack of these preparatory measures or the competent training of the testers has an enormous impact on the overall process. Even the differentiation between operating errors and real problems can become a great challenge, which loses its horror through careful training in advance. Without comprehensive test cycles, problems are analyzed and solved individually. It is not uncommon for key users to be out of the loop when retesting bug fixes and lose a lot of time on the project.
• For the individual test phases, sufficient time must be included in the project plan to carry out the functional tests in a concentrated and careful manner in a practical environment. Depending on the results, individual tests may have to be repeated several times. A serious project plan takes this practical experience into account accordingly. A rather agile approach has proven itself here as well, with which all relevant key users try out all essential processes in a fixed 2-3 week sprint together in one room in the correct order from start to finish and thus test the solution functionally.

Training

• Often the unloved stepchild of every project. Trainings cost money and time, the affected employees are not available for the daily business.
• The planning and coordination of training courses is time-consuming. If it is not possible to find common training dates for the numerous users of the new software, the top management has to put its foot down.
• The recipe for success of a functioning training concept consists of timely planning, the distribution of all training contents to groups and subject areas, transparent communication throughout the entire project and consideration of latecomers.