We are sure that the main cause of ERP automated-system implementation-project failure is an incorrect definition of project goals or their fundamental absence. Sometimes the very project becomes the objective, whose background at different companies may include such factors as: desire of the head (foreign) office to unify accounting (outside the business objectives of the respective division); self-realization of the project manager overriding the business itself; the owner’s unconscious decision – premature for the business – in the pursuit of advanced “regular management technologies;” development of the IT budget allocated by the corporation. If the origins of the project involve the aforementioned agendas, there is a high probability that implementation of the objective will not be transparent to the customer’s personnel or consultants. This is the source of the initial demotivation of performers from both sides that results in routine and incompetent (tenuous) project solution. These failures are accompanied by exhausting the division of responsibility at all levels of the project-participant hierarchy and staff turnover. The added value of such implementation for the corporate business (and ergo for the macrosystem) is doubtful; however, costs are unconventional.
«We are sure that the main cause of ERP automated-system implementation-project failure is an incorrect definition of project goals or their fundamental absence.»
The vagueness of goals is worsened by the incorrect delegation of powers for set objectives to consultants within the customer’s company. Definition of system requirements is assigned to unit managers due to the busyness (unavailability) of the chief executive, or to his incompetence in managing such projects, as masked by this “busyness.” This results in a gap between initiative (project goals, even when they stem from the business and are understood by management) and performance. The position of the leader is: “I decided to launch the project and secured funding, and your job is to accomplish it;” but the position of lower-level executives is: “I have been assigned this such project (who else?), that means (apparently) I need to be competent in managing it and I will be active and responsible in performing my job.” Unit managers, while competent in their professional sphere and reputable leaders within the company, often appear incompetent in managing automation (simply due to their innocent lack of experience). Their reputation and experience become negative to the project.
Following the logic that an implementation project is related to the information space of the organization, an IT manager is often appointed to manage the project. The key risks of such an appointment stem from the fact that he may lack the requisite actual power in the eyes of business unit managers. Then, he must have tremendous leadership skills and a pro-active personal stance in order to defend project interests. One should not forget that the project manager is usually assigned the function of managing the project budget, which includes cost control and saving on the invoices issued by the consulting company. The IT manager’s budget responsibility is a solid KPI in terms of his motivation, and it is rather difficult to form an impartial understanding of the cost of function managers’ mistakes without full knowledge of consulting specificity. The imbalance in such cases usually tends towards excessive quibbling with consultants and (which is worse) underestimating their efforts. As a result, the personal motivation of consultants participating in the project declines, negative relationship attitudes rise, and the implementing company’s project manager wastes his time fielding and objecting to such trivial complaints (which he cannot ignore, both for the purposes of protecting his reputation and defending his budget).
«Integrated information-system implementation does not happen at a firm (whatever its size) every year. It is a real event for the company, one that leaves an imprint on its history for many years to come.»
Let’s examine another factor. Integrated information-system implementation does not happen at a firm (whatever its size) every year. It is a real event for the company, one that leaves an imprint on its history for many years to come. Accordingly, one should recognize that functional staff, including even competent IT managers, cannot accumulate the proper experience specific to implementation management.
The project managers from the implementing company are often highly-skilled, professional executives who have led a challenging (irregular) consulting life. They can predict all of the likely organizational problems of the project and try to avoid them, acting much like psychologists within the customer company and balancing on the edge of functional managers’ relations for the benefit of the project. But if there is a weak link in the project management carried out by such managers it is their motivation. Within the consulting company itself, the short-term authority and remuneration of the manager usually depend on the profitability of the project rather than on his referral success. And over the agreed budget, the customer pays only for its own mistakes. It so happens that the competence of the manager from the performer’s side is often geared not towards quality implementation of the project’s essence, but towards a structured confirmation for the chief executive with regard to the errors and mistakes made by the staff of the latter. However, this requires a lot of energy and time. As a result, the costs of the parties increase.
«It so happens that the competence of the manager from the performer’s side is often geared not towards quality implementation of the project’s essence, but towards a structured confirmation for the chief executive with regard to the errors and mistakes made by the staff of the latter.»
Finally, the motivation of the consulting company itself also contributes to the scope of risks. At the initial stage of project implementation, an experienced consulting manager can see the project’s rational kernel, and is certainly well aware of the absence or presence of the factors contributing to incorrect target-setting described in the very beginning of our article. However, as concerns revealing them to the leader on the customer’s part, it is – first – not an easy task (and thankless for the consultant), and second – may cause postponing of the project, or its general review. Such an outcome leaves the consulting company without a margin for selling the expensive licenses that it receives from the ERP developer. And it means much easier money than the fee for project implementation and one of the key success indicators of the consulting company in the eyes of the vendor (in the eyes of regional managers, to be precise), conferring the right to award insignias and testimonials – as well as access to the ERP supplier’s sales channels.
«Postponing of the project or its general review leaves the consulting company without a margin for selling the expensive licenses that it receives from the ERP developer.»
To conclude. An experienced consultant who has been involved in a range of serious major implementations and gained personal success in this field will find numerous other causes of project failure (and its potential risks). But if the causes described here are transparent to you – this is a solid guarantee of project success. Hopefully, this will not be at the expense of the positions of competent middle managers; however, an integrated automated-system implementation project must prevail over them, i.e. be the responsibility of the chief executive and his trusted architect. This architect may be a project manager with competence in various areas and the appropriate experience that allow him to look at the corporate business in general and venture upon a review of certain aspects of middle-management activities, where necessary. A management information system is a component of the asset (brand) that does not depend on any single employee (even the most superior) over the long-term. It should be designed and implemented from above, indeed, first and foremost – as part of the company’s assets, not as a user tool. If you lack such confidence at the moment, you’d better not launch the project today – just try to make it as pain-free as possible.
Yegor Loginov
Strategic Growth Manager & Startup Executive | Executive MBA LinkedIn Facebook
