5. Change Success Isn't “It Worked”
Imagine a change is implemented on time.
No technical errors occur.
The system remains available.
Monitoring shows everything is green.
he change is closed.
Success? Maybe. But what if customers hate the new experience? What if employees struggle to use the new process? What if the business outcome the change was supposed to deliver never materialises?
Technically successful. Business failure.
The limitation of technical success
ITSM has traditionally been very good at measuring operational performance.
Was the change successful?
Did it cause an incident?
Was it completed within the change window?
Was there a rollback?
Those measures matter. But they're not the whole story. A change exists for a reason. Usually, that reason isn't: “Because IT wanted to change something.” There is normally a business, customer or operational outcome behind it.
So perhaps we should ask a bigger question: Did the change achieve what it was intended to achieve?
Four dimensions of change success
I think there are at least four dimensions worth considering.
1. Technical
Did the technology change successfully?
Was it implemented correctly?
2. Operational
Did the service continue to operate effectively?
Did support teams have what they needed?
Were monitoring and knowledge updated?
3. Business
Did the change deliver the intended business outcome?
Did it improve productivity, revenue, compliance, efficiency or another target?
4. Customer
Did the customer experience improve, or at least remain acceptable?
This last one is often overlooked.
The customer doesn't care about your change window
A customer doesn't know whether your change was:
Normal
Standard
Emergency
Approved by CAB
Implemented within the maintenance window
They care about what happened to them. If the new feature technically works but takes three times as many clicks, that's their reality. If a platform upgrade completes successfully but creates a confusing user experience, the change may have succeeded technically while failing experientially.
This is where ITSM needs to evolve
Good Change Enablement shouldn't stop at implementation. It should connect change with outcomes.
That doesn't mean every change needs a complicated business case. For a small infrastructure change, technical measures may be enough. For a major customer-facing transformation, they probably aren't.
The level of measurement should reflect the significance of the change.
A practical approach
Before implementing a significant change, define:
What are we changing?
Why are we changing it?
Who is affected?
What outcome are we expecting?
How will we know we've achieved it?
Then, after implementation, don't immediately declare victory. Check.
Did the expected outcome occur?
What did customers experience?
Did support demand increase?
Did new incidents appear?
Did adoption happen?
Did the business benefit materialise?
Change Enablement and Experience
This is particularly important as ITSM increasingly focuses on experience. The service desk may see the consequences of a change long before anyone else does.
A sudden increase in “how do I?” calls.
Customers reporting confusion.
Employees struggling with a new process.
Knowledge articles being accessed repeatedly.
These aren't just support statistics. They can be feedback on the quality of the change itself. The service desk can therefore become an important source of change intelligence.
The better question
Instead of: “Was the change successful?” Ask: “What changed for the people and business affected by it?” That question is much harder. And much more valuable.
Because ultimately, Change Enablement shouldn't exist to produce successful change tickets. It exists to help organisations achieve better outcomes through change. A green change record doesn't necessarily mean a successful change. Sometimes, you need to look beyond the ticket.
Next in the series: The Human Side of Change Enablement.
Change Enablement - Beyond the Change Ticket.
Comments