Why is Agile Project Management Better for ERP Projects?

Visit Website View Our Posts

Have you ever noticed that Enterprise Resource Planning (ERP) projects often go over budget, take longer to implement than originally planned, or deliver less value to the business stakeholders than expected? I have spent more than a decade implementing ERP projects for clients, and I have been constantly wondering why our industry continues to deliver projects using the same methods with the same inadequate results.

A few years ago, I began looking for some answers. I came across Ken Schwaber and Mike Cohn and their books, Agile Project Management with Scrum and Agile Estimating and Planning. I realized they were wrestling with the same questions I had been asking. The challenges faced by most ERP projects can be easily understood in the context of industrial science and process control models.

The two major approaches to control any process are the defined process control model and the empirical process control model. Our industry has used the defined process control model since the beginning, a model often characterized as the “Waterfall methodology”. The Waterfall methodology is simple and linear: Analyze the business need, design a solution, develop the solution, test it, and then deploy it. This process appears to be foolproof – follow the steps in order and nothing can go wrong!

Those who have been through a well-managed ERP implementation using the Waterfall method recognize the typical landmarks of the process: After extensive planning and analysis, a Functional Requirements document is produced. Once all the major parties agree on the requirements as stated and sign off on the document, a more technical team begins formulating the actual design of the solution. This results in an Enterprise Design document that, once accepted, becomes what the developers use to begin coding the solution that will eventually be delivered to the project team for testing.

If any of this Waterfall process sounds familiar to you, then I am sure you will recognize what often happens as a result. Even when this process is followed exactly, once the requirements and designs are formulated and accepted, they are rarely modified. Often, these documents are prepared without full knowledge of all the details and assumptions on both the client’s side and the partner’s side – the client does not fully understand the product, and the partner does fully understand the client’s processes. These details are slowly identified only as the project is developed and implemented, but rarely is the design modified as a result.

Then there are misinterpretations of the requirements – no matter how well written the requirements document may be, the development team can sometimes misinterpret the requirements to mean something else and develop something other than what was requested (or, perhaps more accurately stated, what was intended). Since development often happens in a vacuum until that phase is completed, these problems are often not identified until the project is rolled out to test.

Finally, months can pass from the time the requirements were originated and agreed upon until the delivery of the project to test. Many significant events may have occurred in that time that requires a retooling of the deliverable to make it work – other company processes may have changed, new equipment or software may have been introduced, or any of a number of factors could result in the delivered solution being insufficient to meet the current needs of the business.

This is where a comparison of process control models makes sense. In a defined process control, which the Waterfall Methodology represents, the assumption is always that if there is a problem with the output or result, then the problem lies in the inputs. So if the project yields a product that is insufficient to the needs of the business, the assumption is that the requirements were not adequately specified. This simple fact is why the Waterfall Methodology necessarily breaks down for an ERP implementation. Typically ERP projects are a joint effort between a client and the organization that is helping them to implement it. Each team brings unique and necessary skills to a project, but neither team exercises complete control over the other. From the time the project starts until it is complete, the client team continues to learn more about the product they are implementing and the best ways to leverage it for their business. At the same time the organization that is assisting with the implementation learns more and more about their client's unique needs and processes and is better able to suggest how the client should implement the software. Clearly no one exercises complete control and everyone is operating on incomplete information, no matter how much time is spent upfront in planning.

As an empirical process control model, agile methodology takes into account the fact that most teams gain insight and information as a project progresses and will act to significantly improve the quality of the outcome if this information is properly incorporated as soon as possible. Agile methods put a framework and a structure around these iterative feedback loops to provide a consistent delivery of business value at a consistent rate. Agile provides frequent checkpoints throughout the project where all parties converse on the project’s status to ensure that any new information is incorporated into the design and the project plan is adjusted accordingly. Regular meetings also ensure that steady progress is made and that problems are identified early and corrected as they occur, not at the end of the development cycle.

Unfortunately under a waterfall method the entire project is scoped, estimated, and planned when everyone has significantly less information then they will come to possess as the project progresses. What's worse is that teams are typically contractually obligated to deliver the solution they agreed to under the waterfall method whether it was the optimal solution or even meets the current needs of the business by the time the solution is delivered.

Hopefully, our industry will take a critical look at how projects are delivered and understand that there is a scientific basis for why projects will continue to risk falling short of their promised goals if they are delivered the same way they always have been. However there is hope that if, as an industry, companies begin to adopt agile principles they will see projects that deliver more business value at less cost than can be achieved under the status quo.

Greg Kaupp is the CEO of ArcherPoint, LLC, a Northern California Microsoft Dynamics NAV (Navision) partner. Greg has been involved in Dynamics NAV implementations for companies throughout the U.S. since 1997.

2 thoughts on “Why is Agile Project Management Better for ERP Projects?”

  1. Could you please share some ideas about splitting backlog into sprints in ERP implementations? ERP processes are highly interrelated and a single function or even a module has no use alone. Take sales of goods as an example: first is budget, then PO, stock intake, warehouse management, delivery of goods, invoicing, payments, tax and P&L reporting. In fact – everything needs to be delivered at once to make MVP. What is your recommendation? How to eat this elephant?

  2. The article is good and revealed the difficulties of waterfall project execution. While for ERP implementation, the big difficulty may reside at business side. The contract is signed with an SOW; the client focuses on delivery on budget; while the delivery team focuses on limiting the scope to avoid incorporating changes and avoid increasing the cost if the client wouldn’t add money.

    Executing a project on “plan” finalized at the beginning is a problem – because frequently there were no correct (far from correct) plans (and designs) until the project is almost finished in creative areas.

    So for outsourcing ERP implementation project, It seems time and materials contracting and mutual trust is the first step for an ERP project to involve agile project management methodology.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.