Waterfall or Agile? Selecting an ERP Implementation Approach

By
Rossey Charleston
May 9, 2016

When manufacturing companies begin looking at doing an ERP implementation, one of the first questions that needs to be answered after determining which application you will use, is what approach you will take to govern that ERP implementation. Although there is a fairly static set of steps that will need to be taken to successfully implement your ERP system, the approaches you can take to do this are not one and the same. Essentially, the two main approaches companies tend to use to govern an ERP implementation fall under one of two categories: Waterfall methodology and Agile development.

The Waterfall Approach to ERP Implementation

The Waterfall approach is so named because under this approach, each step is supposed to flow seamlessly to the next, like water cascading over a waterfall. In reality, an ERP implementation is a complex project that doesn’t always follow a linear progression. The unexpected sometimes occurs, and requirements can change. However, the idea behind Waterfall is that there are certain steps that always need to happen on an ERP implementation – the Waterfall methodology addresses these. The ERP implementation steps required under the Waterfall methodology include: Discovery: Discovery typically begins during the sales process, and as the name implies, it involves the discovery of what business needs your ERP system will need to address and what you hope to achieve through your ERP implementation. Planning: Planning begins during the discovery phase and continues throughout the whole project. The planning phase involves identification of a project team, meetings with key stakeholders on the project, and documentation that outlines current issues and potential solutions. The outcomes of these meetings and documents will be a project plan that guides the project until it is complete. Design: In the Design phase, the solutions proposed in the Planning phase will be fleshed out. The project team will determine what specific components will be implemented and how they will be configured and used. The project team will also define roles of people involved in the project and document the procedures and methodologies that will be used throughout the ERP implementation process. Development: In Development, the actual nitty-gritty technical work of the ERP implementation process will get underway. The project team will begin preparing for “go-live” by developing the necessary customizations to ensure the applications will work as needed when go-live day comes. Preparing users by providing training, and preparing the data in your current system to be imported into the ERP application are also important milestones that happen during development. Testing: Of course, you want to be sure things work before you go live, so all development work must be tested to ensure it is working properly. As problems are found, they will be addressed and everything will be fine-tuned. The project team users will also get their first peek at how the new system works. Deployment: Go-live, or deployment, happens when all development and testing is complete and problems have all been addressed. The ERP implementation team will make a decision as to whether the system is ready for go-live. The final data will be loaded into the ERP system, with one last check to uncover any problems. Usually, deployment happens over the weekend so as to reduce impact on users and customers. Following a successful go-live, the project team will train users as they begin working in the new system. Support: Just because the system has gone live doesn’t mean your project is over. The system will need support to ensure it continues to meet business needs as requirements change. Updates, upgrades and maintenance of the software will also be required on an ongoing basis.

Agile Methodology: A Sprint to the Finish

The Waterfall approach outlined above was once used on most ERP implementation projects. Over the last 10 to 15 years, however, a new methodology that recognizes the difficulty of managing technology projects over longer periods of time in an environment of change has come to the fore. This methodology is called Agile development, or the Agile methodology, and it has started to replace the Waterfall approach on many ERP implementation projects. Like Waterfall, Agile development requires a great deal of requirements gathering early in the project, and these requirements are used to guide the project plan. However, what Agile projects do with this information and how the project is managed through the Development and Deployment process is somewhat different. Rather than completing all the work in a linear progression prior to testing, Agile divides the project plan into short intervals called sprints. Testing occurs at the end of each sprint, and adjustments are made accordingly, rather than spending a great deal of time doing development for the entire project and only discovering and addressing issues late in the game. Agile, as its name suggests, allows project teams to respond more quickly to issues and changes as the ERP implementation project progresses. It does not assume that the project environment will remain static.

Agile or Waterfall? Pros and Cons

ERP implementations are complex projects for a variety of reasons. The software itself is complex, as are the business environments that can impact these projects. Unfortunately, there isn’t one single approach that works in every situation. There are benefits and problems with both approaches. Waterfall projects may work fine in static business environments, but in a more dynamic environment, such as a company that is growing rapidly or changing its business model, Waterfall can tend to be quite costly if things go wrong or requirements change. With Waterfall, problems may not be uncovered or addressed until it becomes very expensive to fix them. Agile projects, on the other hand, might work better in a more dynamic business environment, but they can tend to run into problems related to planning and resource availability, as that work isn’t done up front. This can lead to delays and missed milestones. Because neither approach is a slam dunk in every situation, it pays to carefully consider which methodology is likely to be the best fit for your ERP implementation, and to have a plan to address the shortcomings of the approach you choose. Are you planning an ERP implementation? Which methodology do you favor? We’d love to hear about it in the comments.