We read a lot of articles and different points of view on the relevance of implementation methods for ERP projects : adaptive or predictive ? What approaches should be adopted to ensure project success ?
Based on our past experience, we have identified several ” invariants “, parameters common to all our projects, which will help and enable the method to be adapted to project contexts.
Invariant 1: Trust operational teams to promote agility in the Enterprise.
The context of the customer is important. At the risk of contradicting preconceived ideas, customers with a strong history on their applications and a significant technological debt are not the most resistant to a change of method. Implementing agile methods opens up the prospect of IS upgrades within timeframes previously unknown to business teams. This motivates and commits to a collective project, and strengthens relations between business and IT teams, which have sometimes become strained over the course of past projects.
Invariant 2: Adopt the method (agile or predictive) according to the component to be implemented.
The product to be implemented is a contextual element influencing the method to be used. Today’s IS urbanization imposes components of various kinds, with ERPs, cloud applications, hybrid applications and other mobility-related components. Faced with this multitude of products to implement, formalizing end-user needs in the form of ” User Stories “, as advocated by agile methods, is a good approach. Implementing all IS components using an agile method is more questionable. To secure the integration of the new product into the IS, predictive methods (V-cycle) are more appropriate. For example, when it comes to modifying interfaces, managing releases from the existing IS and ensuring consistency with other projects, planning is essential, based on known and controlled requirements.
Invariant 3: Change management must adopt an agile method.
The most important criterion, and the one that varies most depending on the context, is that of the team project.
Implementing an ERP in an organization will initially destabilize the structure, then, with a phenome of resilience, the project will bring the expected benefits. To achieve this objective, the project team must take into account any resistance to change at an early stage. This necessary anticipation is achieved by detecting weak signals, and here again, adaptive methods offer a real advantage in reducing the risk of product rejection.
What applies to the Enterprise must also apply to the project team, each member of which is an ambassador for the project. Agility makes it possible to share a common vision throughout the project, through various ” ceremonies ” (Daily, Retrospectives)…
No ROI without buy-in. No buy-in without change management;
A successful ERP project: two findings that fly in the face of preconceived ideas.
We’ve drawn up the following two observations, which also run counter to certain preconceived ideas.
- Constat n°1: Agility, yes, but without getting agitated
Beyond the method, the tools exist to enable the project team to collaborate transparently. All stakeholders (integrator, customers, sponsors) share the same source of information. The famous “tunnel effect” of predictive methods is a thing of the past.
Roles are changing, and the project manager in predictive methods is becoming the project facilitator in adaptive methods.
- Consensus no. 2: Predictive methods are deceptive.
The use of predictive methods gives us the illusion of certainty : Certainty about start-up date and content. This false assurance pushes companies to make strong commitments right from the start of the project. The resulting pressure on the project team, which supplies the product, can lead to a lack of quality that is detrimental to future commitments. The ” contract ” takes precedence over the result.
A partial or even partial conclusion…
A predominantly predictive project is better suited to meeting legal requirements, such as e-invoicing, which will change infrequently with regulations. An adaptive project, on the other hand, is better suited to meeting a business need that will change frequently with the demand for new uses.
Even if projects meeting legal and regulatory requirements are certain to be implemented, they can sometimes be delayed – e-invoicing is a good example – and the resumption of a V-cycle project requires a major effort. In such cases, a dose of agility helps to identify a minimum set of functionalities (MVP) that can be added to when the project is resumed.
On the other hand, for the maintenance of agile projects, it can be interesting to use certain predictive methods for :
- A project requiring few evolutions;
- Managed by support teams accustomed to documentation structured by technical objects;
- The use of deliverables (such as specifications per technical object).
The right balance lies in the right mix of methods, all serving the same purpose: to secure the project.
