Industry
Part of Reading change management with a sceptical eye
The change management trends that will still matter next year
Five change management trends for 2027, from change saturation to process mining, and what each one asks operations teams to do differently.
Change management stopped being a communications job. The trends that will still matter next year all push the same way: fewer simultaneous changes per team, more measurement of whether a change held, and a named owner on the day the switch happens.
What to take away
- Change saturation is now a planning constraint, not a complaint. Teams plan a switch date and forget the recovery weeks that follow it.
- Change registers are moving from project offices to operations. The useful version sorts by the team carrying the load, not by the sponsor paying for it.
- Adoption measurement is replacing go-live as the finish line. A change counts as done when the old process stops being used, not when the training ends.
- Process mining is the fastest-growing way to find that out, because it reads the system log rather than asking people what they do.
- Every trend below assumes a named owner on the day of the switch. None of them works without one.
Trend 1: change saturation as a capacity number
Saturation used to be a word people used in retrospectives. It is becoming an input to the annual plan.
The arithmetic is simple. Take the last four changes a team absorbed. Estimate the weeks each one left output below normal. Add them. If the total approaches the length of the period, that team has been in continuous transition, and the next change lands on a team that never returned to baseline.
The practical rule most operations groups settle on is one significant change per team at a time, with the next starting after the degraded period ends rather than after the switch date. That rate is slower than most annual plans assume, and it is the real one.
Trend 2: the change register moves to operations
The register is a single table, one row per change, updated monthly. What is changing is who keeps it.
Operations change register columns
- Changeshort name people recognize
- Teams affectednamed groups, not departments
- Switch windowdates work is disrupted
- Degraded periodweeks until normal speed returns
- Owner on the dayperson at affected hours
- Reversibilitycan this be undone, and by when
A project office keeps a register organized by sponsor, which answers the question the sponsor asked. An operations register is sorted by the team affected, which answers the question the team asks. Same rows, different sort, different decisions.
| Column | What goes in it | Why it earns its place |
|---|---|---|
| Change | A short name people recognize | Without it, two teams discuss different things |
| Teams affected | Named groups, not departments | Impact lands on groups, not on org units |
| Switch window | The dates work is disrupted | The overlap between windows is the whole point |
| Degraded period | Weeks until normal speed returns | Always longer than the switch itself |
| Owner on the day | A person, available at the hours affected | Names the escalation before it is needed |
| Reversibility | Can this be undone, and by when | Decides how much testing it needs |
Two columns do most of the work. The degraded period is the one people leave out, and it is where collisions hide: two switches two weeks apart look separated on a calendar but are not if each carries a three-week recovery.
Trend 3: adoption measurement replaces go-live
Go-live measures the vendor's milestone. Adoption measures yours.
The shift is toward counting how often the old path is still taken. If the legacy form is still submitted, the change has not landed, whatever the training attendance said. The measures are ordinary operations numbers, the same ones collected in operating processes metrics: exception counts, rework hours, the volume still arriving through the retired channel.
This is where the trend meets the audit trail. A change closed on the switch date with no evidence of the old process stopping is an unfinished change wearing a completion date.
Trend 4: process mining to find what actually changed
Process mining reads the system log and reconstructs the path work really took, rather than the path the procedure describes. It is the fastest way to answer whether a change held.
The output is unglamorous and useful: the sequence of steps, the loops, the handoffs that were supposed to disappear. A process that still routes through the old approval is visible in the log even when everyone reports the new process is working.
Treat the tool as a measurement, not a verdict. It shows the path; it does not say whether the path is wrong. For that you need the process as designed and the process as operated, which is the comparison set out in operating processes examples.
Trend 5: change fatigue treated as a safety and quality issue
Regulators have been ahead of most internal plans here. UK Health and Safety Executive guidance on organizational change treats change as a human-factors risk, not a project-throughput question, and starts from how much working memory people have left after doing the job.
Change as project vs human-factors risk
Project-throughput view
- Starting point
- Project schedule
- Review timing
- After the change
- Governing frame
- Throughput
- Failure mode
- Missed dates
- Who owns it
- Project office
Human-factors view
- Starting point
- Working memory left
- Review timing
- Before the change
- Governing frame
- Safety and quality
- Failure mode
- Unfinished changes
- Who owns it
- Qualified safety engineer
The same logic shows up in process safety. OSHA's Process Safety Management standard carries management-of-change as one of its 14 elements, and the requirement is a documented review before the change, not after. For any change touching a covered process, work with a qualified process safety engineer rather than adapting a general register.
The failure mode this trend targets is slow. Each unfinished change leaves a permanent exception, and a register full of changes never formally closed is how an organization accumulates them. That drift is normalization of deviance, and it is why closing changes matters more than opening them.
What the trends share
All five assume a named owner on the day of the switch. A change with no person attached at the affected hours has no escalation path, and the first problem becomes a discovery rather than a decision.
All five also assume the recovery period is planned, not discovered. The switch is the visible part; the weeks after it are where the load actually sits.
And all five are slower than the plans they replace. That is not a flaw in the trends. It is the rate the work supports.
What none of them fixes
A register makes the load visible. It does not create capacity, and the temptation once you have one is to prove everything fits by shaving the degraded-period estimates. Treat any estimate under two weeks with suspicion.
None of these trends improves the design of an individual change. A well-sequenced set of badly planned changes still fails, one at a time, on schedule. The design questions live in change management, and building one against the process as actually operated is set out in change management framework.
Nor do they tell you whether a change caused the movement you see afterward. Crediting a change with a result it did not produce is its own discipline, and reading someone else's published result as if it transferred to your site deserves the caution covered in operations case studies.
Common questions
Who should own the register?
Whoever can see across the affected teams, usually one level above them. It should not sit with a project office that also sponsors changes, because ownership by a sponsor turns the register into a scheduling tool for that sponsor's work.
How often should it be updated?
Monthly is enough. Weekly turns it into a status meeting, and the value is in the quarter-level view rather than in currency. The exception is a change with a hard regulatory date, which should be visible the moment it is scheduled.
What if leadership will not accept the sequencing?
The register has still done its job, which is to make the choice visible and attributable. Running three changes at once with the collision on the page is a different decision from the same one made blind, and it changes what happens when it goes badly.
Does this apply to small teams?
More sharply. In a team of five, one person learning something new is a fifth of capacity, and the absorption limit is reached by changes that would be invisible in a group of fifty.
