ERP implementations are among the hardest projects that a company will ever undertake. They impact every business process and every user and they require a painstaking attention to detail to ensure that the business continues to function smoothly at go-live.
Any opportunity to simplify and improve an ERP implementation should be taken. With that goal in mind this blog post focuses on some practical ways to blend agile and waterfall methodologies that take advantage of the strengths of each for improved ERP implementations.
Historically, the waterfall methodology has been used for ERP implementations for a number of reasons including:
1. An ERP is an integrated system and the waterfall methodology supports a comprehensive design across all modules before actually configuring, modifying, testing or going live with any module independently.
2. Given the high risk of an ERP implementation, the clear stage gates of the waterfall methodology (e.g., “design before build”, “build before test”, and “test before train” ) promises a way to mitigate organizational risk.
3. Typically an ERP system will be implemented all at once which is a better fit for the waterfall methodology.
4. An ERP project team can be quite large and will benefit from a more traditional project manager and team structure versus the multiple scrum teams and scrum of scrums required under agile.
In spite of the overall strong fit of the waterfall methodology to ERP projects they are still notorious for coming in over budget and behind schedule. Even well executed ERP projects (on time and on budget) often under-deliver against user expectations and/or result in significant disruption at go-live due to missed requirements. These disruptions can be severe and jeopardize short-term, if not long-term, business performance.
These issues are generally caused by the following shortcomings with the waterfall methodology:
– ERP projects are typically long duration and it’s difficult for the project team and key users to remain focused and communicate effectively for this timeframe. Typically, weekly status meetings and status reports are used to track progress but this leaves plenty of time for the team to get distracted between meetings and status reports are rarely effective.
– Completing an accurate and robust design early in the project can be difficult if not impossible. Key users, who understand the business, don’t know the new ERP system and have difficulty participating in design discussions. Similarly, business analysts who know the ERP system don’t yet have full insight to the end users business. This combination results in missed or incomplete requirements that don’t show up until a configured system is delivered late in the project when it’s often too late to react.
– User change management is often lacking with the waterfall methodology. Key users are engaged during the design process to provide information about their business, not learn the new system. The configured system and supporting processes are then delivered late in the project when the users have little time left to internalize the changes.
– Because of the long duration of ERP projects there is a high risk for business requirements to change during this time. The waterfall methodology is fairly inflexible in dealing with these changes since the design is locked in early in the project.
Augmenting the waterfall methodology with agile techniques can help to mitigate these shortcomings. Here are some specific examples where this can be done:
Use daily standup meetings to keep the team focused and improve communication – A 15 minute standup meeting reminds everyone that they need to keep their tasks moving even on a project that takes 8 months or more. Each team member should answer the questions: “What did I work on yesterday?”, “What will I work on today?”, and “what roadblocks do I have?”. The daily standup meetings replace the typical multi-hour weekly status meeting and make it easier to track project status without the need for timesheet status reports.
Use 2 or 3 week sprints to gain commitment and focus on upcoming tasks – Using sprints to manage ERP project tasks has 2 benefits. First, the core project team participates in the sprint planning meetings which serves to regroup and refocus everyone on smaller deliverables and milestones instead of the monolithic milestones (e.g., “design complete”) of the waterfall methodology. Second, the sprint can be used to incrementally deliver user features and functionality during the build phase. This engages end users earlier and more frequently, gets their input well before the official “user test phase”, and mitigates the risk of finding issues too late in the project.
Use a minimum viable product to make sure the design is on target – An MVP is typically used to gain insight on the product design from the customer. For an ERP project an MVP can serve the same purpose by giving the key users a prototype system to review as early as possible. One approach to accomplish this is to choose one or two main scenarios (user stories), setup a “play” instance, configure the ERP to support those scenarios, and manually load real data that the users can relate to. For example, if 80% of a businesses orders follow a common process and flow through the system, then setup the prototype (MVP) to demonstrate that scenario. This prototype won’t have all of the reports or other functionality that will ultimately be required but it will serve the purpose of giving the key users a better understanding of how the new system will work to support their requirements and processes.
Maintain a product backlog – Even though an ERP is an integrated system there will be opportunities to break the requirements down into somewhat independent deliverables. A prioritized list of these requirements can be managed just like the requirements in a new development project. As backlog items are completed they can be delivered to a test or sandbox instance and then ultimately delivered as one complete solution at go-live. Some examples of organizing the ERP backlog include:
– Use prioritized business processes to group requirements on the backlog. For example, if a company’s order flow can be broken down into discrete order types (make to order, order from stock, in-store purchase, …etc), then focus on building out each order type in turn including any upstream (e.g., quotes) or downstream (e.g., MRP / procurement / production) requirements
– Reports or modification requests can typically be designed, built and tested somewhat independently and delivered to users throughout the sprint cycles
– Whole modules such as HR or CRM can usually be separated out and either delivered early or later than the modules required for core transactions
– New or changing business requirements can be addressed through the backlog thus adding flexibility
– Less common requirements or business exceptions may not make it to the top of the backlog and can be handled manually or even outside of the main system on day 1. These can be incorporated into the system at a later date
– Ideas for process improvements are oftentimes better left for a second phase after the initial core functionality is delivered and stable
By blending these agile techniques into the typical ERP phased approach the resulting methodology will be more reactive to changing business requirements, will engage users early and often resulting in more informed users and fewer missed requirements, and will improve project communications. This will help to keep the project on track and minimize the risk of business disruption at go-live.
Do you have other examples of blending agile and waterfall methodologies on your ERP projects? Please post your comments and ideas below.