An AI rollout should earn a place in the same capacity plan as the system migration, service deadline and reorganization already affecting its users. Compare the demands on specific people during specific weeks, then decide what to move, narrow or cover. A small pilot can still be badly timed if it needs the two experts already keeping another change on track.
For leaders coordinating several departments, the useful question is whether the proposed work can be supported without quietly borrowing time from another commitment. This is one of the practical decisions within people and change in AI adoption.
Find the people shared by several changes
Start with the people who must learn, review, troubleshoot or explain the new workflow. An organization-wide project count can hide the fact that three initiatives all need the same finance specialist, service supervisor or IT support team.
Prosci's discussion of AI change fatigue distinguishes the disruption people experience from their capacity to absorb it. It also warns that AI-related changes can arrive outside a planned project. That is a useful planning lens, rather than a validated formula for how many changes a team can safely handle.
A concrete version of this tension appears in an IT manager's Reddit account. The manager described rebuilding an underfunded IT function while executives wanted Copilot and deeper integrations with their business systems. Data foundations still needed work. The proposed response was a role-specific pilot before broader licensing. This was a request for advice, not evidence of a successful rollout, but it makes the sequencing problem visible.
For each affected group, ask about four demands:
- Ordinary service. What work must still be completed, and when does demand peak?
- Transition work. Who tests the replacement system, cleans up records or runs old and new processes together?
- Learning and review. Who practices the AI task, checks its output and resolves uncertain cases?
- Support after launch. Who handles questions and repairs while the next group gets started?
Keep the last category on the calendar after go-live. A launched system may still need the same people you were planning to assign to AI.
Put the collision on a team calendar
Suppose a university enquiry service is replacing its customer relationship management system, which stores enquiries and their follow-up history. The change falls near peak intake. Its AI proposal is modest: help advisers draft answers from approved public course information, with an experienced adviser checking dates, requirements and links before anything is sent.
Two experienced advisers are also needed to test the new enquiry system and help colleagues resolve problems after launch. Recruiting a small AI pilot group does not remove that shared dependency.
Bring the enquiry manager, migration lead and AI lead together around the same near-term calendar. Include named people in the working version. This simplified example shows the collision they need to resolve.
| Work needing the experienced advisers | Week 1 | Week 2 | Week 3 |
|---|---|---|---|
Enquiry service | Cover peak intake | Cover peak intake | Check remaining enquiry backlog |
System replacement | Test enquiry histories | Support launch and resolve errors | Support unresolved cases |
Proposed AI pilot | Prepare checked examples | Train pilot group and review drafts | Review pilot results |
The problem is Week 2. Service coverage, migration support and AI review all depend on the same advisers. Moving a training invitation is easy; finding someone qualified to check a course answer may be harder.
Add the expected effort and available coverage with the people doing the work. Record uncertain estimates as ranges and revisit them. Avoid giving the whole department a reassuring capacity percentage when one indispensable reviewer is unavailable.
The calendar is a discussion aid. It cannot tell you how demanding an unfamiliar task will feel or whether employees trust another launch promise. Ask what is still difficult about the previous change and which assumptions in the new plan look unrealistic. Then change the commitments where the answers warrant it.
Choose what moves and what stays
Once a collision is visible, compare changes to scope, timing and support. Each option has a cost, and more than one may be needed.
| Option | When it can help | What the decision must include |
|---|---|---|
Move the AI start | Essential reviewers are committed to a fixed deadline | A return date, restart conditions and the cost of waiting |
Narrow the pilot | Some useful work can proceed without the constrained people or systems | The smaller task, available reviewer and limits on use |
Add experienced cover | Ordinary service can be handed over safely | Funding, onboarding time, access and who checks the handover |
Move another change | Its deadline is more flexible and AI has a stronger near-term case | The other owner's agreement and the consequences of delay |
In the university example, the leaders might postpone live AI drafting through peak intake. The AI lead can prepare public-information examples without asking the advisers to review them during migration launch week. Restart depends on the enquiry backlog and unresolved system cases allowing protected review time. Preparation continues, but the pilot has not secretly started.
Extra staff can be a real option when they relieve the right work. In a Cherry Bekaert case study, a residential-services company running two systems during an enterprise resource planning transition brought in four temporary accounting professionals to support receivables and general-ledger work. This is the staffing provider's account of an unnamed client, not an independent AI evaluation. It illustrates targeted operational cover, without establishing that hiring is always the best answer.
Cover also takes time to arrange. An additional person who needs the overloaded expert for every decision may not relieve the immediate constraint. Agree what the person can take over independently before counting the capacity as available. For individual practice arrangements, use the more detailed guide to making time for AI learning.
Count the cost of waiting without spending imaginary savings
Postponing AI can have costs: useful learning arrives later, a recurring manual task continues, or a workable improvement misses a seasonal opportunity. Make that case concrete enough to compare with the competing deadline. An untested promise that AI will save everyone time is not available capacity for next week's launch.
There is a useful counterexample in the same Reddit discussion. Another Reddit user described introducing policies, training and a rollout with realistic expectations, then gaining time and budget for a larger data project. The account is unverified and does not quantify the benefit. It supports considering a limited rollout alongside foundation work, rather than treating complete modernization as a prerequisite for every AI task.
The UK Department for Work and Pensions' Copilot evaluation also captures both sides. Interviews described work pressures limiting exploration, while some users reported redirecting saved time to other work. Others found that checking outputs reduced the benefit. The trial concerned corporate staff, and its self-reported findings, nonrandom licence allocation and lack of a baseline limit causal conclusions.
Test whether the particular workflow releases usable time for the constrained people. Faster drafting by one group does not free a different group's reviewer. If a small, supported trial can resolve that uncertainty without disrupting the fixed commitment, it may be worth running. If the trial itself needs the unavailable expert, expected future savings cannot fund that expert's current time.
Give a pause a return condition
The leader responsible for the affected service and the owners of the competing changes should agree the tradeoff. If they cannot resolve it within their authority, escalate the named conflict to a sponsor who can change scope, funding or dates. The guide to negotiating AI budgets and decision rights covers that agreement in more detail.
At the next review, compare the plan with what happened: service backlog, unresolved transition work, actual reviewer availability and the questions employees still need help answering. A drop in AI use during a planned pause needs different interpretation from someone trying a tool and abandoning it. Preserve that context when reviewing activation and retention.
Questions about AI rollout capacity
Does AI have to wait until an ERP rollout is finished?
No. An AI task may proceed alongside an enterprise resource planning rollout when its data, reviewers and support are available and the two activities do not compete for essential capacity. A task that relies on unstable records or the migration team's busiest specialists may need to wait. Map the actual dependencies and compare a narrower pilot with delay using the scope, timing and support options.
How many simultaneous changes are too many?
There is no universal safe count established by the evidence used here. One major system replacement can occupy a team's key reviewers, while several smaller changes may affect different people. Assess the work by affected role and week, including ordinary service and post-launch support. Use the team calendar example to find conflicts, then confirm the estimates with the people doing the work.
Who should decide which change gets priority?
The decision belongs with leaders who can change the affected commitments, informed by the teams doing the work. The AI lead should bring a specific proposal and its cost of delay; the service and other project owners should identify what would be displaced. If their authority is insufficient, the sponsor must resolve the conflict. Record the agreed scope, capacity and return conditions so employees are not left to satisfy incompatible promises.
