- April 9, 2024
- Shawn Stamp
- Reading Time: 5 minutes
Complex ERP transformation initiatives can leave room for misalignment of your SI’s roles and responsibilities, resulting in delays and costly change orders. Creating a system of SI accountability that ensures they are providing accurate estimates for your program is the key to a successful initiative.
Undergoing an ERP transformation program comes with an array of complexities and considerations. More specifically, your PMO should be concerned with ensuring that the process and reason for issuing change orders in your transformation initiative is clear, regardless of the type of contract you have in place or the role your SI is playing. Having a process in place to ensure your SI understands the complexity of your program and the resources needed to deliver on your agreed upon scope is critical in minimizing the chance of a change order.
Here are some specific vulnerabilities to address as part of your contract to establish a solid foundation for effective, integrated change control that will hold your SI accountable:
1. Maintaining Clear Change Order Provisions in Fixed Price Contracts
With Fixed Price Contracts, project cost is tied to delivery of defined scope and services rather than the actual number of hours required by the System Integrator (SI) to deliver it. In other words, the risk that your solution will be more complex to deliver than expected is being assumed by the SI.
In exchange for this price certainty, though, Fixed Price Contracts include a fixed-price premium. While the percentage of the premium can vary, it represents the execution contingency paid to your SI to compensate them for assuming the risk of unforeseen complexity.
Challenge
Every methodology includes a change control process for reviewing, approving, and integrating the flood of change requests that typically come with large, transformational projects. With fixed price contracts, though, it is vital to ensure that the change requests reflect actual scope changes and are not a pass-through of complexity tied to the original scope.
This has historically been a challenge, and the introduction of hybrid-Agile methodologies has only exacerbated the problem. The problem is that once the original scope is translated to a backlog with an expected number of story points, that baseline can get quickly lost as new stories are added, and existing stories are split into a group of related stories.
For example, one 50-point story might get broken down into four new stories of 15 points each for the purposes of developing a balanced sprint plan; this is a 20% increase in story points without a corresponding increase in scope. Alternatively, new stories might be added in support of other stories by way of unforeseen complexities or technical prerequisites that may not constitute additional scope.
Mitigation
For fixed-price contracts, it is critical to include clear provisions in the contract for when the SI is able to issue a change order. The discovery of new requirements that are approved through the change control process, not just an increase in story points, should be the standard. Moreover, there should be a master list of requirements that all user stories are linked to. Unless new stories are in support of approved new requirements and design decisions, they should not be counted as new scope.
Finally, it is a good idea to take regular snapshots of your backlog and requirements traceability matrix so that you have a record of how scope has changed over time and why. These resources are your best form of insurance against retroactive change orders, and at a minimum, you should have snapshots at the ready from pre/post design and at the conclusion of each sprint and testing cycle.
2. Ensuring Proper Estimates of Delivery Hours in Time & Materials Contracts
Unlike fixed-price contracts, cost is ultimately a function of the number of hours delivered. As such, you are assuming the risk of unforeseen complexity rather than your SI. While there are contractual provisions that can mitigate the risk of an “open checkbook,” it is even more important to hold your SI accountable to their initial proposal, particularly their assumed productivity standards.
Challenge
Although the shift towards Agile delivery means that scope will be managed in terms of story points, you will still be invoiced for hours logged regardless of the points delivered by those hours. In other words, if you get billed $100 in month 1 for the delivery of 100 story points, but by month 4 that same $100 is only delivering 70 story points, it only takes 3 months of “month 4” productivity to add another actual month to your project timeline.
Thus, just as baselines and snapshots of scope are essential to holding your SI accountable under a Fixed Price scenario, developing baselines for assumed productivity and then measuring actual performance is vital for accountability under a Time & Materials contract.
Mitigation
Effort estimates should not just be for development time, but should include capacity for the SI system testing, change management, training, knowledge transfer, and support. These estimate breakdowns enable you to develop KPIs by work-stream (hours/point) that you can be contractually established up front and used for every estimate. This will give you the ability to measure delivered hours against delivered scope, protecting you against productivity gaps on the part of your SI’s delivery team.
3. Expecting Comprehensive Estimates and Change Requests When Your SI is the Master Conductor
While your SI typically owns the development and maintenance of the project plan, making them the “Master Conductor” increases their level of accountability for delivery of the entire project by considering all participants–including the client as well as any third-parties–in the ongoing planning and management of the project. In other words, even though your lead SI is not responsible for failures or missteps outside of their control, they are nonetheless responsible to stay on top of potential risks and issues and to help manage them appropriately.
Challenge
In multi-vendor situations, your lead SI may not be as motivated to work with third-parties to define an integrated timeline that is both realistic and complete. This can lead to a misaligned plan that is setup for failure, which subsequently results in a change order.
Moreover, whereas SIs are fairly diligent in logging risks and issues that impact their ability to deliver, they may not be as vocal about perceived risks that impact client or third-party responsibilities. By making them Master Conductor, they become additionally responsible to consider the entire project, which ultimately reduces the likelihood as well as the impact of change orders when third parties do not perform. Not because the Master Conductor is now responsible for delivering, but because they are responsible to ensure it doesn’t get to that point.
Mitigation
Every estimate and change request provided by your SI needs to be comprehensive. Estimates should reflect the expected impact on client staffing requirements, account for any changes to any third-party staffing, and forecast any changes to schedule or budget. The scope of these responsibilities should be explicitly included as part of the contract, along with change order limitations linked to failure to serve in this capacity.
The Bottom Line
Every SI brings a change control process to the table as part of their methodology, but even the best process will fail if execution does not result in a “closed loop process” that feeds back into the other PMO activities. Furthermore, failing to acknowledge how your SI’s role could change in different contract scenarios can leave you vulnerable to misaligned expectations of the change control process and, ultimately, costly change orders. But with a few contractual changes and a little discipline, you can help to ensure an effective and integrated change order process that keeps your program running smoothly.
