The Science Behind Why Agile is Better for ERP Projects
Have you ever wondered why Enterprise Resource Planning (ERP) Projects almost always go over budget, take longer than originally scheduled, and deliver less business value to stakeholders than expected? I can tell you I have. Having spent more than a decade implementing ERP projects for clients I was constantly wondering why our industry continued to deliver projects the same way with predictable results. I believe that is Einstein's definition of insanity.
Several years ago I became convinced that there had to be a better way and went on a quest believing there had to be someone out there asking the same questions I was and hopefully providing some answers. Thankfully I came across Ken Schwaber and Mike Cohn. In their books Agile Project Management with Scrum and Agile Estimating and Planning I saw them wrestling with exactly the same questions I had been asking. What I discovered was that the challenges besetting most ERP projects could be easily understood in the context of industrial science and process control models.
There are basically only two major approaches to control any process. There is the defined process control model and empirical process control model. What our industry has used since the beginning is the defined process control model which is often characterized as the Waterfall Methodology. The Waterfall Methodology is simple and linear. The steps are as follows: Analysis, Design, Development, Testing, and Deployment. The process seems so straight forward and intuitive what could possibly go wrong? For those of you who have been through an ERP implementation it was probably characterized by some common traits. In projects that are managed well according to the Waterfall Method there is extensive planning and analysis that precedes any solution design. The results of all of this effort are typically communicated in an exhaustive Functional Requirements Document. Once this document is agreed upon and signed off on then the team involved in the analysis will hand it off to a more technical team to begin working on the actual design of the solution. This is usually communicated back in an Enterprise Design Document. Once this is agreed upon and signed off on then the developer's disappear to begin coding the solution that will eventually be delivered to the project team for testing.
If this Waterfall process is at all familiar then I'm sure that what I'm about to say next will be as well. I'm guessing that the first time you saw the result of months of analysis, design, and development your response was more often than not how could they have possibly gotten this out of what we said. Unfortunately even when the process is followed perfectly you uncover all of the assumptions that could never be fully articulated in the requirements and design documents that have now resulted in the delivery of a product that is unusable at worst or at best just disappointing. You probably have also seen the situations where everyone does exactly what they said and agreed to do only to find out that months later the resulting solution no longer met 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. This type of defined process control can be easily understood in the context of a chemical plant. If there is a problem with the output then all that needs to be adjusted are the variables and inputs to achieve the right output. The key factor in controlling the output in a defined process control model is that you control all of the inputs. 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. 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.
Any time there is any amount of uncertainty at the beginning of a process it is important to use an empirical process control model to achieve the optimal outcome. The best way to describe the empirical process control model is with the analogy of tracer bullets. The whole idea of firing tracer bullets is to use something that is inexpensive and repetitive to quickly lock in on the optimal target. This is what an empirical process control model or an agile method is all about. I'm guessing that if you think back to the most successful ERP projects that you've ever been involved in there was lots of prototyping, it was highly collaborative and iterative to ensure that an optimal outcome was achieved at least cost. An agile method takes into account the fact that most teams will gain insight and information as a project progresses that would act to significantly improve the quality of the outcome if properly incorporated. Agile methods put a framework and a structure around these iterative feedback loops which can ensure a consistent delivery of business value at a consistent rate.
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.
My hope is that our industry begins to take a critical look at how projects are delivered and understands that there is a scientific basis for why projects will continue to fail 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.