I have experienced and seen plenty of successes using agile development methodologies in various types of projects. Agile addresses many of the failures that have often plagued waterfall projects and can be a powerful approach.
Then again, I have also seen agile used very poorly, as essentially just an excuse to have no structure for a development team. This goes poorly no matter the situation. But how does agile look in an ERP implementation?
The CEO of our company recently posted an article about why agile is a bad idea for ERP implementations. This video summarizes his point of view:
While there may be some valid points in this argument, I have found that agile ERP implementations can be very effective when deployed correctly. For example, SAP’s Activate methodology and Microsoft’s SureStep methodology for D365 implementations both utilize agile concepts, so there is clearly merit in this approach.
Below are some things to consider when considering agile approaches to your ERP implementation:
First of all, any agile methodology must still follow good ERP project management practices. While agile allows documentation to be developed later in the process, the quality and depth of documentation must still be robust and supportive of both adequate oversight during the project as well as solid hand-offs of material after the project ends.
Another of the key elements is that project governance must be equally strong regardless of the methodology. While an agile team can be empowered to make decisions on the ground, there must still be strong feedback loops to ensure that those project teams are making decisions that align with project goals.
And you better have those project goals very well-defined. This is true regardless of your methodology, as any project that starts without a clearly defined set of objectives is destined for struggle and likely failure as well.
ERP projects require a particular emphasis on integrating data and processes across silos. As a result, agile project teams need to be extremely well-aligned to the organization as a whole. Depending on the size of the organization and the implementation, there are different techniques that can be used to accomplish this.
On a smaller implementation, business representation on the project team can cross organizational boundaries. A strong product owner with a working knowledge of all relevant business areas who can make decisions that effectively incorporate the perspectives of disparate business units.
If your organization has a candidate for product owner with this skill set, knowledge, perspective, decisiveness, and capacity to devote to the project, you have a chance at having the leadership necessary to ensure your project meets its goal. This is better than veering off course with decisions optimized for certain departments at the expense of others.
In a larger implementation such as an SAP S/4HANA transformation, no one person can fill this role. An effective project structure must be created to align all of the individual project teams’ decisions to the broader organizational goals. A scrum of scrums that brings all of the sub-projects together can help to do this.
Simply holding these meetings is not enough, though. There must be appropriate engagement from leaders along with deep enough communication from the teams to ensure that no one goes too far off track. You must ensure the following elements:
If this all sounds like a lot of work, it is! Agile is not an excuse to do less work. The real lesson here is that your project methodology is not the key determinant of success. Setting clear project objectives, defining effective organizational communication methods, and committing to an engaged and strong project governance structure are all crucial regardless of how you approach your project.
If you are confident that you have all of these measures in place, you can be successful whether you use agile or waterfall. Effective ERP consultants such as those at Third Stage can help you effectively deploy an agile ERP implementation strategy.