Agile Project Methods for SAP ERP Projects?
SAP Project Guidance
Looking at the “Agile Manifesto” and how Agile methods are applied generally involves small, discrete, “digestible” work and task components.
Trying to juggle the number and complexity of dependencies on a full scale SAP ERP project involves management and coordination efforts which completely go against the idea of Agile methods.
======
ERP projects tend to have too many moving parts for Agile–, there are too many dependencies and Agile provides too little control and coordination. The level of coordination required for a large business package implementation flies in the face of “Agile” methods and techniques. For example, you have to coordinate:
- process configuration teams,
- custom code development teams,
- data conversion,
- change management,
- training,
- testing,
- governance,
- infrastructure, etc.
On complex projects like this all those “sprints” that are not carefully coordinated and planned (which goes against the “Agile Manifesto” listed below) become completely disjointed disasters. There are too many work streams with dependencies that can not be going in “their own direction” regardless of the impact to other work streams.
Agile Manifesto Activities
The following chart, from the Agile Manifesto, illustrates serious trouble spots for ERP projects like SAP.
Valued | DE-Valued |
Individuals and interactions | Processes and tools |
Working software | Comprehensive documentation |
Customer collaboration | Contract negotiation |
Responding to change | Following a plan |
Notice, 3 out of 4 of those items on the RIGHT side are often precursors to ERP implementation failures according to the academic literature. Numerous case studies prove Agile “De-Valued” areas are the places ERP projects fail. For example:
- Failure to follow good processes and have solid tools.
- Failing to have adequate documentation (training materials, help, etc.)
- NOT following a well laid out plan (i.e. SAP’s PROVEN ASAP implementation methodology, including sample project plans, templates, etc.).
The only Agile Manifesto item that might have strong need to be followed in the ERP space is the focus on the customer over the system integrator contract.
All of those Competing Stakeholders and Constituents
Not only are the project related dependencies and work streams significant, there are numerous competing constituencies which must also be coordinated:
- business stakeholders or organization,
- IT,
- external business customers,
- external vendors,
- system integrators (when you use consulting companies),
- internal business senior management,
- business department heads who don’t always agree with each other, etc.
While Agile methods might work well for small, discrete, component areas of an SAP or other ERP project the academic literature proves it is a disaster for ERP implementations.
Agile is not a waste of time, it must just be understood and used in the PROPER CONTEXT of an overall SAP project. Even the ASAP Methodology includes an “Agile” overlay. This is an overlay of the existing ASAP Methodology–, it does not replace more traditional waterfall methods and does NOT adopt the “de-vauled” Agile Manifesto areas.
Does Agile Have a Place in ERP Projects?
It might.
Agile is not suitable for projects with multiple, overlapping / parallel activities with dependencies between them. The parallel and overlapping dependencies create a requirement that is more suitable to traditional project management methods with:
- full project plans,
- discretely defined tasks and responsibilities (to avoid “border wars” at transition points),
- clearly defined deliverables,
- management of parallel work-streams and parallel critical paths, etc.
Applying Agile principles to an overall SAP project creates a high likelihood of blown timelines, blown budgets, and collapsed scope — delivery suffers while stress balloons.
Agile in SAP ERP Project Examples
I know about the struggles, stresses and messes of Agile SAP projects. I’ve been on three of these types of projects and none of them went well.
On one SAP project they tried to manage it with “Agile” and it was a complete mess –, the coordination and responsibility struggles forced a change to the more traditional waterfall approach. Using Agile methods the project had an unsustainable burn rate for the budget, dates were ALWAYS slipping, inter-team coordination and planning were a complete disaster, and before the mid-course correction this project was not going to go live.
Worse still because of the “Agile” methods of only planning small, discrete work components just before they are due, each dependent group tried to minimize their own work and risk by dumping many of their traditional responsibilities and tasks onto any other group. With Agile they were allowed to “self define” much of their own effort and naturally tried to minimize their effort while maximizing their success (at the expense of other project participants and work streams).
I do NOT place this responsibility on the clients who hire outside help, they obviously recognized a capability gap or a need they are willing to pay for. I hold the outside project managers responsible for this and if you ever encounter one of these snake oil salesmen then you should FIRE THEM!
My Conclusion on SAP and Agile Deployments?
Wide application of Agile is a disaster on any major SAP, ERP, or business software implementation project. I can absolutely guarantee you that any Agile SAP project delivery “success” claim violated the Agile Manifesto to get there. There are too many moving parts and too many constituents to use pure Agile on a full blown SAP project.
Popular Searches:
- sap roi powerpoint
- sap agile project management
- agile methodology for SAP/R3
- sap implementation failure in maryland state tax
- SAP Implementation using Agile methodology
- sap implementation work stream dependency
- sap migration project plan template
- sap project management agile
- sap project plan ppt
- sap scrum methodology
- sap test plan example vim
- scrum method for erp development
