Can Your Team Handle the Next ERP Rollout? Include preparation, launch, support and everyday work.
An ERP rollout can look comfortably phased on a release calendar while the same people are overloaded throughout it. The first site is still asking for help. The second needs practice and data validation. The third wants design decisions. A shared finance lead, integration specialist, or operations supervisor appears in every plan.
Sequence waves using a role-level view of demand. Include preparation, launch, stabilization, and ordinary business work in the same picture. A technically ready release may still need to wait if the people required to operate and support it cannot absorb the next change safely.
The practical tool is a change-load map linked to wave-entry conditions. Its purpose is to reveal overlapping obligations early enough to adjust scope, timing, staffing, or support. It should support a decision about the next wave, rather than create a numerical score that disguises uncertain capacity estimates.
Start with roles and responsibilities, then resolve scarce or highly specialized roles to named people where necessary. A broad label such as “finance team” can conceal a dependency on the only person authorized to make a particular decision.
Map who designs, prepares data, approves access, practices tasks, validates results, supervises launch, and handles exceptions afterward. Include local staff and shared services. A wave at one location may create work for a central team that is already supporting another location.
Look for hidden dependencies on trusted experts. They may be invited to every workshop, asked to review every procedure, and contacted informally when a task goes wrong. Their scheduled project allocation can understate the demand created by the program's operating habits.
Keep backups visible. A second name counts as useful coverage only if the person has the knowledge, permissions, time, and authority needed for the duty. Listing someone who must ask the primary expert every question does little to reduce the underlying dependency.
Use a common time scale that matches meaningful operating decisions. For each role or scarce person, record four kinds of demand:
Show when work is expected to occur and how flexible it is. Some preparation can move earlier. A physical inventory, a business cutoff, or a required approval may have a much narrower window. The map should distinguish movable demand from fixed constraints.
Estimate effort with the people who do the work. Record assumptions and uncertainty rather than pretending that every support question can be predicted. Separate scheduled effort from interrupt-driven demand, because the latter can fragment time even when its total duration seems modest.
A calendar milestone can close a deployment while substantial operating work continues. A prior wave may still require daily reconciliation, guided task completion, unresolved defect work, or temporary manual controls. The next wave inherits competition for the same support capacity.
Define what it means for the previous wave to release resources. Relevant evidence may include stable execution of critical tasks, support demand that the permanent team can handle, completed reconciliation, and removal or ownership of temporary workarounds. The accountable business and support owners should determine the acceptable conditions.
Avoid using the passage of a fixed number of days as the sole evidence of stability. Time since launch says little about whether a team is working independently or relying on exceptional help. Likewise, a low incident count can be misleading if staff avoid unfamiliar tasks or report problems through informal channels.
Make continuing obligations explicit. If an expert is released only for part of the week, record that capacity accurately. Do not move the person's entire allocation to the next wave while leaving the previous team with an implied promise of unlimited access.
When demand overlaps, identify the specific work at risk. “The team is stretched” is too broad. “The same supervisor must validate closing balances and coach the next site's first transaction cycle during the same operating window” gives the program a decision it can resolve.
Compare options rather than assuming the next wave must simply slip. The program might move preparation earlier, reduce a wave's scope, split a site group, add qualified coverage, postpone lower-priority work, or change the sequence of locations.
Each option has consequences. Smaller waves can reduce immediate load while increasing repeated transition overhead. Added support can help with routine questions but may not replace scarce decision authority. Delaying a wave can protect operations while extending temporary arrangements or contractual commitments.
Record the chosen option, the demand it removes, and any new dependency it creates. Then update the map. A mitigation that exists only in a meeting note should not be counted as available capacity when the wave-entry decision is made.
Agree the evidence required to start the next wave while there is still room to change the plan. Include technical readiness and human operating capacity in the same decision packet, with separate owners for each.
A practical gate can ask:
Use evidence with a date and an owner. A readiness statement from several weeks earlier may no longer reflect absences, a changed design, or unresolved support demand. The gate should show what was checked recently and what is still an assumption.
Consider a hypothetical rollout across three distribution sites. The first site's local team is learning a new exception process. The central inventory specialist also owns data validation for the second site and design review for the third.
The release calendar shows three separate waves. The change-load map shows that the specialist is expected to provide daily coaching, complete validation, and attend design workshops in the same period. A nominal allocation to each wave would hide the collision.
The program reviews the work. Routine coaching can move to a trained local lead, but certain reconciliation decisions still require the specialist. The second site's validation can be brought forward only if its source data is ready. The third site's workshop can move without affecting a critical dependency.
The revised plan transfers a defined coaching task, retains specialist coverage for reconciliation, confirms the data prerequisite, and reschedules the workshop. The wave proceeds only if the local lead demonstrates the required capability and the earlier site's remaining demand fits the revised arrangement.
This is an illustrative capacity decision, not evidence that the same remedy will fit every rollout. The important step is making the collision and the conditions of the remedy visible.
Create a short review after meaningful operating cycles in each wave. Separate lessons into reusable improvements, local adaptations, defects, and proposals that change the approved scope. Give each category a route and a decision owner.
A clearer job aid may be adopted quickly after review. A changed approval model may require broader design and control decisions. A site-specific exception should not automatically become a requirement for every remaining wave.
Identify which lessons invalidate preparation already completed. If a process changes, affected users may need updated practice. If a data rule changes, validation may need repeating. Include that rework in the load map rather than counting it as a free benefit of learning.
Version the common rollout materials and maintain a concise change log. Local teams need to know which instructions apply to their wave and whether a later improvement changes their own operating procedure. Uncontrolled variations can increase support demand just when the program expects it to decline.
Review task performance, recurring exceptions, reliance on temporary controls, and support aging alongside the capacity map. A team may meet transaction deadlines only because a small group is absorbing unsustainable effort. Ask managers how the work is being completed, not just whether it is complete.
Escalate when a wave's assumptions no longer hold. Relevant triggers might include the loss of a critical backup, unresolved reconciliation, repeated failure of an essential task, or support demand that exceeds the agreed coverage. Set the actual thresholds and authority through the program's governance.
Do not treat a pause as the only available response. A bounded change to sequence or scope may protect the outcome. Equally, do not call a release ready because people promise to work harder. The decision should rest on a credible operating arrangement.
Before approving the next wave, ask one concrete question: who is still carrying the previous wave, and what evidence shows they can take on the next one? A clear answer can prevent the release calendar from getting ahead of the organization's capacity to change.