Published
Author
From time to time, phenomena and trends arise that manage to establish themselves as truths even though they are more about religion than scientific fact. And where the fundamental idea is adopted and begins to be applied incorrectly. We have seen it before and we will see it again, many times over. Agile projects are precisely such a phenomenon.
Why have agile working methods and agile projects become popular as models for development? Simply because in many contexts they are the only and best way to achieve a long-term and sustainable result.
In simplified terms, one can claim that an agile working method is a successful mix of two models that are fundamentally poor. One model advocates planning "everything" down to the smallest detail before starting change and development. The other model advocates starting development immediately with no planning and tackling problems as they arise. The agile model advocates working with incremental planning and development where planning is limited to "what is reasonable to oversee" without overworking down to the smallest detail. However, this also means that the project can gradually change character and move in pace with new insights arising during the project work. And where the final result may differ from what was expected when the project began. This can, of course, be seen as 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 became astronomical and the expected and necessary result was still never achieved. Working agile is a countermeasure to both work with continuous control and governance and to be able to act and change when new insights show that corrections to plan and goals are required. In this way, the agile project becomes more like a fast and manoeuvrable motorboat compared to a large supertanker that takes a long time to turn.
If there is so much positive to say about agile projects, why does this blog have a heading that suggests otherwise? Because it requires sense and balance in the view of agility. All models, regardless of their name, have their given place and occasion. And just like 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 system projects.
Of course, there are differences between ERP system projects in terms of scope and complexity, but in everyday language, it means a project where a multitude of processes and modules are to be replaced from an old environment to a completely new environment. And a situation where the majority need to be replaced at the same time (which, however, should not be confused with the classic expression Big Bang). The basic logic regarding an ERP system is that all parts are so interconnected and integrated that it is difficult and sometimes impossible to plan for anything other than a consolidated deployment. However, this does not prevent waiting with certain processes that are not critical for deployment or planning a deployment where one chooses limited flexibility in the processes before scaling up.
The challenge with ERP systems is precisely that the business's basic logic and the overall information flow must be coherent and well thought-out before the system can be fully tested and where the hypothesis regarding the business model can be tested. The problem that can arise with an agile model is the slavish belief in how the model should be applied. Many followers insist the model must follow a fairly strict principle with sprints of 3-5 weeks, something that together with a relatively large and complex ERP system can prove difficult and in a context where work must proceed in parallel across many process areas, and where the result is difficult to assess before complete end-to-end tests through the system can begin much later. The misunderstanding that often leads to challenges with agile ERP system projects is the belief that the agile model keeps the total cost down and that the final result becomes better. This is by no means a given. And in the very worst examples, the parties choose not to produce any map or blueprint at all but assume that what exists in the standard is sufficient and that problems are handled as they arise. And it may become quite late apparent that the total solution will not hold together in the way expected. But at the same time, the work has progressed to such an extent that for cost reasons or political reasons it is difficult to back out or cancel.
It is important that the customer understands their role and responsibility in an agile ERP system project. And that the customer is prepared to pay the price for the result. Even if the final cost turns out to be significantly higher than estimated when the project was initiated.
It is very difficult for the traditional customer to fully understand the consequences of decisions made in each sprint and to be able to foresee how it will affect the final system solution. And at the same time, the vendor can keep relatively free from blame as the customer is required to give approval for each individual sprint. In the vast majority of all ERP system projects, a formal phase will sooner or later arise where the customer must accept and test the solution. And in situations where the customer is confronted at this phase with the fact that the final solution will not work as intended at the start, it is difficult to argue that the vendor should bear the additional cost of adjustments required to change the setup. It may be that individual parts and flows work perfectly but that the system at so-called end-to-end testing does not deliver the planned result. And the consequence is that the question of responsibility becomes unclear and where a legal assessment becomes very difficult.
Just as there are examples of projects where an agile model has worked in the implementation of an ERP system, there are at least as many examples where the result has been a disaster. Whatever way you turn the situation, success comes down to the individuals and the experience included in the team carrying out the project. An agile model can never compensate for a lack of insight and understanding of ERP system projects; instead, the effect is the opposite.
The above text should not be interpreted as a tirade against agile projects. It should be interpreted as agile models not automatically being the best model for ERP system projects. And in many cases, it is even a model one should definitely avoid – if one wants to create clarity about what is to be achieved with the system and create clarity on how responsibility is divided between the parties regarding the solution's realisation. The model should be applied with sense and caution.
