Organisations invest significant amounts of money developing their IT service management capability.
They train people in ITIL. They recruit experienced service managers. They implement sophisticated ITSM platforms. They build service desks, change functions, problem-management practices and continual-improvement teams.
Then, when something needs improving, they often do something curious.
They bring in somebody from outside the organisation to tell their trained and experienced people what to do.
There will always be situations where external expertise is valuable. Sometimes an organisation genuinely doesn’t possess the knowledge or experience required to solve a particular problem.
But what if the expertise already exists?
What if the challenge isn’t a lack of knowledge, but creating the environment in which people can apply that knowledge, challenge established assumptions and develop their own solutions?
Perhaps the next evolution of IT service management isn’t another methodology, maturity assessment or transformation programme.
Perhaps it’s unlocking the capability organisations already have.
That means moving from ITSM consultancy to ITSM capability.
The ITSM Capability Paradox
Consider a typical organisation.
It invests in ITIL training so its people understand service management principles and practices.
Those employees accumulate years of operational experience.
They understand their organisation’s systems.
They know their customers.
They understand where processes become difficult.
They experience the workarounds.
They see where tickets repeatedly get stuck.
They know which changes generate incidents.
They understand the organisational politics that prevent improvements.
Collectively, they possess an extraordinary amount of knowledge about how their services actually operate.
Yet when the organisation wants to improve ITSM performance, it may spend substantial sums bringing external consultants into the organisation.
The consultants interview those same employees.
They conduct workshops.
They review processes.
They analyse data.
They identify problems.
And eventually they present recommendations back to the organisation.
There is nothing inherently wrong with this model.
Good consultants can bring expertise, independence, experience and perspectives that organisations simply don’t possess internally.
But there is an important question organisations should ask before commissioning external consultancy:
Are we buying knowledge we don’t have, or are we paying someone to unlock knowledge we already possess?
Those are fundamentally different problems.
And they require different interventions.
The Economic Case: Extract More Value From ITIL Investment
The UK spends substantial amounts every year developing IT service-management capability.
Organisations pay for ITIL certification, specialist training, ITSM platforms, conferences, professional development and experienced service-management professionals.
Training is an investment in organisational capability.
But the return on that investment isn’t created when somebody passes an exam.
It’s created when that person applies what they have learned.
Imagine an organisation has trained 100 employees in ITIL.
The important question isn’t:
“How many people have ITIL certification?”
It’s:
“What improvements have those 100 trained people subsequently created?”
If organisations invest heavily in developing people’s knowledge but continue outsourcing much of the thinking about improvement, they may never realise the full value of their training investment.
This suggests a different economic model.
Instead of:
Train → Consult → Recommend → Implement
consider:
Train → Coach → Discover → Experiment → Measure → Improve
Consultancy expenditure isn’t necessarily eliminated.
It becomes more targeted.
External expertise is purchased where genuine expertise is missing.
Coaching is used where capability already exists but needs to be unlocked.
Over time, this has the potential to reduce dependency on external consultancy while simultaneously increasing the return generated by investments in ITIL and professional development.
The goal isn’t simply to reduce consulting costs.
The goal is to create an organisation that becomes progressively better at improving itself.
From Advice to Inquiry
Consultancy and coaching begin from very different positions.
Consultancy frequently starts with:
“What should this organisation do?”
Coaching starts somewhere else:
“What could the people in this organisation discover?”
The distinction matters.
A consultant is typically engaged because of their expertise.
They analyse a situation and provide recommendations.
A non-directive coach takes a different position.
The coach does not need to arrive carrying the answer.
Instead, they create the conditions in which people can think more deeply about the problem.
They listen.
They question.
They challenge assumptions.
They create reflection.
They expose contradictions.
They help people distinguish evidence from opinion.
And, importantly, they resist the temptation to solve the problem for the people experiencing it.
The principle is simple:
The people closest to the work often understand things about the work that outsiders cannot easily see.
That doesn’t mean they automatically have every answer.
It means their knowledge deserves to be explored before the organisation purchases an external answer.
A Non-Directive Philosophy for ITSM Improvement
Non-directive coaching begins with a belief in the capability of the individual or team.
Rather than positioning the coach as the expert and employees as recipients of expertise, the relationship assumes that employees possess experience, knowledge and insight that can be developed through structured reflection.
The coach’s role is therefore not:
“Here is what you should do.”
It is to ask questions such as:
What outcome are you trying to achieve?
What is actually happening today?
What evidence supports that view?
What assumptions are you making?
What have you already tried?
What is preventing improvement?
What is within your control?
What haven’t you considered?
What could you experiment with?
How would you know whether it worked?
These appear simple.
Asked well, however, they can produce remarkably sophisticated thinking.
And because the solutions are generated by the people who must implement them, they can create something recommendations often struggle to achieve:
Ownership.
Not Everything Is a Coaching Problem
This distinction is critical.
Non-directive coaching should not become an ideological replacement for expertise.
Sometimes people simply don’t know something.
No amount of powerful questioning will manufacture specialist knowledge that doesn’t exist.
If an organisation needs specialist cybersecurity expertise, regulatory knowledge, complex platform architecture or experience of something it has never previously implemented, external expertise may be exactly what it needs.
The challenge is choosing the right intervention.
A useful framework is:
LEARN — CONSULT — COACH — ENABLE
LEARN
When there is a knowledge gap.
People don’t yet possess the underlying knowledge required.
Invest in training, education, mentoring or professional development.
Examples might include understanding ITIL practices, learning a new ITSM platform or developing knowledge of service integration.
Question: Do we know how this works?
CONSULT
When there is an expertise gap.
The organisation lacks specialist experience that would be inefficient, risky or unrealistic to develop immediately.
Bring in expertise.
Examples could include complex ITSM platform implementation, regulatory requirements, major organisational transformation or specialist technical architecture.
Question: Do we have the specialist expertise required?
COACH
When there is a thinking or ownership gap.
The knowledge exists.
The experience exists.
But people need space, challenge and structured reflection to turn that capability into action.
Use coaching.
Question: Do we already possess enough knowledge to discover our own answer?
ENABLE
When there is an execution gap.
People know what needs to happen but organisational barriers prevent action.
The answer isn’t more training, consultancy or coaching.
Leadership needs to remove constraints.
That might mean providing authority, resources, data, technology, time or cross-functional support.
Question: What is preventing capable people from acting?
This framework changes an important organisational question.
Instead of asking:
“Do we need a consultant?”
ask:
“What capability is actually missing?”
Only then select the intervention.
A Coaching Methodology for ITSM Improvement
Non-directive ITSM coaching needs enough structure to turn conversation into measurable improvement without turning the coach back into a consultant.
One possible methodology is an eight-stage improvement cycle.
1. OUTCOME
What are we trying to improve?
Start with value rather than process.
What would be different for customers, employees or the organisation if this improved?
Avoid vague objectives such as:
“Improve incident management.”
Instead explore outcomes:
“Reduce the disruption customers experience from recurring incidents.”
The distinction immediately changes the conversation.
2. REALITY
What is actually happening?
Separate perception from evidence.
What does the data show?
What do customers experience?
What do employees experience?
Where does work really flow?
Where does it stop?
This stage should embody a powerful principle:
Start where you are—not where your process documentation says you are.
3. INSIGHT
What does the evidence tell us?
Now explore patterns.
Why might this be happening?
What assumptions are embedded in the existing process?
What behaviours does the current system encourage?
Where are hand-offs creating friction?
What are people doing outside the documented process—and why?
The coach challenges thinking without supplying conclusions.
4. POSSIBILITY
What could we do differently?
This is deliberately expansive.
Before selecting a solution, generate possibilities.
What would we try if the current process didn’t exist?
What would the customer design?
What could we stop doing?
What could we simplify?
What could we automate?
What small change might create a disproportionately large benefit?
Innovation requires permission to think beyond the current operating model.
5. EXPERIMENT
What is the smallest meaningful change we can test?
Avoid turning every improvement into a transformation programme.
Choose something that can be tested.
Define:
What will change?
Who will participate?
How long will the experiment run?
What do we expect to happen?
What could go wrong?
What evidence will we collect?
This shifts improvement from debate to experimentation.
6. EVIDENCE
What happened?
Return to data.
Did incidents decrease?
Did resolution time improve?
Did customers notice?
Did employees experience less friction?
Did another problem unexpectedly appear?
The objective isn’t to prove the original idea was correct.
It is to discover what actually happened.
7. LEARNING
What have we learned?
This is where coaching becomes particularly powerful.
What surprised us?
What assumptions were wrong?
What would we do differently?
What did we learn about our customers?
What did we learn about our organisation?
What did we learn about ourselves?
Improvement without reflection can simply create another process.
Reflection turns experience into capability.
8. IMPROVEMENT
Adopt, adapt or abandon.
If the experiment worked, consider adopting it.
If it partially worked, adapt it.
If it didn’t work, abandon it.
Failure isn’t necessarily wasted effort if it generated useful evidence.
Then begin the cycle again.
OUTCOME → REALITY → INSIGHT → POSSIBILITY → EXPERIMENT → EVIDENCE → LEARNING → IMPROVEMENT ↻
Continual improvement becomes something people do, rather than something contained in an ITSM process document.
Measuring What Matters
For this model to gain credibility with CIOs and senior leadership, coaching cannot simply be measured through participant satisfaction.
The question cannot only be:
“Did people enjoy the coaching?”
The question must become:
“What changed because of it?”
Measures should therefore operate at several levels.
Operational outcomes
Depending on the improvement being explored, these might include:
- Mean time to restore service
- Incident volumes
- Recurring incidents
- First-contact resolution
- Change failure rates
- Service availability
- Ticket backlog
- Escalations
- Request fulfilment times
- Automation rates
Customer outcomes
Measure whether customers actually experience the improvement:
- Customer satisfaction
- Employee experience
- Effort required to obtain support
- Service reliability
- Complaints
- Digital experience
Financial outcomes
Translate improvement into economics:
- Cost per ticket
- Productivity released
- Avoided incidents
- Reduced rework
- Reduced external consultancy
- Reduced service-desk demand
- Automation benefits
- Cost avoidance
Capability outcomes
This is perhaps the most important category.
Is the organisation becoming better at improving itself?
Measure things such as:
Number of employee-generated improvement ideas
Number of experiments undertaken
Percentage producing measurable benefits
Time from idea to experiment
Cross-functional participation
Percentage of improvements generated internally
Reliance on external consultancy
Benefits generated per £1 invested in coaching
Over time, one metric could become particularly powerful:
Internal Improvement Capability Index
Not simply how much did we improve?
But:
How capable are we of creating the next improvement ourselves?
The Role of the ITSM Leader Changes Too
There is a leadership implication.
If employees are expected to identify and create improvements, leaders must resist the temptation to provide every answer.
A leader who asks:
“What do you think we should do?”
creates a different environment from one who immediately says:
“Here’s what we’re going to do.”
That requires psychological safety.
People must be able to question existing processes.
Challenge assumptions.
Run controlled experiments.
Report unsuccessful experiments.
And disagree constructively with established thinking.
Leaders therefore become enablers of improvement rather than owners of every solution.
Capability Rather Than Dependency
The strongest argument for coaching-led ITSM improvement isn’t that consultants are too expensive.
It is that organisations should be deliberate about what capability they outsource.
There will always be circumstances where consultants add enormous value.
Use them.
But first ask:
Do we need expertise—or do we need to unlock the expertise we already have?
If it is the latter, bringing in another expert to provide the answer may actually bypass the capability the organisation has spent years developing.
ITIL training gives people knowledge.
Experience gives them context.
Coaching can provide the space, challenge and confidence to connect the two.
The result is a different model of ITSM improvement:
Learn what you don’t know.
Consult where you lack expertise.
Coach where capability already exists.
Enable people when organisational barriers prevent action.
And then measure whether any of it actually made things better.
From ITSM Consultancy to ITSM Capability
Perhaps the ultimate measure of a successful ITSM function isn’t how closely it follows a framework.
Nor how many people hold certifications.
Nor how impressive its transformation roadmap looks.
A more interesting question is:
How capable is this organisation of identifying and solving its next service-management problem for itself?
Because sustainable continual improvement cannot depend indefinitely on somebody arriving from outside the organisation with the answer.
The knowledge may already be there.
The experience may already be there.
The ideas may already be there.
The people may already be there.
Sometimes the most valuable intervention isn’t giving them another answer.
It’s asking the questions that help them discover what they already know—and what they could do next.
