We all know that ERP implementations are tricky things. From 2012 to 2016, 55% of implementations exceeded their planned budgets and 66% took longer than planned. But...why? ERP isn't exactly a new concept and you’d think, by now, there'd be a consensus on the best, easiest, and cheapest way to implement. Clearly, that isn’t the case. While there are many possibilities for these troubling statistics, let's consider one that shows up in nearly every result when you Google "why ERP implementations fail": project management. And more specifically, how best to approach an implementation timeline. Should you go waterfall, agile, or something in between?

Why Waterfall?

Waterfall approaches have traditionally been favored by companies with simpler, static business practices. It's easy to see why this concept is alluring. Project owners have a strong belief that they understand how their business works, so why not just get all the planning for each process out of the way and get going already! But, as the name suggests, once you start going down a waterfall, there's no going back up – at least not without extreme effort and pain. In fact, the more complex a technology project is, the more wasteful it is to write exhaustive requirements upfront.

A waterfall approach also doesn't handle change very well and issues seem to most often appear at the very end. So, any expansion of scope, any process that didn’t make it into the initial planning, any deviation at all from the original plan is going to end up costing you. You also run the risk of finding out in the CRP (at which point go-live is imminent and most of the budget spent) that there are critical problems with the system that must be addressed. Finally, waterfall processes often assume that both a problem and its solution are contained in the same area. Well, you know what they say about assuming things... This operation-centric approach struggles to encompass multiple divisions involved in any given business process.

Waterfall deployments do have some positive aspects. For one thing, expectations are set early on regarding deliverables, making planning and designing more straightforward. Additionally, there are relatively clear benchmarks to measure progress. Finally, for businesses that don't have many internal resources or stakeholders that are in different physical locations, after the requirements phase there is little need for input from the client until the very end of the project. But these benefits rarely outweigh the potential risks in moving forward with a waterfall approach.

Agile Deployments Suit More Complex Projects

On the other hand, a traditional agile implementation approaches each business process iteratively and considers how multiple business units may impact any given process. Instead of finding issues at the end, they can be addressed during multiple rounds of testing and design. For a more complex and dynamic business, an agile implementation gives the company more opportunities to ensure that the software accurately represents the business both at the outset of the project and at the end.

An agile approach isn't without its own challenges. Although it is almost always better to have more input from the business at each stage, traditional agile deployments require a high degree of involvement, someone who is completely dedicated to the project, and teams that are in the same physical space. For many organizations, this is simply not possible for a wide variety of logistical, practical, and who-only-does-ONE-thing-in-their-role-anymore reasons. Additionally, because of the frequent reprioritization of a traditional agile deployment, it's possible that not every sprint would be complete by go-live and it can be hard to track progress.

Hybrid Deployments = Best of Both Worlds

That leaves us with a hybrid approach that takes the best of both methods. A hybrid method defines the work upfront, borrowing defined phases of development and high-level requirement setting from the waterfall approach. Frequent iteration, testing, and cross-divisional engagement are added from the agile method. Combined, businesses can take advantage of a clear project roadmap with concrete, achievable phases where progress is easy to track, yet still flexible enough to accommodate any unforeseen challenges or changes to the business. All while exposing and engaging end users to the new solution for as long as possible (another well-documented key to implementation success) through frequent, but not all-consuming, check-ins.

This hybrid approach recognizes that any project with the scope and complexity of an ERP implementation is about more than just developing software. It's about addressing broad operational concerns and transforming the business, so it can tackle challenges today, tomorrow, and years from now.

Ultimately, each method has its own pros and cons and it is up to the organization, along with a trusted partner, to determine which method is the best fit.