Say NO to agile ERP implementations

From time to time, new philosophies arise and sometimes turns into “the only truth”. And where the basic idea is being picked up and applied in a way it was not intended from the beginning. We have seen it before and we’ll see it again, over and over again. Agile projects are such a phenomenon.

Why have agile working methods and agile projects become popular as models for development? Well, for the simple reason that in many contexts they are the only and best way to achieve a long-term and sustainable result.

Simplified a bit, it can be argued that an agile way of working is a successful mix of two models that are basically rather bad. The first model advocates that you plan “everything” down to the smallest detail before you begin your change and development. And the second model advocates that with only limited planning, you start to develop and tackle the problems as they arise. The agile model advocates working with a gradual planning and development, but where the planning is limited to “what is reasonable to overlook” without overworking down to the smallest detail. However, it also means that the project can gradually change character and move as new insights emerge during the project’s work. And where the final outcome may differ from what was expected when the project began. And this can of course be considered both positive and negative.

The basis for working according to an agile model comes from system development. Historically, many IT projects have been carried out where the cost has become astronomical and where the expected and necessary result has never been achieved. Working agile is a counterpoint to working with continuous control and management and being able to act and change when new insights show that corrections of plans and goals are required. In this way, the agile project becomes more of a fast and maneuverable motorboat compared to a large supertanker that takes a long time to turn.

 

The problems with agile ERP projects

So, if there are so much positive to say about agile projects then why does this blog have a headline that indicates something else? Well, for the reason that sense and balance are required in the approach to agility. All models, no matter what they are called, have their given place and purpose. And just like for other models, an agile model is not suitable for all IT projects and in all contexts. And one of the contexts where an agile model should be used with great caution or not at all is ERP implementations.

Of course, there are differences between ERP projects in both scope and complexity, but in everyday speech it refers to a project where a variety of processes and modules are to be replaced from an old environment to a completely new environment. And a situation where the majority of processes and systems need to be replaced at the same time (which, however, should not be confused with the classic expression Big Bang). The basic logic of an ERP system is that all the parts are so integrated and integrated that it is difficult and sometimes impossible to plan for anything other than a single commissioning. However, this does not prevent it being possible to wait with certain processes that are not critical to the commissioning or that you can plan for a commissioning where you choose limited flexibility in the processes before switching up.
The challenge with ERP systems is precisely that the basic logic of the business and the overall information flow must be connected and well analyzed and planned before the system can be fully tested and where the hypothesis of the business model can be tested. The problem that can arise with an agile model is the strict believing of how the model should be applied. Of many belivers, the model must follow a fairly strict principle with sprints of 3-5 weeks, something that together with a relatively large and complex business system can prove difficult and in a context where work must take place in parallel in many process areas, and where the result is difficult to assess before you can start running complete tests through the system at a much later stage.

The misunderstanding that often leads to challenges with agile ERP implementations is the attitude that the agile model keeps the total cost down and that the end result is better. It is by no means a given. And in the very worst examples, the parties choose not to produce a requirement specification or plan at all, but assume that what is in the standard is sufficient and that the problems are dealt with when they arise. And where it may turn out quite late that the total solution will not hold together at all in the way one would have expected. But where at the same time the project has gone so far that for cost or political reasons it is difficult to turn around or stop. It is important that the customer understands their role and responsibility in an agile ERP implementation. And that the customer is willing to pay the price for the result. Although the final cost may turn out to be significantly higher than what was estimated when the project was initiated.

It is very difficult for the traditional customer to fully understand the consequences of the decisions made in each sprint and to be able to get an overview of how it will affect the final system solution. And at the same time, the supplier can keep his back relatively free as the customer is required to approve each individual sprint. In the absolute majority of all ERP implementations, there will sooner or later be a formal phase where the customer must test and verify the total setup. And in situations where the customer in this phase is faced with the fact that the final solution will not work as intended at start-up, it is difficult to claim that the supplier will bear the additional cost of the adjustments required to change the set. It may be that individual parts and flows work excellently, but that the system in end-to-end tests does not give the planned result at all. And the consequence is that the question of liability becomes unclear and where a legal assessment becomes very difficult.

Just as there are examples of projects where an agile model has turned out well in ERP implementations, there are at least as many examples of projects where the result has been a disaster. No matter how you turn the situation around, success can be boiled down to the individuals and the experience included in the team that will carry out the project. An agile model can never create a counterweight to a lack of insight and understanding of ERP projects, instead the effect is the opposite.

The above text should not be interpreted as a firebrand against agile projects. It should be interpreted that agile models are not automatically the best model for ERP projects. And in many cases it is even a model you should refrain from – if you want to create clarity in what you want to achieve with your system and where you want to create clarity in what the responsibility looks like between the parties regarding the realization of the solution. The model must be applied with common sense and caution.