Introduction
Technology platforms are widely presented as mechanisms through which improved service quality, reduced operational costs, increased automation, strengthened governance, enhanced employee experiences, and AI‑enabled capabilities are delivered.
Despite these promises, many organisations are left questioning where anticipated benefits are being realised following substantial platform investment.
Modern ITSM and Enterprise Service Management (ESM) platforms are marketed as transformative instruments through which organisational silos are connected, workflows are automated, service levels are improved, and foundations for future AI initiatives are established.
However, a contrasting reality is consistently identified across organisations:
Business case benefits are not being realised
Data is retained in fragmented and inconsistent forms across multiple systems
Technical debt is permitted to accumulate
Automation is applied in ways that duplicate existing effort
AI readiness is characterised more as aspiration than achievement
The selected platform is akin to a fancy sports car, capable of peak performance, that is only taken 100m down the road for some grocery shopping at the corner store
Total Cost of Ownership (TCO) is increased rather than reduced.
Consequently, sophisticated enterprise platformsare frequently utilised to perform tasks tkllklhat can be executed through significantly simpler solutions.
“A Fool with a Tool…”
A central motif of the presentation is articulated through the familiar maxim:
“A fool with a tool is still a fool.”
Rather than serving as criticism, the phrase is reframed as a cautionary reminder. Platform transformations are typically initiated with positive intent, organisational enthusiasm, and a genuine desire for service improvement. The challenge is created not by the technology itself, but by the assumption that technological acquisition is sufficient to produce transformation.
Effective outcomes are achieved only when organisational capability is developed, rather than when software is merely implemented.
Why Does This Keep Occurring?
Drawing on extensive industry experience, four service lifecycle stages (pertaining to the ITSM/ESM
Business cases are developed to secure funding, yet benefit realisation is frequently not managed once project execution begins.
Key issues include:
The platform is positioned as the strategy rather than as an enabler of broader organisational vision
Technology is prioritised over operating model design
People, governance and organisational change requirements are underestimated
Funding is concentrated on implementation while ongoing platform improvement as a BAU capability is neglected
ITSM/ESM subject matter expertise is often requested, funded and used initially, but is somehow (partly or largely) ignored when key decisions are made and next steps initiated
Design phases are often constrained by:
Inadequate architectural planning.
Unclear ownership of data and sources of truth (within the platform itself and between the platform and related enterprise systems)
Weak service catalogues and service taxonomies
Automation of inefficient legacy processes (even resorting to ‘lift and shift’)
Insufficient integration planning across enterprise systems
Lack of holistic operating model / business architecture considerations with which the platform architecture should be aligned
ITSM/ESM subject matter experts within the organisation that argue mitigation of the above risks are not heard in amongst all moving parts
In the absence of strong design foundations, inefficiencies are embedded rather than removed.
During implementation, additional risks are introduced:
Governance and executive oversight are sub-optimal.
Non‑technical transformation components are under‑emphasised.
Organisational Change Management (OCM) activities are delivered in ways that fail to resonate with practitioners (often because the OCM teams do not have a background in the subject matter itself and operate as a silo within the transformation team).
Subject matter expertise (and even comprehensive holistic design if the previous life cycle phases were done well) is diminished during project delivery.
Single training sessions are expected to suffice for developing mature capability.
Introduction
Technology platforms are widely presented as mechanisms through which improved service quality, reduced operational costs, increased automation, strengthened governance, enhanced employee experiences, and AI‑enabled capabilities are delivered.
Despite these promises, many organisations are left questioning where anticipated benefits are being realised following substantial platform investment.
Modern ITSM and Enterprise Service Management (ESM) platforms are marketed as transformative instruments through which organisational silos are connected, workflows are automated, service levels are improved, and foundations for future AI initiatives are established.
However, a contrasting reality is consistently identified across organisations:
Business case benefits are not being realised
Data is retained in fragmented and inconsistent forms across multiple systems
Technical debt is permitted to accumulate
Automation is applied in ways that duplicate existing effort
AI readiness is characterised more as aspiration than achievement
The selected platform is akin to a fancy sports car, capable of peak performance, that is only taken 100m down the road for some grocery shopping at the corner store
Total Cost of Ownership (TCO) is increased rather than reduced.
Consequently, sophisticated enterprise platformsare frequently utilised to perform tasks tkllklhat can be executed through significantly simpler solutions.
“A Fool with a Tool…”
A central motif of the presentation is articulated through the familiar maxim:
“A fool with a tool is still a fool.”
Rather than serving as criticism, the phrase is reframed as a cautionary reminder. Platform transformations are typically initiated with positive intent, organisational enthusiasm, and a genuine desire for service improvement. The challenge is created not by the technology itself, but by the assumption that technological acquisition is sufficient to produce transformation.
Effective outcomes are achieved only when organisational capability is developed, rather than when software is merely implemented.
Why Does This Keep Occurring?
Drawing on extensive industry experience, four service lifecycle stages (pertaining to the ITSM/ESM
Business cases are developed to secure funding, yet benefit realisation is frequently not managed once project execution begins.
Key issues include:
The platform is positioned as the strategy rather than as an enabler of broader organisational vision
Technology is prioritised over operating model design
People, governance and organisational change requirements are underestimated
Funding is concentrated on implementation while ongoing platform improvement as a BAU capability is neglected
ITSM/ESM subject matter expertise is often requested, funded and used initially, but is somehow (partly or largely) ignored when key decisions are made and next steps initiated
Design phases are often constrained by:
Inadequate architectural planning.
Unclear ownership of data and sources of truth (within the platform itself and between the platform and related enterprise systems)
Weak service catalogues and service taxonomies
Automation of inefficient legacy processes (even resorting to ‘lift and shift’)
Insufficient integration planning across enterprise systems
Lack of holistic operating model / business architecture considerations with which the platform architecture should be aligned
ITSM/ESM subject matter experts within the organisation that argue mitigation of the above risks are not heard in amongst all moving parts
In the absence of strong design foundations, inefficiencies are embedded rather than removed.
During implementation, additional risks are introduced:
Governance and executive oversight are sub-optimal.
Non‑technical transformation components are under‑emphasised.
Organisational Change Management (OCM) activities are delivered in ways that fail to resonate with practitioners (often because the OCM teams do not have a background in the subject matter itself and operate as a silo within the transformation team).
Subject matter expertise (and even comprehensive holistic design if the previous life cycle phases were done well) is diminished during project delivery.
Single training sessions are expected to suffice for developing mature capability.