All Posts

Photo Credit: Miguel Bruna We've spent years building processes to control change. Change records. Approval workflows. CAB meetings. Change windows. Risk assessments. Standard changes. Emergency changes. All of these have value. But perhaps the future of Change Enablement requires us to ask a different question. Not: “Have we approved this change?” But: “How confident are we that this change will achieve its intended outcome?” From control to confidence There is a natural mat

Photo Credit: Martin Martz For decades, Change Enablement has relied heavily on human judgement. People review changes. People assess risk. People look for conflicts. People decide whether something should be in approved. People review what happened afterwards. But what happens when AI can do much of the analysis? That's not a distant possibility. It's already becoming a practical opportunity. Imagine a smarter change process Imagine raising a change and having AI immediately

Photo Credit: Zac Ong We often talk about change as though technology changes itself. It doesn't. People experience change. People implement it. People support it. People adopt it. And people sometimes resist it. Yet much of traditional ITSM change management focuses on the technology. Was the implementation successful? Did the deployment complete? Was there an incident? Was the rollback required? Important questions. But there are others. What happens to the people? Consider

Photo Credit: Arthur Debons 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 traditiona

Photo Credit - Clay Banks “We need this implemented immediately.” We've all heard it. Sometimes it's absolutely justified. A critical security vulnerability. A major production incident. A failing service. A regulatory requirement. Sometimes, however, “emergency” means something else entirely. Poor planning. Missed deadlines. Business pressure. A change that wasn't ready in time. Or a team that simply doesn't want to wait for the normal process. And that's where emergency cha

Image Credit: Zac Ong There is something slightly strange about asking for approval to do something you've already successfully done dozens, or hundreds of times. Yet this happens every day in IT organisations. A routine change is raised, it goes through assessment, someone approves it, perhaps it goes to CAB and then someone implements it. And everyone moves on, until next time... The missed opportunity Standard changes are one of the simplest ways an organisation can make C

Image Credit: Benjamin Voros For years, the Change Advisory Board or CAB has been a familiar part of ITSM. A group of people meet Changes are reviewed Questions are asked Risks are discussed Approvals are given It sounds sensible, but there's a question worth asking: Does your CAB actually enable better decisions, or has it simply become another approval meeting? The CAB problem The problem isn't CAB itself. The problem is what we sometimes expect CAB to do. A CAB should prov

Image Credit: Tom Gainor For many organisations, the word “change” still creates an almost automatic reaction: approval, CAB, risk assessment, implementation window, approval again. And somewhere along the way, Change Enablement became synonymous with Change Control. That is a problem. The purpose of Change Enablement isn't to stop people from making changes. It is to enable beneficial change while managing the risks associated with it. That is a very different proposition. W

Most organisations are still debating whether they should adopt Artificial Intelligence. The reality is that many employees have already made that decision for them. Across service desks, project teams, development groups, and support organisations, staff are increasingly using AI tools such as ChatGPT, Copilot, Gemini, and others to help them work faster, write documentation, analyse information, and solve problems. Often, this is happening without formal approval, governanc

Artificial Intelligence has quickly become one of the most discussed topics in IT. Every software vendor seems to have an AI offering, every conference features AI sessions, and every leadership team is asking the same question: "How can we use AI to improve our service desk?" Unfortunately, many organisations are rushing to implement AI without first understanding the risks, governance requirements, or desired outcomes. In some cases, AI is being deployed simply because comp

For years, IT Service Management (ITSM) has focused on delivering reliable, repeatable, and measurable services. We track incidents, monitor service levels, manage changes, and report against key performance indicators. Yet despite meeting every contractual target, many organisations still find themselves facing dissatisfied customers. Why? Because customers don't experience our processes. They experience the outcomes. The relationship between ITSM and Customer Experience (CX

With the release of ITIL v5 product and service management has crossed an important threshold. AI is no longer something organisations are experimenting with at the edges, it is now embedded in the core of how services are delivered, supported, and improved. That shift introduces a new kind of challenge. Not a tooling issue, and not simply a capability gap, but a governance question. When decisions are increasingly made by machines, often in real time and at scale, how do org

In the world of Information Technology Service Management (ITSM), the utilization of the ITIL framework has become synonymous with efficiency, effectiveness, and excellence. ITIL serves as a set of best practices that help organizations align their IT services with the needs of the business. By implementing ITIL principles in ITSM strategy, organizations can unlock a multitude of benefits that drive organizational success and growth. One of the key advantages of incorporatin

Governance is meant to protect organisations. It exists to manage risk, provide oversight, and ensure decisions are made responsibly. In theory, good governance enables better outcomes. In practice, however, governance can do the opposite. It can slow delivery. It can disconnect decision-makers from reality. And in the worst cases, it can become a barrier to the very value it was designed to safeguard. This is not a call for less governance. It’s a call for better governance

In IT services, few things are more reassuring than a dashboard full of green indicators. SLAs are being met, response times are within target, and incident volumes are under control. On paper, the service looks healthy. Yet many service leaders will recognise a familiar contradiction: despite strong SLA performance, customer confidence is declining. Conversations become tense. Escalations increase. Renewal discussions feel less certain. This disconnect is not unusual. It hig

Standardisation sits at the heart of managed services. Without it, scale becomes difficult, delivery risk increases, and margins quickly erode. Standard processes, tools, and operating models are what allow providers to deliver consistent service across multiple customers. For managed services leaders, standardisation often represents stability: predictable outcomes, repeatable delivery, and governance that can be measured and reported. And yet, many of the most challenging s

Introduction Data is the backbone of effective service management, but not all metrics are created equal. Many MSPs track too many KPIs, or the wrong ones, or measure things that don’t actually drive improvement. This article outlines the KPIs that truly matter and how MSPs can use them to measure success, improve performance, and demonstrate value to clients. The KPIs That Actually Matter for MSPs 1. Mean Time to Resolve (MTTR) MTTR reflects efficiency and service quality. I

Introduction Every MSP deals with large volumes of tickets. But not all tickets should be treated the same and not all require the same process. The key to sustainable service delivery is understanding the difference between incident management and problem management , and applying each where they belong. This article explains the difference in simple, real-world terms and outlines how MSPs can implement both practices effectively. Incident Management: Fixing What’s Broken R

Introduction For many MSPs, the service catalogue is one of the most under utilised tools in the entire service management ecosystem. On paper, the catalogue is meant to define services, outline expectations, and streamline requests. In reality, many clients don’t use it and many technicians don’t either. Why? Because most service catalogues are built from an engineer’s perspective, not the customer’s. A great service catalogue is not a list of technical capabilities. It is a

Introduction If you walk into almost any Managed Service Provider (MSP), you’ll hear a version of the same statement: “We follow ITIL and industry best practice.” And in many cases, it’s true, at least on paper. Processes are documented. Roles are defined. Tools are configured. But in the day-to-day reality of service delivery, something different often unfolds. Engineers triage based on instinct rather than procedure. Workarounds replace workflows. SLAs get interpreted diff