By Ritvars Mētra, Founder of ReadinessCompassThe rollout is approved. The date is set, the budget is committed, the vendor is engaged.
Nobody has asked whether the teams receiving it can absorb another change this year, because that question is normally asked much later — after adoption disappoints, as a diagnosis. Asked before the decision, it changes the decision: what gets sequenced first, what gets descoped, and which groups need capacity created before anything lands.
Here is how to run that assessment, and why the answer differs depending on whether you are deploying ERP, CRM or AI.
Saturation is a ratio. Most assessments measure half of it.
Saturation is change load divided by absorption capacity. Almost every attempt at measuring it counts the load — how many initiatives, how big, landing when — and treats capacity as a constant, or as a feeling about how busy people seem.
That is why two teams facing an identical portfolio produce completely different outcomes. The load side is covered in what change saturation is and how to know you have too much. This is the denominator.
What absorption capacity actually is
Capacity is not spare hours. It is a structural property of the group, and it is measurable.
William Judge and Thomas Douglas developed a validated instrument for exactly this — organizational capacity for change, in the Journal of Organizational Change Management — built from around 3,600 respondents across 161 organisational units. Their construct is multidimensional, and resolves into three ingredient groups: human skills and resources, formal systems and procedures, and culture, values and norms.
You do not need to run a 32-item instrument to use the insight. It tells you which proxies to collect per receiving group:
- Recent change history — how many changes in the last eighteen months, and crucially how they ended. A group that has absorbed three changes successfully has more capacity than one that has absorbed three abandoned ones.
- Operational headroom — vacancies, seasonal peaks, current utilisation, whether they are running overtime.
- Leadership stability — a team whose manager changed three months ago has materially less capacity, because the reinforcement layer is itself new.
- Prior capability — have they been through a system change before? Experience of surviving one is itself capacity.
- Unfinished business — are previous changes consolidated, or is the group still carrying half-adopted processes?
That last one connects to the definition of the problem. Stensaker, Meyer and Falkenberg define excessive change as arising either from several unrelated changes at once or from new changes introduced before previous ones have completed. Residual load is not a footnote; it is half the construct.
Capacity does not run out linearly
This is the argument that settles the “they are busy but they will cope” conversation, and it is not a matter of opinion.
Queueing theory — applied to development capacity by Donald Reinertsen and summarised well in this overview of flow and queueing — establishes that the relationship between utilisation and delay is non-linear. Moving from 80% to 90% utilisation roughly doubles queue size; moving from 90% to 95% doubles it again. Slowdown begins well before capacity is nominally full.
Transferred to change absorption, that produces a rule most portfolio conversations get backwards. The marginal cost of one more change is not constant. A group at 60% absorption can take another initiative at modest cost. The same group at 90% cannot take even a small one without disproportionate damage — to that change, and to everything already in flight.
Which means the assessment’s job is not to determine whether a group is at 100%. It is to identify which groups are already in the steep part of the curve, because those are the ones where “just one more” is most expensive and least visible.
The assessment, in five steps
1. Define receiving groups, not initiatives. Team, role or site — whatever unit actually experiences the change. This is the single decision that determines whether the assessment is useful, because saturation is a property of the receiver.
2. Inventory all concurrent demand, not just your programme. Every initiative landing on those groups over the horizon, including regulatory work, restructures, system upgrades and things run by other functions. Add residual load from changes not yet consolidated. Most organisations cannot produce this list, and the difficulty of producing it is itself the finding.
3. Weight by depth. A new report is not a new operating model. Weight each change by how much of the role it alters for that specific group — the same severity judgement used in impact assessment, which means an existing impact register is usually the fastest source.
4. Score capacity per group using the five proxies above. Keep it coarse — high, medium, low is enough to drive a sequencing decision, and precision here creates false confidence.
5. Plot load against capacity, by group and by quarter. The time dimension matters as much as the total: four changes spread over a year is a different proposition from four in the quarter containing year-end. The output is a grid, and the groups sitting in the top-right of it are your sequencing problem.
ERP, CRM and AI cost different amounts of capacity
Treating “a rollout” as one unit of load is where most weighting goes wrong. The three most common technology programmes make genuinely different demands on absorption, in different shapes and over different timeframes.
| Demand profile | Where capacity is consumed | Weight it against | |
|---|---|---|---|
| ERP | Broad, deep, mandatory, cross-functional | A short, intense window around cutover and the first period-end | Operational headroom in that specific window; collision with financial calendar |
| CRM | Narrower population, behaviour-heavy, often feels optional | Sustained reinforcement over months, not a cutover spike | Manager capacity and stability over two to three quarters |
| AI | Ambiguous, largely voluntary, governance-sensitive | Attention, trust and judgement — thinly spread and easily deprioritised | Cognitive headroom and psychological safety, not clock time |
The practical consequences differ sharply.
ERP concentrates its demand. A group can be fine on annual average and completely saturated in the six weeks that matter, so assess the window rather than the year — and check the collision with month-end, quarter-end and any regulatory deadline.
CRM spreads its demand thinly over a long period and depends on managers sustaining new behaviour after the launch energy fades. Its binding constraint is rarely the users’ time; it is whether managers have the bandwidth to reinforce for two quarters. A CRM rollout into a function whose managers are simultaneously absorbing a restructure will underperform regardless of the deployment.
AI is the one most often assumed to be cheap because adoption is voluntary and the tool is easy to access. That inverts the real cost: voluntary adoption competes directly with everything else for attention, and it asks people to change their judgement rather than their steps. In a saturated group, an optional change is simply the first thing dropped — which shows up as low usage and gets misread as resistance.
What the assessment should decide
A saturation assessment that produces a red light is not useful, because nobody cancels an approved programme on a heat map. It should drive three decisions that are actually available:
- Sequence. Which groups go in which wave. Saturated groups go later, and the assessment gives you a defensible reason rather than a negotiation.
- Scope. Which modules or capabilities land now and which defer. Reducing depth for a saturated group is usually cheaper than delaying the whole programme.
- Support allocation. Where the change capacity, backfill and hypercare resource concentrate. This is the decision saturation data is best at informing and the one it is least often used for.
And when a group is genuinely over capacity, the options are wider than proceed or cancel: defer that group, descope for them, stagger across waves, create capacity by backfilling or pausing something else, or accept the risk explicitly with a named person accepting it. The last is legitimate. Accepting it silently is not.
Doing it in a day
This does not require a survey programme. A usable first version takes about a day:
- Morning: list the receiving groups; assemble every initiative hitting them over the next four quarters from the portfolio, the PMO and two well-connected operational managers.
- Afternoon: weight each change high/medium/low per group, score the five capacity proxies, and plot the grid.
It will be rough, and it will still be the first time anyone has seen the intersection. Refine only where the first pass shows a problem — the change saturation assessment works through absorption capacity by group in more depth once you know where to look.
One caveat on interpretation. Prosci’s benchmarking has tracked change saturation since 2007, and the share of organisations reporting they are near, at or past the point of saturation has risen to roughly three-quarters in recent waves. Finding saturation is therefore not a surprising result and not by itself an argument against proceeding. The useful output is comparative — which groups, in which quarter, relative to each other.
The question to ask before the date is fixed
Not “is the organisation ready for this?” — too broad to answer and too easy to answer optimistically.
Ask instead: which groups are absorbing this, what else lands on them in the same quarter, how did their last change end, and what would we move if the answer is too much?
If nobody can answer the second part, the portfolio is being managed by initiative rather than by receiver — and that is the condition under which saturation is discovered rather than prevented, one underperforming rollout at a time.
For the governance that stops this recurring, see the PMO’s role in managing change saturation; for why portfolios reach this state, why transformation portfolios fail when they ignore employee capacity; and for separating the system condition from the human symptom, change fatigue versus change saturation.
CRM rollouts carry their own readiness profile — CRM transformation readiness covers what to assess before one.