Change management in technology often gets reduced to IT operations announcing what patches will be applied over the weekend. This misses the entire point of why change processes exist.
Effective change management helps the business achieve their goals without drowning stakeholders in notifications they can’t act on. Getting this right requires understanding what change management is actually for.
What change management actually addresses
I’ve worked in organisations where the Change Advisory Board consisted entirely of IT operations staff. The meeting agenda: which patches would be applied on the upcoming weekend, which external vendors had advised of upcoming changes. Assessment focused entirely on impact to systems, not people.
If IT operations decided something might affect someone, they’d prepare communications. Sometimes things would go wrong. Someone couldn’t log in on the weekend because they weren’t on the notification list. Finger-pointing would begin.
“There’s no guarantee the systems will be up 24/7” is technically accurate. Achieving 24/7 availability is difficult for smaller organisations with limited resources. But have clear service level agreements and KPIs that the business has approved been defined? Usually not.
This is the gap effective change management bridges: connecting technology changes to business impact in a way people can actually understand and plan for.
Getting the right information to the right people
Security patches that don’t affect user access? Notify operations staff. End users don’t need to know.
Changes affecting how people work? Stakeholders need advance notice, a clear explanation of what’s changing and the opportunity to plan around it. An email the day before doesn’t accomplish this.
The challenge is determining what matters to whom without either over-communicating (everyone gets every notification) or under-communicating (people discover changes when things break).
Involving stakeholders when it matters
Engage stakeholders early for changes affecting how they work. Their input matters because they understand their workflows better than IT does.
When stakeholders are involved from the beginning, resistance decreases. They have context for why the change is happening and what to expect.
This doesn’t mean involving everyone in every change. Identify which changes have business impact and involve those specific stakeholders.
Matching training to actual need
Weekend security patches don’t require user training. New systems for processing customer work do.
Matching support to the actual scope of change prevents both under-preparation (users struggling with systems they weren’t trained on) and over-preparation (mandatory sessions for changes that don’t affect daily work).
Define the parameters first
What are your system availability targets? What service levels have stakeholders agreed to? When is planned downtime acceptable and when isn’t it?
Without these parameters defined and agreed, every change becomes a negotiation. Define them upfront and change planning becomes straightforward: does this change fit within agreed parameters, or does it require exception approval?
The most effective change management I’ve seen started here. System availability ranges, service level agreements, escalation procedures and which changes required broad stakeholder involvement versus which could be handled operationally.
Once those boundaries were defined and agreed, routine operational changes happened within agreed parameters. Changes outside those parameters went through broader assessment and stakeholder involvement. This prevented both notification fatigue (everyone informed about everything) and surprise disruption (nobody informed until things broke).
