- October 8, 2019
- Shawn Stamp
- Reading Time: 6 minutes
Given the success of the Agile methodology when it comes to managing custom development projects, it’s no surprise that all of the ERP system integrators (SIs) rushed to adopt it. But in spite of the labels that systems integrators have embedded into their methodologies, it’s important to realize that simply breaking the standard ERP “realization” phase into several “sprints” doesn’t make your project Agile.
One of the biggest benefits of using the Agile systems development methodology is its accelerated delivery of value to the business. Its rigorous adherence to short, time-boxed development cycles, a.k.a. sprints, result not only in incremental delivery of functionality at a faster pace (i.e., realize value sooner rather than later) but also improved alignment of the end product to business needs (i.e., more bang for the buck).
For those not familiar with Agile terminology, one of the most important artifacts of the methodology is the product backlog. The backlog is the inventory of new features, changes to the existing functionality, bug fixes, and even system performance issues that need to be addressed. Each item in the backlog is typically referred to as a user story, and throughout the project, the product owner is responsible to see that:
- New user stories are regularly reviewed and added to the backlog
- Low-value user stories are removed from the backlog, and
- The backlog is re-prioritized in accordance with the changing needs and requirements of the business.
Unlike more traditional “waterfall” methods where the entire list of requirements is assembled, vetted, and approved upfront, the product owner plans each sprint such that it delivers a subset of incremental value/features from the backlog that can be completed with the available capacity. The key differentiator is that the acceptance of the system progresses via multiple increments as opposed to one monolithic event. Again, the philosophy is to drive tight alignment with the business stakeholders by giving them regular input and progress updates throughout the program, versus taking a list of requirements, going away for 24 months, and hoping you got everything right at the end.
What makes Agile so appealing is that the regular cadence of the sprints:
- Focuses the efforts of the development team on the highest value items in the backlog
- Provides regular, pre-defined opportunities to course-correct, and
- Keeps the business stakeholders engaged throughout
Make Sure the Backlog Doesn’t Become a Logjam
As user stories are added to the backlog, each one is assigned an initial number of “points” that indicates the anticipated amount of effort required to deliver it. Simple items receive a low number of points, complex user stories can be one or two orders of magnitude higher, and intermediate ones fall somewhere in between. In addition, each user story is assessed to determine if it is a “must have”, a “nice to have”, or truly a “wish list” item. Every user story in the backlog gets automatically factored into planning of the next sprint, such that each sprint endeavors to deliver the maximum amount of value with the available capacity.
When launching an ERP project, the process of gathering requirements works essentially the same way. Every request/requirement is captured, sized, and prioritized, and the initial scope is then defined in conjunction with your stakeholders based upon all of the “must haves” and some combination of the “nice to haves” and even “wish list” items. This list of requirements establishes the baseline scope for the project and is used to estimate funding, resources, and timing, and from an Agile perspective, becomes the baseline backlog. As with any project, though, it’s important to recognize that scope is not static, such that the final product will vary from the baseline as new stories are added, others are removed, and priorities are reevaluated over the course of the project.
So far so good, but ERP projects introduce some extra complications simply due to their sheer scale. To draw an analogy, when it comes to ERP implementations, you are trying to pilot an aircraft carrier and not a destroyer. They don’t turn as quickly or easily, so your ability to react to a significant change in conditions (weather patterns, approaching threats, new destination/course) doesn’t happen without a lot of extra effort and coordination. As such, when managing the backlog for an ERP program you need to keep the following points in mind:
- Many stories are not optional. ERP systems offer flexibility in terms of configuration options and alternatives, but not in terms of the items that actually need to be configured. If delivery starts to fall behind schedule, you may end up ultimately sacrificing some “nice to haves” or “wish list items” if you aren’t willing to sign a change order to add capacity. Either way, you will end up eroding the value of your business case.
- Your team is inherently less Agile. Unlike most Agile efforts where a single product owner has complete ownership and visibility of the solution, ERP projects are so large that each process team/workstream typically has its own product owner (RTR, OTC, etc.). Whereas a typical Agile project has the ability to pivot quickly in response to changes in requirements (the destroyer), the integrated nature of ERP systems means that changes to one part of the system have the potential to break your business processes. This means that anything that impacts your business process design must be coordinated and validated with each process workstream product owner to ensure cross-functional integrity (the aircraft carrier).
- Avoid an “epic” failure. An epic is a large user story that is broken up into smaller user stories and delivered over the course of several sprints. Sometimes the epic represents a collection of related features, and as such, certain features (user stories) may be optional. Per the previous points, though, ERP systems are much less forgiving in this respect; moreover, many of the individual stories in an epic are prerequisites for other downstream stories and related epics. In particular, conversion and integration epics typically have to wait for configuration epics to complete and failing to take these dependencies into account as you define your sprints can jeopardize and potentially derail your entire plan.
- Beware the “snowplow” effect. As delivery of user stories starts to slip, the incomplete work typically gets pushed into the next sprint; what typically does not happen is the addition of capacity to make sure that nothing else falls behind. As a result, cascading delivery issues can lead to a “bubble” in your project plan due to the immovability of testing and go-live dates. Moving these dates is a herculean, expensive change management problem that is always the last resort, and while your SI might be able to quickly bring on additional resources to catch up on their tasks, understand that you probably don’t have that luxury. You only have so many SMEs, data cleansers, testers, legacy developers, etc., to go around, and so you need to make sure that missed delivery on the part of your SI doesn’t become a capacity problem for you later on.
In summary, there’s a good reason that the SI’s all talk about their “hybrid Agile” methodologies. Even though they are taking a page from the Agile playbook with respect to accelerated delivery cycles and user involvement, development is still constrained by the events and timeframes that are dictated by aspects of integrated systems which lend themselves to “traditional” methodologies. Moreover, it’s important to understand that Agile is successful primarily because of the ongoing involvement of your users and stakeholders, and companies that fail to plan and manage accordingly could end up with some unpleasant surprises (like change orders or delays) as they near the finish line. Here are some things you can do to protect yourself against paying too much for a system that doesn’t deliver the expected benefits:
- Press your SI for a comprehensive, detailed, monthly picture of the resources required from your company and get regular updates from them to understand the impact of any changes. Reprioritizing the work for the project team is one thing but going back to the business with a new demand profile for SMEs and other stakeholders is another.
- Understand what “done” looks like for each sprint, manage your scope to this target, and keep your SI accountable for the delivery schedule. Having contractual schedule controls (i.e., holdbacks) in place is an effective way to keep them on track.
- It is not atypical to see scope increases of 10-15% over the course of ERP projects, so make sure to budget for this contingency versus the baseline backlog.
- Due to the size and complexity of ERP projects, things are going to happen that put your plan in jeopardy. Make sure to set aside some additional contingency to mitigate execution inefficiency as the project wears on. You’re probably going to need it.
Follow me on Twitter @sstamp_ue. Find my other UpperEdge blogs and follow UpperEdge on Twitter and LinkedIn. Learn more about Project Execution Advisory Support.
