Managing the pipeline of change requests on your ERP program is an essential aspect of effective change control. However, managing scope creep is only one step in ensuring ERP transformation success – you also must hold your SI accountable for the changes made to your program once they are approved.

Controlling the influx and approval of change requests is only part of the picture. It’s just as important to ensure that baselines for scope, capacity, and cost are actively updated as changes are approved.  Otherwise, your PMO will quickly lose the ability to accurately report on status and develop necessary contingencies.  This eventually leads to surprises, delays, and ultimately change orders.  Fortunately, you can establish a solid foundation for effective, integrated change control that will hold your SI accountable by addressing a few specific vulnerabilities as part of the contract:

1. Fixed Price Contracts

Contract costs are tied to delivery of defined scope and solution, not the number of hours delivered.  This includes a fixed-price premium, which is the execution contingency paid to your SI to compensate them for assuming the risk of unforeseen complexity.

Challenge:  The challenge with fixed price contracts is in ensuring that the change orders reflect actual scope changes and not a pass-through of complexity.  While this has historically been a challenge, the introduction of hybrid-Agile methodologies has only exacerbated the problem.

Story point estimates have become the norm in the hybrid/Agile methodologies, but estimates tend to become “moving targets” when the story is actually implemented, even though the scope really hasn’t changed.

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 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 in particular, 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 which are approved through design decisions, 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.

In addition to a clear definition of how new scope will be tracked and managed, 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.  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. Time & Materials Contracts

Unlike fixed-price contracts, cost is ultimately a function of the number of hours delivered. As such, the client is assuming complexity risk at the outset of their program.

Challenge: The challenge with time and materials contracts is ensuring that your SI is delivering in line with productivity expectations. The shift towards Agile delivery means that scope will be managed in terms of story points, but you will be invoiced for hours delivered, not points completed. Thus, it is crucial to keep track of the points completed throughout the program to ensure they align with your expected scope.

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. There needs to be a standard conversion factor (hours/points) 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. Master Conductor

In the case where the SI is made the “Master Conductor,” the SI also has increased levels of accountability for planning and aligning client and any third-party activities.  In other words, even though your lead SI is not responsible for failures or missteps on your part, they are nonetheless responsible to stay on top of potential risks and issues and escalate them appropriately.

Challenge: In addition to the responsibilities of the Program Lead, the role of Master Conductor is additionally responsible for working directly with third parties to plan, manage, and track the entire scope of the project. This added level of accountability 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 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 payment penalties 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, there is typically little in the form of deliverables or metrics that you can use to hold your SI accountable in this regard. 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.