Hybrid-Agile ERP: Agile is No Substitute for Discipline

When it comes to implementing an ERP system, every systems integrator (SI) has jumped on the Agile bandwagon and is touting their own “hybrid-agile” methodology.  Some approaches are more “agile” than others, but every SI has attempted to leverage what’s best about Agile to transform their ERP delivery methods, processes, and tools.

In contrast to waterfall or more traditional approaches to application development, an Agile approach focuses on delivering functionality or value to the business in regular increments called sprints.  The predictable cadence of sprints helps to drive alignment between your end-users and your project team, because it requires a high level of engagement with your stakeholders throughout the build phase.  This enables you to course-correct and make necessary adjustments as part of the realization process and is why it’s called Agile – the methodology expects and plans for change.

Nevertheless, this flexibility comes at a cost, because an important caveat of the Agile philosophy is that rework is actually expected.  Furthermore, unlike traditional approaches where scope is established up front and development capacity is essentially variable, Agile methodologies are constantly adapting the plan to prioritize changing requirements against fixed development capacity.  These requirements, or “user stories,” get recorded in your backlog, and the sprint plan is constantly being reviewed and tweaked to ensure the user stories with the highest value are getting delivered as soon as possible.

To a certain extent your plan becomes a moving target.  While shifting delivery schedules are simply part of working in an Agile development environment, they don’t dovetail with the “go-live” mentality of an ERP implementation.  That’s where the “hybrid” part of your SI’s ERP methodology comes into play and is why you need to keep the following pitfalls in mind.

Less Flexible Than You Think

When looking at ERP projects from a scope standpoint, there is a “critical mass” that can’t be treated as variable or a moving target.  This means you can’t choose to configure, for example, 80% of your financial user stories simply because users have identified some additional high-value supply chain requirements that they’d like to include in scope.  Much of the initially defined scope is non-negotiable, so unlike a traditional Agile environment that presumes the ability to redefine delivery horizons, any net-new scope is going to translate to additional development capacity if you want to maintain your go-live date.

Furthermore, your timeline is unforgiving when it comes to events like system integration testing, mock conversions, training, and cutover. These essential elements of your project plan each require a high degree of planning and coordination, making them very expensive to replan or move if assumptions change.  For example, you can’t decide to delay the start of system testing simply because one team suddenly realizes it needs an extra sprint to complete required configuration and development.  Or you can’t just shift the cutover date by a week while you wait for another team to resolve its critical defects from UAT.

These restrictions are the drivers behind the “hybrid” part of the SI’s methodologies, because contrary to Agile principles, you can’t simply shift things around by redefining the next increment.  There is an overarching plan that every team must adhere to because everyone has to be ready to move onto the next phase at the same time.  It’s inherently un-Agile, and this rigidity is not something that most Agile teams are accustomed to.

Lack of Planning Rigor

Since Agile is predicated on breaking things down into simple, stand-alone units of work, Agile tools like JIRA were designed to help you efficiently collect and reprioritize your changing requirements over time. This approach works well when scope and timelines are negotiable, but when it comes to building and tracking against an overarching project plan, the inherent bias of these tools can progressively undermine your ERP project.

The issue is that unlike traditional project plans, which are relatively easy to review for gaps and missing activities, any lack of rigor with respect to detailed project planning and resource forecasting tends to get lost amidst a sea of the user stories which intentionally focus on describing atomic units of work rather than highlighting dependencies.  This in turn obscures the critical path and often leads to surprises that you can’t easily recover from.

To be clear, it’s not that getting resource forecasts from Agile tools is impossible.  You can certainly review your backlog and realize that you need additional capacity.  The problem is that the backlog is often incomplete.  It typically captures the breadth and depth of development and configuration activities, which your SI clearly has a significant stake in, but it probably doesn’t contain all of the other tasks and activities that are required to complete your project successfully, especially those that the client is responsible for: test script creation, mock conversion validation, data cleansing, etc.

Put differently, just as if they were maintaining a separate, detailed project plan, your SI should be responsible for getting everything entered into the backlog, including the tasks you are accountable for. Otherwise, by the time you realize you don’t have enough people for integration testing or data validation it will be too late.  Even though your SI probably has the ability to quickly ramp-up capacity to meet their obligations, you probably don’t have that luxury.

Retroactive Change Orders

Another area where an overreliance on Agile techniques can overwhelm your ERP project is governance and scope control.  Once again, Agile tools are designed to help you easily capture and evaluate changing requirements as part of your backlog, and they rely upon a rigorous sprint planning process to provide formal controls and approvals for getting user stories completed.  But when it comes to ERP, the integrated nature of the system means that no single team has the autonomy to approve and manage its own backlog.  Even “simple” stories can have ripple effects on other teams, and without rigorous oversight at the project level, “death by a 1,000 user stories” can quickly overload teams and jeopardize delivery of the MVP (Minimum Viable Product).

Unfortunately, by the time you realize your teams are understaffed and that extra sprints are required to complete the backlog, it’s often too expensive to reverse course.  The result is a change order which is essentially a retroactive invoice, because instead of paying for additional scope that has been jointly agreed to, estimated, and planned, you are just getting billed for work that has already been done.  This makes it virtually impossible to hold your SI accountable, since recovering the original MVP still means backing out work that has already been done.  You’re going to pay either way, so most projects simply have no choice but to pay the bill and forge ahead.

Clarity and Discipline

While the adoption of Agile precepts and tools can facilitate the delivery of a system that better meets the expectations of your users and stakeholders, it does not obviate the need for tried-and-true project management disciplines when it comes to ERP projects.  You need to coordinate multiple teams and workstreams to make sure that everybody is ready to cross the finish line together, which means that governance and planning cannot be afterthoughts or byproducts of the process.  As such, you need to structure your RFP and orals to make sure you have clarity on the following questions:

• How will the SI keep project plans and resource forecasts evergreen?
• How will the critical path be tracked?
• Who owns the backlog and how will approvals be managed?
• How will the SI track the definition of the MVP and ensure its delivery?

The Bottom Line

In short, a solid project plan and tight control over scope are the best means of keeping everyone moving forward together.  But while having a process is one thing, making sure your SI follows it is quite another.  So, before you sign the statement of work, make sure it includes the following provisions:

• • Your SI should be responsible to deliver a comprehensive, weekly forecast of the tasks and resources that are going to be required for the project team to meet its obligations and responsibilities in the contract…not just their own.
  • Your SI should be dedicating senior, experienced resources to lead the change control process. They need to be individuals with cross-functional understanding of the solution who are able to assess the impact of every change / new requirement.