One of the big complaints about ERP implementations is that they take so gosh darn long. Even with a great team, you’re looking at many months of planning, decisions, and strategy execution before you’re ready to go live. Part of the reason for this is because traditionally, ERP implementations have followed what they call the “waterfall” method of project management. But recently, some industry experts have been pushing for ERP implementations to adopt the agile method: they argue that this method is faster, more adaptable and provides a better final product. So we have to ask. When it comes to ERP implementation, is it better to follow an agile or waterfall methodology?
The waterfall method
The waterfall methodology is what you might call the “traditional way” to implement an ERP: you gather requirements, create a plan, do the work and present a complete, operational final product. Each phase of the project has a start and end point, and work on the next phase doesn’t begin until the current phase is complete - hence why it’s called “waterfall”.
In ERP implementation, the waterfall methodology might look something like this:
A lot of the work, and a lot of the decisions, happen in the planning phase. This is traditionally where the team gets input from the project sponsor and any/all stakeholders on what they want the project to look like: what they need, what they want, and so on. From there, the team creates a project plan and gets to work.
The problem with the waterfall method is that as time goes on, requirements may change… and in waterfall, there’s no mechanism to make changes/updates to requirements as the project moves forward. This means that the final product, despite everyone’s best intentions, might not work the way it should - even if it meets all of the original requirements. This is when scope creep can happen, leading to longer timelines, increased budgets, and less planning — which all increases the likelihood of a failed ERP implementation. When timelines are measured in months (or even years in some cases), there’s a high probability that requirements will change as time goes on. And if the client isn’t willing to set their requirements in stone, chances are that they will add to the scope of the project as time goes on.
But with that said, there’s a reason the waterfall method is so popular: it makes sense to everyone. Most people instinctually understand the waterfall method because it’s linear: you complete step A before moving on to step B, and continue on the path until you reach your destination. It provides structure, which is something you really need in a large, complex project like ERP implementation.
Benefits of waterfall
- you present a complete, finished product
- clear start and end lines
- gives your project structure
- easy for everyone to understand
Drawbacks of waterfall
- time consuming
- difficult to make changes to requirements
- higher chance of scope creep
The agile method
Agile, as the name would suggest, is faster and more flexible than waterfall. The big difference between waterfall and agile comes in the development and deployment stages. Instead of trying to present a full, finished product all at once, the agile methodology focuses on what’s most important right now.
Think of it this way: if waterfall is like writing a novel, agile is like writing a book of short stories.
The goal of agile is to get the system operational as quickly as possible, and add on to the frame as time goes on. If invoicing needs to be up and running before the rest of the system, then the team prioritizes invoicing. If inventory management is of critical importance, the team focuses on inventory management.
Agile teams break work into small increments, called sprints, that minimize the amount of up-front planning and design. The team works on all functions (planning, development, deployment, testing and so on) during the sprint. At the end, they have an operational piece of the larger ERP puzzle ready to go.
One by one, the team builds the pieces that create the whole system. And because they’re focused on one piece at a time — instead of working on the project as a whole — the client has more flexibility to change and refine their requirements as they learn more about what their new ERP system can do.
Agile is faster and more flexible, sure. But that doesn’t mean it’s the right choice for every ERP implementation. If you’re working with a team who’s never used agile before, there could be a learning curve. If you’re working with a team who has limited time resources, they may have trouble completing tasks in the sprint cycle. One of the biggest drawbacks of agile is that it’s hard to estimate up-front how much time and resources a project will take, since project requirements can change drastically from the beginning to the end of the project.
Benefits of agile
- projects implemented faster
- go-live sooner, because you keep working on the project after go-live
- more flexibility with regards to features, requirements
- more collaboration with the customer
- higher chance of the customer being pleased with the final product
- more focus on the high-priority work
Drawbacks of agile
- not as structured
- go-live with an incomplete, “bare bones” product
- may have a learning curve with people used to waterfall
- tighter deadlines
Which to choose for your ERP implementation?
The answer is use both. If you’re following the implementation strategy provided by your ERP, you’re most likely using both waterfall and agile methods at the same time: SAP, Oracle, Infor and many other ERP providers use a combination of both methodologies in their implementations.
In order to meet the requirements of a predictable project—in terms of time, cost and requirements fulfillment—a gated approach is needed. Most, if not all of the vendors, use five Tollgates to present the readiness of the solution to the sponsors:
- Gate 1: Project Define
- Gate 2: Solution Defined
- Gate 3: Solution Ready [conference mode]
- Gate 4: Solution Implemented [site readiness go-live decision]
- Gate 5: Project Completed.
Between the gates are phases where value is being added to the solution. In each phase an agile approach is sometimes preferred. But it’s vital that you never ever run agile sprints over a Tollgate.
If your company is changing rapidly and you’re not sure your requirements will be the same a year from now, you might want to try an agile ERP implementation in the phases between the Tollgates. That way you can prioritize features and make changes to project requirements if/when you need to.
If your company has firm requirements and they value structure, you might want to purely follow the waterfall methodology. It might take a bit longer to get to the deployment stage, but your implementation project will have much more structure, stability and documentation.
The methodology you choose also depends on your implementation team. It’s pretty safe to assume that they’re comfortable with the waterfall method, as it’s the “traditional” method. But are they familiar and comfortable with agile? Would they prefer to follow agile? Is there a consensus among your implementation team as to how they’d like to work? These are all questions you need to ask before choosing the right implementation method for your team.
A few days ago, we asked our LinkedIn followers which method they prefer. Want to weigh in? Join the discussion here.