Opportunity and demand
Opportunity is a chance to add value, such as moving a data centre service to the cloud. Demand is a need for a service, such as a new office. Both enter the system the same way.
ITIL 4
ITIL 4 as a toolkit, not a rulebook
ITIL (originally the IT Infrastructure Library) is a widely used body of guidance for running IT services. I use it to make the networks and platforms I design supportable from day one. This page explains the service value system, the value chain and the 34 practices. It goes deeper on events, configuration, release and knowledge, shows how I measure and improve, and covers what ITIL Version 5 changes.
Value system
From demand to value, as one system
ITIL 4 stopped describing service management as a lifecycle of processes. It describes a service value system instead: everything an organisation uses to turn demand into value. I find this the most useful idea in the framework, because it makes support part of the design, not something added at the end.
Swipe sideways to see the whole diagram.
One system, not a list of processes. Demand and opportunity come in. The value chain turns them into value, using the practices. The principles shape every decision and governance keeps it accountable. Continual improvement runs through all of it, so the system gets better each time it is used.
The words that matter
| Term | What it means | A network example |
|---|---|---|
| Service | A way of creating value with a customer, by making outcomes possible without the customer managing the costs and risks. | A branch connection: the branch gets working links without owning carriers or routers. |
| Product | The resources an organisation configures to offer services: people, tools, suppliers and processes. | Routers, a carrier contract, a monitoring tool and a support team. |
| Service offering | One or more services, packaged for a type of customer: goods, access to resources and service actions. | Gold branch connectivity: two circuits, a router, monitoring and a four hour fix. |
| Output and outcome | An output is something produced. An outcome is the result the customer cares about. | Output: a router configured. Outcome: the shop takes card payments. |
| Utility | Fit for purpose: what the service does. | Connects the branch to the data centre and the internet. |
| Warranty | Fit for use: how well it does it, in availability, capacity, security and continuity. | 99.9% availability, enough bandwidth at peak, and encrypted links. |
| Value | The benefit, usefulness and importance of something, as the people who use it judge it. | Staff serve customers without waiting for the system. |
Definitions paraphrased from ITIL 4. The examples are mine.
Governance
The board or leadership sets direction and checks the system is working. For infrastructure, that is the design authority, the change authority and the service reviews.
Practices
Sets of resources for a type of work: people, information, tools, suppliers and processes. Version 4 has 34 of them, and so does Version 5.
ITIL (originally the IT Infrastructure Library) is guidance, not a standard. ISO/IEC 20000 is the standard an organisation can certify its service management against, and ITIL is one way to meet it.
Projects hand new services into these practices. How I run them before that is on my PRINCE2 (Projects in Controlled Environments) page. In telecoms, the process view is eTOM (enhanced Telecom Operations Map), on my TM Forum page.
Principles
Seven guiding principles, applied to infrastructure
The guiding principles are the advice that holds whatever the situation. They are short and easy to quote, which makes them easy to ignore. These are the seven, each with the way I apply it to network and platform work.
- Focus on value. Everything should link back to value for someone. A change freeze that protects a trading floor is value. A form nobody reads is not, so I remove it.
- Start where you are. Measure what exists before replacing it. The old monitoring tool often has years of good thresholds that a new tool should inherit.
- Progress iteratively with feedback. Improve one site, one practice or one queue at a time, and check each step worked before the next. A big bang rollout of a new tool rarely survives first contact.
- Collaborate and promote visibility. Put work and its status where everyone can see it: one change calendar, one major incident timeline, one backlog of known errors.
- Think and work holistically. A network change touches security, servers, suppliers and the service desk. I review it with all of them, not just the network team.
- Keep it simple and practical. If a step adds no value, drop it. A standard change for a VLAN (virtual local area network) on an access port needs a template and a check, not a meeting.
- Optimise and automate. First make the work simple, then automate it. Automating a broken process only produces broken results faster.
They apply together
The principles are not a checklist to pick from. A good decision usually satisfies several at once, and a bad one breaks more than one.
They outlast the version
The same seven principles carry over into ITIL Version 5. They are the part of ITIL I use most outside service management, in design reviews and project planning.
They settle arguments
When two teams disagree about a process, asking "where is the value, and is this the simplest way?" ends most debates quickly.
Four dimensions
Four dimensions, so nothing is left out
ITIL 4 says every service and every practice must be looked at from four dimensions, inside a frame of external factors. It sounds abstract. In practice it is the best checklist I know for a service handover. Choose a dimension to see it applied to a new SD-WAN (software defined wide area network) service.
Swipe sideways to see the whole diagram.
Organisations and people. For a new SD-WAN service, the network operations centre needs training on the controller, the service desk needs a script for branch outages, and someone must own the policy. Culture counts too: a team that fears change will route everything to the CAB (change advisory board).
Information and technology. The controller, the monitoring feeds, the CMDB (configuration management database) records for every edge device, and the knowledge articles. It also covers what information the service needs and creates, and how that data is protected.
Partners and suppliers. The carriers for each underlay, the vendor for software and hardware support, and any managed service partner. Their contracts must support the promise made to the business, or the promise is hollow.
Value streams and processes. How a new branch is ordered and connected, how an outage is detected and fixed, and how a policy change reaches every site. Each is a value stream, built from value chain activities and practices.
External factors. ITIL uses PESTLE (political, economic, social, technological, legal and environmental factors). For SD-WAN that means regulation on where traffic may go, carrier prices, home working, new vendor features, contract law and the power drawn by every edge device.
All four together. I use the dimensions as a design checklist. When a service fails in its first months, the gap is usually in a dimension nobody owned: a supplier contract, a missing skill or an undocumented handoff, rarely the technology itself.
| Dimension | What I check before a service goes live | Typical gap |
|---|---|---|
| Organisations and people | Named service owner, trained support teams, on call rota, escalation contacts | The project team leaves and nobody else knows the design |
| Information and technology | CMDB records, monitoring, dashboards, knowledge articles, data classification | Devices live but not in monitoring or the CMDB |
| Partners and suppliers | Support contracts, fix times, escalation routes, licence renewals | A carrier fix time longer than the promise to the business |
| Value streams and processes | Request, incident, change and release routes, with the right assignment groups | Tickets for the new service land in a generic queue |
Value chain
Six activities, many value streams
The service value chain has six activities. They are not a sequence: each kind of work, from a password reset to a data centre migration, combines them in its own order. That combination is a value stream. Step through a branch office request to see one.
Swipe sideways to see the whole diagram.
A regional manager asks for a new branch office connection. The service desk logs a request, and relationship management agrees the scope, the opening date and who signs off. Engagement keeps going until the branch is live.
The request is checked against the network roadmap, the standards and the budget: which branch pattern, which carriers, which security controls. Planning sets direction for every value stream, not just this one.
The design follows the standard branch pattern, so it is quick. The change is assessed and scheduled, and service validation and testing defines how the build will be proved.
Circuits and hardware are ordered, the router is staged from a template, and the new configuration items go into the CMDB with their relationships.
Go live. Monitoring watches the new links, the service desk has a knowledge article for the branch, and incidents route to the right resolver group from day one.
The branch trades on its opening day. Value is created with the customer, not handed over: the branch gave the address, the access and the opening date, and confirms the outcome.
Lead time, cost and incidents in the first month go into the improvement register. If carrier lead times caused the delay, the next branch orders circuits earlier. Improvement touches every activity.
| Activity | Its purpose | For infrastructure it means |
|---|---|---|
| Plan | A shared understanding of the vision, the current state and the direction for all products and services. | Roadmaps, standards, lifecycle and capacity plans, budgets |
| Improve | Continual improvement of products, services and practices across every activity. | The improvement register, problem trends, service reviews |
| Engage | Understanding stakeholder needs, being transparent and keeping good relationships. | The service desk, request intake, supplier and business relationships |
| Design and transition | Making sure services meet expectations for quality, cost and time to market. | High and low level designs, change, testing, release planning |
| Obtain or build | Making service components available when and where they are needed, to specification. | Ordering, staging, building from templates, recording assets and CIs (configuration items) |
| Deliver and support | Making sure services are delivered and supported to agreed specifications and expectations. | Operations, monitoring, incident and request fulfilment |
Purposes paraphrased from ITIL 4. ITIL Version 5 adds a product and service lifecycle on top of these ideas; the practices stay the same.
Try it: build a value stream
A value stream is the route one kind of work takes through the value chain. Each uses the same six activities in its own order, with its own practices. Choose a piece of work to see its route. Without scripts, the firewall rule example is shown.
- EngageAn application team asks for access from a new server to a database.Service request management, service desk
- Design and transitionSecurity checks the rule against policy, the risk is scored and it is scheduled as a standard or normal change.Information security management, change enablement
- Obtain or buildThe rule is written from a template, peer reviewed and added to the rule base with an owner and an expiry date.Deployment management, service configuration management
- Deliver and supportThe requester tests the connection. Hit counts show it is used.Service request management, monitoring and event management
- ImproveRules with no hits after 90 days go to a quarterly review and are removed.Continual improvement, risk management
34 practices
The 34 practices, and which ones a network needs
ITIL 4 groups its practices into 14 general management, 17 service management and 3 technical management practices. Search or filter the list to see what each one is for, and how it shows up in infrastructure work.
Find a practice
Showing all 34 practices.
| Practice | Group | Its purpose | In infrastructure work |
|---|---|---|---|
| Architecture management | General | Understands how the parts of the organisation fit, now and in future. | Reference architectures, standards and the design authority |
| Continual improvement | General | Keeps services and practices in line with changing needs. | The improvement register and its owners |
| Information security management | General | Protects the information the organisation needs. | Firewall policy, access control, vulnerability response |
| Knowledge management | General | Keeps knowledge usable, so people can find and trust it. | Runbooks, known errors and diagrams people actually use |
| Measurement and reporting | General | Supports decisions with data that reduces uncertainty. | Availability, capacity and incident trends per service |
| Organisational change management | General | Manages the human side of change so it sticks. | Training and support when a new tool or process arrives |
| Portfolio management | General | Keeps the right mix of programmes, projects, products and services within budget. | Which refreshes and migrations get funded this year |
| Project management | General | Delivers projects through planning, control and coordination. | Refreshes, migrations and builds, often run with PRINCE2 |
| Relationship management | General | Builds and keeps links with stakeholders. | Service reviews with business units and suppliers |
| Risk management | General | Understands and handles risk. | The risk register, change risk and end of life exposure |
| Service financial management | General | Supports decisions on spending and investment in services. | Cost per site, licence costs and recharges |
| Strategy management | General | Sets goals and the actions and resources to reach them. | The infrastructure strategy and its roadmap |
| Supplier management | General | Makes sure suppliers and their performance support the services. | Carrier and vendor contracts, fix times and reviews |
| Workforce and talent management | General | Puts people with the right skills in the right roles. | Skills matrices, training plans and on call cover |
| Availability management | Service | Makes sure services deliver the availability that was agreed. | Redundancy design and availability reporting |
| Business analysis | Service | Analyses the business, defines its needs and recommends solutions. | Requirements for a new site, service or migration |
| Capacity and performance management | Service | Meets agreed performance and future demand at a sensible cost. | Link, firewall and licence headroom forecasts |
| Change enablement | Service | Maximises successful changes by assessing risk, authorising and scheduling them. | Change models, the change calendar and the CAB |
| Incident management | Service | Restores normal service as quickly as possible. | Outages, degradation and loss of resilience |
| IT asset management | Service | Plans and manages the full lifecycle of IT assets, to maximise value and control cost and risk. | Hardware, software, licences, support contracts and disposal |
| Monitoring and event management | Service | Observes services and components, and records and reports changes of state. | Polling, traps, logs, telemetry and event rules |
| Problem management | Service | Reduces the likelihood and impact of incidents by finding causes and managing workarounds. | Root causes, known errors and vendor bug cases |
| Release management | Service | Makes new and changed services and features available for use. | Gold software releases and new service features |
| Service catalogue management | Service | Provides one consistent source of information about services and offerings. | What users can request, and what each offering includes |
| Service configuration management | Service | Keeps accurate information about configuration items and how they relate. | The CMDB, discovery and service maps |
| Service continuity management | Service | Keeps availability and performance acceptable in a disaster. | Disaster recovery sites, tests and recovery plans |
| Service design | Service | Designs products and services that are fit for purpose and fit for use. | Designs that include support, monitoring and suppliers |
| Service desk | Service | Captures demand for incident resolution and service requests, as the single point of contact. | First line: logging, first fixes and routing |
| Service level management | Service | Sets clear, business based targets and checks delivery against them. | SLAs (service level agreements), OLAs (operational level agreements) and monthly service reviews |
| Service request management | Service | Handles agreed, user initiated requests in an effective and user friendly way. | Access, VLAN changes, new starters and standard kit |
| Service validation and testing | Service | Makes sure new or changed products and services meet their requirements. | Lab tests, pilot sites and acceptance criteria |
| Deployment management | Technical | Moves new or changed hardware, software and other components to live environments. | Configuration pushes, software waves and staging |
| Infrastructure and platform management | Technical | Oversees the infrastructure and platforms the organisation uses. | Networks, data centres, cloud platforms and their operations |
| Software development and management | Technical | Makes sure applications meet internal and external needs. | Automation code, templates and scripts as managed software |
Practices, not processes
ITIL v3 had 26 processes and four functions. ITIL 4 replaced them with 34 practices. A practice includes its people, information, tools, suppliers and processes, so it is closer to a capability than to a flowchart.
Use the ones you need
Nobody runs all 34 at full depth. A network team leans on monitoring and event, incident, problem, change, configuration, release, deployment and supplier management. I start there.
One owner each
Each practice I put in place has a named owner who keeps its process, its data and its measures healthy. A practice with no owner decays within months.
Purposes summarised in my own words from the ITIL 4 practice guides. Incident, problem, change, service levels and patching are covered in depth on the support and service management page.
The service desk practice in action, with support lines, swarming and knowledge, is on my 1st, 2nd and 3rd line support page.
Events
Monitoring and event management, without the noise
ITIL 4 defines an event as any change of state that matters to the management of a service or a CI (configuration item). The practice is less about collecting data and more about deciding what each event means and who, if anyone, should act on it.
Swipe sideways to see the whole diagram.
Most events need no person. Many events arrive, and few should reach a person. Informational events are kept for trends and audit. Warnings show a threshold is near, so they feed capacity and problem work. Exceptions mean something is wrong, and become incidents with the CI (configuration item) already attached.
- informational
- warning
- exception
Event rules I agree with service owners
| Event | Type | Rule | Result |
|---|---|---|---|
| An access port goes up or down | Informational | Log only | Kept for trends and audit |
| Link above 80% for 15 minutes | Warning | Watch list and a capacity record | No incident. Reviewed weekly |
| One uplink of a redundant pair down | Exception | Incident, priority 3 | Resilience lost, users unaware |
| Both uplinks to a site down | Exception | Incident, priority 1, page on call | Site down |
| The same interface flaps 5 times in 10 minutes | Exception | One incident, child events linked | One ticket, not five |
| Any event from a device in its change window | Any | Suppressed and logged against the change | Expected noise stays quiet |
| A clear event for an open incident | Informational | Note added; resolve only after checks | No silent auto close on a flapping link |
Example rules and thresholds. Each organisation sets its own with the service owners.
Correlate with the CMDB
When a distribution switch fails, its access switches go quiet too. With relationships in the CMDB, the tool raises one incident for the cause and links the rest, instead of paging four people.
Change aware
The change calendar feeds the event tool. Alerts from a device inside an approved window are suppressed and logged against the change, so a planned reload never wakes the on call engineer.
Measure the noise
I track how many events become incidents, and how many alerts led to no action. If most pages need no action, the rules are wrong, not the engineers.
The sources themselves, SNMP (Simple Network Management Protocol) polling, traps, syslog, flows, telemetry and synthetic tests, are on the support and service management page.
Configuration
A CMDB people trust, because it is used every day
Service configuration management keeps accurate information about CIs and their relationships. The CMDB is where that lives. On every engagement I find one of two things: a CMDB nobody trusts, or none at all. The fix is the same. Record only what a process will use, and use it every day.
Swipe sideways to see the whole diagram.
A CI (configuration item) is anything that must be managed to deliver a service. Each has a class, an owner, a status and relationships. Business services depend on application services, which run on infrastructure.
A discovery tool scans the estate on a schedule: devices, software versions, serial numbers and connections. Discovery finds what exists. The CMDB (configuration management database) says what should exist and why.
Here the record says the firewalls run release 10.1, but discovery finds 11.1. Either a change was not recorded or the record was never updated. Every mismatch is investigated, not overwritten blindly.
Before a firewall change, the relationships show it touches the HR (human resources) application and Teams calling, so two business services. The change risk, the window and the people consulted all follow from that.
When the data centre fabric fails, the incident is logged against that CI. The map shows Payroll is affected, so the service desk can tell the right people before they call.
A CMDB is only useful if people trust it. I measure completeness against discovery, the share of CIs with an owner and a status, and how recently each was seen.
Asset or configuration item?
| Thing | IT asset? | CI? | Why |
|---|---|---|---|
| A live core switch | Yes | Yes | It has financial value and it delivers service |
| A spare switch on the shelf | Yes | Not yet | It has value but delivers nothing until it is installed |
| A software licence | Yes | Sometimes | Tracked for cost and compliance; a CI only if service depends on it |
| The Payroll service | No | Yes | No purchase value, but the most important thing on the map |
| A carrier circuit | Contract | Yes | Its fix time and its relationships drive incident priority |
| A firewall rule base | No | Part of the firewall CI | Versioned with the device, compared against the approved backup |
IT asset management tracks value, cost and lifecycle. Service configuration management tracks what delivers service and how it fits together. The records overlap but the questions differ.
Record what you will use
I only add a CI class when a process needs it. For networks that means devices, pairs and stacks, circuits, sites, services and contracts. Interfaces and VLANs stay in the network tools unless a service depends on one.
Discovery feeds, people decide
Discovery and service mapping fill in what exists. People own what it is for: the service, the owner and the support group. A CMDB that is only discovery data cannot answer "who do I call?"
Changes update it
Every change that adds, moves or removes a CI updates the record in the same change. Monthly reconciliation catches what slipped through.
What an asset record holds, and disposal that can be proved, is on the end user computing page.
Release and DevOps
Release, deploy and change, at the speed of automation
ITIL 4 splits the old release and deployment process into separate practices, and renamed change management to change enablement. Together they let tested, repeatable work move fast and keep scrutiny for the changes that need it. That fits DevOps and SRE (site reliability engineering) far better than the old weekly CAB for everything.
Swipe sideways to see the whole diagram.
Change enablement, not change prevention. A change that has passed the same tests many times, with a known rollback, earns standard change status and flows straight to deployment. Anything new or riskier is routed to a change authority. The pipeline writes the change record itself, so the audit trail costs nothing.
- standard change
- normal change
| Practice | The question it answers | A network example |
|---|---|---|
| Release management | Is the new or changed service ready for people to use? | Cisco IOS XE 17.12 becomes the approved gold release for the campus |
| Service validation and testing | Does it meet its requirements? | Lab tests against the standard configuration, then a pilot site |
| Change enablement | Is it safe to change live service now? | Each upgrade wave is a change, assessed and scheduled |
| Deployment management | How does it get onto the live devices? | Images staged, hash checked and activated in waves |
ITIL 4 separates release from deployment: a release can be deployed in stages, and a deployment can sit unreleased behind a feature flag. Software versions here are examples.
ITIL alongside DevOps and SRE
| Site reliability engineering idea | Closest ITIL practice | How I combine them |
|---|---|---|
| SLOs (service level objectives) and SLIs (service level indicators) | Service level management | Internal objectives sit tighter than the SLA, so I act before a breach |
| Error budgets | Change enablement, risk management | While the budget lasts, standard changes flow. When it is spent, risky change pauses |
| Blameless postmortems | Problem management | The review feeds a problem record with owners and dates |
| Toil reduction | Continual improvement | Repeated manual work goes on the improvement register to automate |
| Infrastructure as code | Deployment, configuration management | The repository is the source of truth; the CMDB links to it |
Pipelines and source of truth tooling are on the network automation page.
Knowledge
Knowledge management, written while the fault is fresh
Knowledge management keeps information findable, trusted and current. For infrastructure that means runbooks, known errors, diagrams and design records. I use KCS (Knowledge-Centered Service) ideas with ITIL, because they make knowledge part of the daily work rather than a separate job nobody has time for.
Swipe sideways to see the whole diagram.
Knowledge as a by product of solving. The engineer searches first, uses an article if one exists, improves it if it is wrong, and captures a new one if not. Knowledge is written while the fault is fresh, not weeks later, and it gets better every time it is used.
An article that works at 3am
| Part of the article | What goes in it | Example |
|---|---|---|
| Issue | The symptom in the words the user or the alert used | "Phones at the Leeds branch keep rebooting" |
| Environment | Where it applies: platform, release, site type | Catalyst 9300 access switches, PoE phones |
| Resolution | The steps that fix it, and how to confirm | Check the PoE budget, move phones, raise a capacity change |
| Cause | Why it happens, once known | The power budget was exceeded after cameras were added |
The article structure used in KCS. The example is mine.
Shift left
Every article that lets first line fix a fault, or lets a user fix it themselves, moves work to where it is cheapest and fastest. Third line time then goes on problems and design.
Measure reuse
I track how often articles are linked to resolved tickets, the share of fixes at first contact, and articles flagged as wrong. Unused articles are archived.
Owners and dates
Every runbook and article has an owner and a review date. Network articles are checked after every software release, because commands and outputs change.
Improvement
Continual improvement, with a baseline and a date
Continual improvement is both a practice and part of the value system. ITIL gives a seven step model for it. I use the model for anything from a single queue to a whole support organisation. Step through it with a real kind of problem: repeat outages at branch sites.
Swipe sideways to see the whole diagram.
Agree the goal in business terms with the service owner: branch staff should not lose their tills because of the network. That ties the work to value, not to a tool.
Measure the baseline: 14 branch outages last quarter, 9 of them repeats, with an average of 3 hours to restore. Without a baseline nobody can prove the change worked.
Set a measurable target with a date: half the repeat outages within two quarters, and every site with a tested backup path. Targets come from the gap, not from a template.
Plan the work in small steps: fix the top three causes first, add a backup circuit at the worst sites, and write the knowledge articles. Each step has an owner.
Do the work through the normal practices: problem records, changes and releases. Iterate with feedback, checking each step does what it should before starting the next.
Compare against the baseline: repeat outages fell from 9 to 3. If the target was missed, learn why before adding more work.
Share the result with the people who did the work and the people who benefit, put the next target on the register, and keep the measures in the monthly service review.
The improvement register
| Idea | Benefit | Owner | Effort | Status |
|---|---|---|---|---|
| Backup path at the 10 branches with most outages | Fewer priority 1 incidents | Network lead | Medium | Approved |
| Auto create incidents from exception events only | Less noise for the NOC (network operations centre) | Monitoring owner | Low | In progress |
| Standard change model for access port VLAN changes | Requests done in hours, not days | Change manager | Low | Done |
| Article for every top 10 fault category | More first contact fixes | Service desk lead | Low | In progress |
| Retire the second monitoring tool | One view, lower cost | Tools owner | High | Proposed |
An example improvement register. Each idea has a benefit, an owner, an effort estimate and a status, and the register is reviewed every month.
Measures, and how they mislead
| Measure | What it tells me | Watch out for |
|---|---|---|
| First contact resolution | How much first line can fix | Closing tickets early to hit the number |
| MTTR (mean time to restore) | How fast service comes back | An average hides the long tail; I look at the 90th percentile too |
| Reassignments per ticket | Whether routing works | Teams bouncing tickets to stop their own clock |
| Change success rate | Changes with no incident or back out | Failed changes recorded as successful with a follow up change |
| Repeat incidents | Whether problem management works | Repeats logged under new categories |
| User satisfaction | What people actually feel | Surveys only sent on tickets that went well |
Measures I report monthly. Targets vary by organisation, so none are given here.
SLAs and XLAs
An SLA measures what IT delivers. An XLA (experience level agreement) measures what users experience, such as how long a new starter waits to be productive. I use both, because each catches what the other misses.
The watermelon effect
Green on the outside, red inside: every SLA met while users are unhappy. It happens when the measures count tickets, not outcomes. Satisfaction, reopens and repeat faults expose it.
Measures drive behaviour
People optimise for what they are measured on. I pick few measures, explain why each matters, and review them together so nobody games one at the expense of another.
Try it: a quick maturity check
Six questions I ask at the start of an engagement. Choose the answer closest to your team. This is an indicative starting point, not the ITIL maturity assessment, which scores each practice on capability levels from 1 to 5.
Indicative score: 12 out of 18, defined but not yet measured. The basics exist. The next gain usually comes from measuring outcomes and giving each practice an owner who acts on them.
Tooling
ITIL in the tools, without bending the tool
ITIL is tool neutral, but most organisations meet it through an ITSM (IT service management) platform. These are the platforms I meet most, with where each practice lives. Module names change between releases, so I check them against the current version on each engagement.
ServiceNow
| Practice | Where it lives |
|---|---|
| Incident, problem and change | Incident Management, Problem Management, Change Management, with change models and conflict checks |
| Service requests and the catalogue | Service Catalog and Request Management, with fulfilment workflows |
| Service configuration management | The CMDB, filled by Discovery and Service Mapping |
| Monitoring and event management | Event Management, part of IT operations management, which turns alerts into incidents |
| IT asset management | Hardware Asset Management and Software Asset Management |
| Service level management | SLA definitions with response and resolution timers |
| Knowledge management | Knowledge bases with article review and feedback |
| Measurement and continual improvement | Performance Analytics and Continual Improvement Management |
ServiceNow is in my core skills. I design the routing, the CI classes and the change models first, then configure the platform to match.
Jira Service Management
| Practice | Where it lives |
|---|---|
| Service requests | Request types and queues behind a self service portal |
| Incident and problem | Incident and problem records, linked to development work in Jira |
| Change enablement | Change requests with risk assessment and approvals, and deployment tracking from pipelines |
| Service configuration management | Assets, formerly called Insight, for CIs and their relationships |
| Service level management | SLA goals with calendars per request type |
| Knowledge management | A knowledge base in Confluence, suggested on the portal |
A good fit where development teams already work in Jira, so incidents, problems and code changes link directly.
Other ITSM tools
| Tool | Where I see it |
|---|---|
| BMC Helix ITSM | The successor to BMC Remedy, common in large enterprises |
| Ivanti Neurons for ITSM | Service management with asset and endpoint tooling alongside |
| Freshservice | Quick to set up, popular with mid sized organisations |
| TOPdesk | Common in UK education and the public sector |
| ManageEngine ServiceDesk Plus | Service desk, assets and CMDB, on premises or in the cloud |
The practice design carries over between tools. The data model and the integrations are what take the time in any migration.
Rules I follow when configuring a tool
- Process before product. I map the value streams and agree the routing and CI classes before anyone configures a form. A tool cannot fix a process nobody agreed.
- Fewer fields, better data. Every mandatory field must be used by a report or a rule. Otherwise analysts fill it with whatever is first in the list.
- One record of each thing. One CMDB, one change calendar and one knowledge base, even when several teams and suppliers use them.
- Integrate the monitoring. Events create and update incidents automatically, with the CI attached, so nobody retypes an alert.
- Stay close to the platform. Heavy customisation makes every upgrade a project. I configure first and customise only for a clear business reason.
Versions
From v3 to ITIL 4 and on to Version 5
Most organisations I work with still run processes set up under ITIL v3, with ITIL 4 language arriving through training and tools. Knowing how the versions map onto each other avoids long arguments about names, and lets a team keep what works.
Swipe sideways to see the whole diagram.
The UK government's CCTA (Central Computer and Telecommunications Agency) published the first ITIL books, as practical guidance for running government IT. The library grew to dozens of volumes.
Published from 2000, as the CCTA became part of the OGC (Office of Government Commerce). Service support and service delivery became the core books, with the service desk and incident, problem, change and configuration management at their heart.
In 2007 ITIL v3 organised everything as a service lifecycle of five stages: strategy, design, transition, operation and continual service improvement, with 26 processes and four functions.
A 2011 update made v3 clearer and more consistent without changing its shape. Much of the ITIL still running in organisations today was set up to this edition.
Launched in February 2019 by AXELOS, then a joint venture of the UK Cabinet Office and Capita. It replaced the lifecycle with the service value system and the processes with 34 practices. PeopleCert bought AXELOS in 2021.
PeopleCert began releasing ITIL Version 5 in 2026, starting with Foundation in February. It keeps the principles, the four dimensions, the value system and the 34 practices, and adds a product and service lifecycle and guidance on AI (artificial intelligence).
Swipe sideways to see the whole diagram.
Service Strategy becomes mostly plan, with demand and business relationships in engage. Portfolio, financial and strategy management carry on as practices.
Service Design becomes design and transition, with some of its work in plan. Service level, capacity, availability and continuity management carry on as practices.
Service Transition splits between design and transition and obtain or build. Its release and deployment process became two separate practices.
Service Operation becomes deliver and support, while the service desk sits mostly in engage. The four v3 functions became parts of practices rather than teams.
Continual Service Improvement becomes the improve activity, and continual improvement also appears as a practice and as a part of the whole value system.
What carries over
The guiding principles, the four dimensions, the service value system and the 34 practices all carry into Version 5, with minor changes to terms. Teams running ITIL 4 well are most of the way there.
What is new
A digital product and service lifecycle with eight activities: discover, design, acquire, build, transition, operate, deliver and support. Guidance on AI runs through the whole framework.
What I do about it
I keep ITIL 4 as the working baseline on current engagements, read the new lifecycle against the product teams I work with, and adopt Version 5 terms when the organisation's tools and training move.
Certification paths
| Level | ITIL 4 | ITIL Version 5 |
|---|---|---|
| Entry | ITIL 4 Foundation | ITIL Foundation (Version 5), the single entry point |
| Practitioner | Practice Manager, built from practice modules | Role based modules, with a Practice Manager path |
| Professional | Managing Professional: four modules on creating, delivering and supporting services, stakeholder value, high velocity IT, and direction and improvement | Managing Professional, with a transition course for ITIL 4 holders |
| Leader | Strategic Leader | Strategic Leader |
| Expert | ITIL Master | ITIL Master |
The Version 5 scheme was still being released through 2026, so I check PeopleCert's current list before planning training. ITIL 4 Foundation remains valid as the prerequisite for Version 5 modules.
When it goes wrong
When ITIL goes wrong, find the stage that fails
Service management faults show up as unhappy users and tired engineers, not as alarms. I trace them the way I trace a network fault: follow one ticket through each stage until I find where it fails. Choose a symptom to see where it usually sits and what I check. My general fault finding method is on the troubleshooting page.
Swipe sideways to see the whole diagram.
Alert storms bury real faults. Every change of state raises an alert, so the people on call stop reading them. I classify events with the service owner, correlate through the CMDB, suppress alerts during approved changes, and remove any alert that never leads to action.
First line escalates almost everything. First line has no articles or access for the common faults, or the categories are too vague to act on. I take the top categories, write articles, give first line safe checks and tools, then measure first contact fixes each month.
Tickets bounce between teams. Tickets route on vague categories, or the CI in the CMDB has no support group. I route on the affected service and CI, fix the categories with the teams that receive them, and agree that a group keeps a ticket until another accepts it.
Simple requests take days. Routine requests are logged as incidents, or wait for approvals that add nothing. I add catalogue items with pre approval for low risk requests, automate fulfilment where I can, and measure time spent waiting as well as time spent working.
The same fault keeps coming back. Incidents are closed with a workaround and nobody raises a problem record. I set a trigger, such as three incidents on one CI in a month, review the top repeat CIs weekly, and give each problem an owner and a date.
Changes wait weeks for approval. Every change goes to one board whatever its risk, so the board approves them without real review. I add standard change models for repeatable low risk work, delegate approval by risk, and keep the board for changes that need debate.
Nobody trusts the CMDB. It was loaded once and never kept up. I cut it to the CI classes a process uses, feed it from discovery, make every change update it, and report completeness each month until teams rely on it.
Every SLA met, users still unhappy. This is the watermelon effect: the SLAs measure ticket handling, not outcomes. I read the comments, add measures users feel, such as time to be productive, and review them with the business each month.
Health checks I run every month
| Monthly check | Healthy looks like | If not |
|---|---|---|
| Incidents with a CI attached | Nearly all, so trends per CI mean something | Make the CI mandatory at resolution, filled from the event |
| Problems opened from repeat incidents | Every top repeat CI has a problem record | Review the top repeats weekly |
| Standard changes as a share of all changes | Rising as models are added | Look for repeatable work still going to the board |
| Articles used to resolve tickets | Rising, with few flagged as wrong | Fix or archive the flagged articles first |
| Improvement register items closed | Some every month, each with a measured benefit | Fewer, smaller items with named owners |
Indicative checks. The right level for each depends on the organisation and its baseline.
Engagement
How I bring ITIL into an infrastructure service, from first workshop to steady state
ITIL work usually starts with a complaint: tickets bounce, changes wait, nobody trusts the CMDB, or a new service is about to go live with no support model. I follow the same path each time: agree what matters, find out how work really flows, design the practices and their owners, prove them with a pilot, then keep them improving.
Swipe sideways to see the whole diagram.
I start with the services that matter most and the people who own them, not with the tool. I agree what good looks like for users, which teams and suppliers are in scope, and who decides. A RACI (responsible, accountable, consulted, informed) chart names each practice owner.
I turn the goals into requirements for each practice and service: what must happen, how fast, and what must be recorded. Service levels must add up from suppliers to users. Security and audit needs, such as change records for regulated systems, are written in now.
Before designing anything I study how work really flows. I export a year of tickets and look at categories, reassignments, repeat CIs and time spent waiting. I sit with the service desk, sample the CMDB against discovery, and score each practice against its purpose.
The design sets the value streams, the practices and their owners, the routing and assignment groups, the CI classes and relationships, and the change models. Every decision traces back to a goal agreed at the start. Tool configuration follows the design, not the other way round.
The tool is configured to the design and tested with real tickets from the discovery data. A pilot with one resolver group proves the routing and the measures. Training, knowledge articles and a cutover plan with a rollback are ready before the wider launch.
After go live, each practice owner has a dashboard and a monthly review. Hypercare, the period of extra support after go live, ends only when agreed measures hold for a set period. Service and supplier reviews use the same numbers, so nobody argues about whose data is right.
Practices need upkeep like any system. I review each one quarterly against its measures and remove steps and fields nobody uses. I test tool upgrades before they reach production, and plan when to adopt new guidance such as ITIL Version 5 and its product and service lifecycle.
Functional requirements
What it must do.
- Log every incident, request and change against a service and, where known, a CI.
- Route work to the right resolver group on the first assignment, using the service and the CI.
- Create incidents automatically from exception events, with the CI attached.
- Offer approval routes that match the risk of each change, with standard changes pre approved.
- Report each practice's measures to its owner, and each service's levels to its owner.
- Keep knowledge articles where first line and users can find them.
Non functional requirements
How well it must do it, with a number wherever one can be agreed.
- Response
- Priority 1 incidents acknowledged within 15 minutes, at any hour the service runs (typical).
- Routing
- Most tickets resolved with no more than one reassignment (typical aim).
- Change
- Standard changes approved at once, normal changes assessed within days rather than weeks (typical).
- CMDB accuracy
- Over 95% of discovered devices matched to a CI with an owner and a status (typical aim).
- Event noise
- Most pages lead to action, and alerts that never do are reviewed monthly.
- Audit
- Every change to a regulated system traceable to an approved record.
- Resilience
- A fallback way to log and track incidents when the ITSM platform itself is down.
- Data protection
- Personal data in tickets kept to what is needed, under UK GDPR (the General Data Protection Regulation).
Figures are typical starting points. Each organisation agrees its own from its baseline.
Who I talk to
- Service owners and business relationship managers
- Service desk analysts and team leaders
- Resolver group leads in network, server, cloud and security
- Suppliers who receive or raise tickets
- Tool administrators and the reporting team
How I find out
- A year of ticket data: volumes, categories, reassignments and time in each state
- Value stream mapping workshops for the top five kinds of work
- Sitting with the service desk for a full shift
- Sampling CMDB records against discovery and the devices themselves
- Scoring each practice against its purpose and its measures
Discovery tools
| Tool or source | What it tells me |
|---|---|
| ITSM platform reports and exports | Volumes, categories, reassignments and time spent waiting |
| Process mining, such as ServiceNow Process Mining or Celonis | The real paths tickets take, not the ones on the process diagram |
| Discovery and service mapping | Which CIs exist, and how services depend on them |
| Monitoring and event consoles | Alert volumes, and how many lead to incidents |
| User satisfaction surveys | What users feel, by service and by team |
| The ITIL maturity model | Capability levels for each practice, as a structured baseline |
When a practice is not working, I want to know whether the cause sits with people, information, suppliers or the process itself, because each needs a different fix.
My approach
- Symptom. What exactly is wrong, for whom, and since when: a measure, a complaint or an audit finding?
- Data. Pull the tickets behind it, and check the data is complete enough to trust.
- Trace. Follow a sample of tickets through every stage to find where they stall.
- Dimension. Decide which dimension holds the cause: people, information and technology, partners, or the value stream.
- Fix. Change one thing through the improvement register, with an owner and a date.
- Prove. Compare the measure with the baseline before calling it fixed.
Causes I see most
- Tickets routed on vague categories
- CIs with no owner or support group
- One weekly board for every change
- Workarounds with no problem record
- Measures that count tickets, not outcomes
- Supplier contracts that do not support the SLA
Layer by layer
| Layer | What I check |
|---|---|
| Organisations and people | Are roles clear, skills present and owners active? |
| Information and technology | Is the data complete, and is the tool configured to the design? |
| Partners and suppliers | Do contracts and supplier processes match the promise? |
| Value streams and processes | Does work flow, or wait between teams? |
| Governance | Is anyone reviewing the measures and acting on them? |
| External factors | Has a regulation, a cost or a technology change altered what is needed? |
My general fault finding method, with worked faults, is on the troubleshooting page.
Service management needs its own support model. A practice without an owner and a rhythm of review drifts back to how things were.
Practice owners
One named owner for each practice, accountable for its process, its data and its measures.
Service owners
One owner for each business service, who chairs its monthly review with users and suppliers.
Tool administration
A small platform team for the ITSM tool, with its own backlog, release plan and test environment.
Reporting
Dashboards for each practice and each service, built on one set of definitions.
Suppliers
Supplier tickets and escalations through the same tool, or an integration, measured against their contracts.
Hypercare
Extra support after go live, ending only when the agreed measures hold.
Frameworks, tools and services all change. I plan their upkeep from the start.
- Quarterly reviews. Each practice owner reviews measures, open improvements and unused steps every quarter.
- Tool upgrades. Platform upgrades are tested against the configured workflows before production, because each release changes forms and defaults.
- Catalogue. Services and request items are retired when they are no longer offered, so nobody requests a dead service.
- CMDB. CI classes and relationships follow new platforms, such as cloud services and SD-WAN edges, as they arrive.
- Training. New staff and suppliers learn the practices they use, with ITIL Foundation for anyone who needs the common language.
- New guidance. I read new ITIL guidance against current practice, and adopt its terms when the tools and training move with it.
Projects
Where I have used it
I design for operation from the first workshop, so service management runs through every role on my CV. These are the roles where change governance, support and operational handover were a large part of the work.
Change governance through a regulated refresh
Delivered the EMEA (Europe, the Middle East and Africa) Network Refresh with a blended team of 5 engineers and 4 vendors, advising on change governance and architecture standards. The estate stayed compliant with MiFID II (the Markets in Financial Instruments Directive) throughout, with no service outages.
Support and operations after a merger
Post merger infrastructure integration across a multi site estate, including distribution centres. Rationalising infrastructure, support and technology overheads saved £700k a month across support and operations.
Standards every regional team adopted
Set the design authority standards adopted by every regional delivery team. Over £200M of transactional services were safeguarded through data centre transitions at 99.99% uptime, and every global site was upgraded remotely during the lockdowns with no delay.
From discovery to operational handover
Lead architect on network, cloud and data centre modernisation programmes from discovery to operational handover across several client environments. Planned and ran remote site migrations across regulated environments with no critical incidents.
Managed infrastructure for 300 sites
Tier 3 data centre and managed infrastructure for over 300 customer sites on Cisco ACI (Application Centric Infrastructure) and Nexus.
Architecture alongside business as usual
Directed architecture and delivery across AWS (Amazon Web Services), Google Cloud, Azure, disaster recovery, Catalyst SD-WAN, SD-Access and security, and led and mentored a team of 4 engineers alongside BAU (business as usual) work.
Backed by ITIL v3 and ITIL 4, with PRINCE2 Practitioner for the projects that change services, and ServiceNow in my core skills. See all credentials
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.