I’ve completed ITIL v5 Foundation, Strategy and Product now, and one of the things I’ve found most useful about the courses is that I’m able to relate quite a lot of the material back to things I’ve already experienced in IT support.
I’m not saying I’ve suddenly become a service management expert because I’ve completed a few courses. I haven’t. A lot of what I’ve learned is still theory that I haven’t had the opportunity to apply in a formal service management role.
What I do have is a few years of practical experience to compare it against.
That’s probably why the learning has been useful to me. I’m not learning the concepts in complete isolation. I’ll come across something in the course and think about a ticket I’ve worked on, a customer visit I’ve been involved in, a process I’ve had to document or an issue that kept coming back.
Sometimes the course gives me a better way of understanding something I’ve already seen.
I’ve started thinking more about the outcome#
One of the things that has stuck with me is the difference between doing something and actually creating a useful outcome.
In IT support, it’s very easy to focus on the activity in front of you. A ticket comes in, you investigate it, you fix the issue and you close the ticket.
That’s obviously important. If someone can’t work because something isn’t functioning properly, getting them back up and running is the immediate priority.
But I’ve found myself thinking a little more about what happens around that.
Did we actually restore what the person needed? Was the fix appropriate? Did we understand what caused the problem? Is there something useful we should record? Is this likely to happen again?
That’s where the idea of value co-creation made more sense to me.
The value isn’t created by the IT team simply completing an activity. There is a relationship between the people providing the service and the people using it, and both sides contribute to the outcome.
I’ve seen this in quite ordinary support situations.
A user can explain what they’re trying to achieve in a way that gives you information you wouldn’t get from the ticket alone. An engineer can investigate the technical side, but the user understands the impact on their work. Putting those two things together gives you a much better chance of reaching the right outcome.
It’s made me think less about “closing the ticket” as the end of the story and more about whether we’ve actually achieved what was needed.
The four dimensions helped me look beyond the technology#
The four dimensions were another part of the course that I found easy to relate back to real work.
Working in IT support, it’s natural to spend most of your time thinking about technology. If a device isn’t compliant, you look at the device. If someone can’t sign in, you look at authentication. If an application isn’t working, you start investigating the application.
But the technology is only one part of what makes a service work.
There are people and organisations involved. There is information and technology. There are partners and suppliers. There are value streams and processes.
I’ve seen examples of all of these in my own work.
A technical problem can sometimes be made harder by a process that isn’t clear. An escalation can be delayed because the right information hasn’t been captured. A customer issue can be more difficult to understand because the technical description doesn’t really explain the impact on the person trying to work.
None of those are purely technical problems.
That doesn’t mean every support issue needs to become a service-management exercise. It just means I’ve become more aware that the technology I’m troubleshooting is sitting inside a much bigger system.
Value streams made me look at what happens between the ticket being raised and the outcome#
This is probably one of the areas I’ve found most interesting.
When you’re working on a ticket, you’re naturally focused on the part of the process in front of you.
A user raises something. I pick it up. I investigate it. Maybe I resolve it, or maybe it needs to go to another team.
But there is a lot happening around that ticket.
Information has to be gathered. Someone has to decide what needs to happen next. There might be an approval. Another team might need to investigate something. The issue might come back because the original information wasn’t enough.
When you look at the whole flow, you start to see where work can get slowed down.
I’ve experienced that through escalations and through working across different customer environments. Sometimes the technical issue itself isn’t particularly difficult. The difficult part is getting the right information to the right person, understanding ownership or working out what needs to happen next.
That’s what I find interesting about looking at the value stream.
You stop looking only at your part of the process and start asking whether the whole thing is working well.
Continual improvement doesn’t have to mean rebuilding everything#
Continual improvement is another area where the theory connected quite easily with things I’ve already done.
When you hear the word “improvement”, it’s tempting to imagine a big project with a new system, a new process and months of planning.
It doesn’t always need to be like that.
I’ve worked on documentation where the existing information no longer matched the way the process actually worked. In that situation, the improvement wasn’t some huge transformation programme. It was looking at what was there, understanding what had changed and making the information more useful.
I’ve also seen recurring issues where the useful question isn’t just how to fix the individual ticket, but whether there is something that could be changed to reduce the chance of the same issue happening again.
Sometimes the answer will be no.
Sometimes the issue is unavoidable.
Sometimes the improvement is simply making a knowledge article clearer or making an escalation contain better information.
I like that approach because it feels practical.
You don’t need to make everything bigger than it needs to be in order to improve it.
Strategy made me think more about why the service exists in the first place#
The Strategy course was probably the point where I started thinking more about IT beyond the immediate support activity.
When you’re working in support, it’s easy to focus on whether something is working.
But services exist for a reason.
They’re there to enable people and organisations to achieve something.
If a system is unreliable, if users can’t access something they need or if a process constantly creates delays, that eventually has an impact beyond the individual support ticket.
I’ve seen this from the support side.
You can resolve the immediate issue, but there can still be a wider effect on the customer or the organisation.
I’m not involved in setting organisational strategy in my current role, and I wouldn’t claim that I am. What the course has done is make me more aware of the connection between the work happening at the support level and the outcomes the wider organisation is trying to achieve.
That’s a useful perspective to have.
Product made me think about services as things that need to be looked after#
The Product course built on some of this for me.
I found myself thinking more about the fact that a product or service isn’t something that can simply be created, handed over and forgotten about.
The environment changes.
Technology changes.
People’s needs change.
Requirements change.
The way people use something can change as well.
That means there needs to be some thought about how the service continues to provide value as those things change.
Again, I’ve seen smaller versions of this in support.
Documentation becomes outdated.
A process changes.
A device configuration needs to be reviewed.
A workaround that was useful six months ago is no longer appropriate.
Those things don’t necessarily look like “product management” when you’re dealing with them on a Tuesday afternoon, but the underlying idea is there. Things need to be looked after and reviewed rather than assuming that because something works today, it will always work tomorrow.
The biggest thing ITIL has given me is a different way of looking at work#
I think that’s probably my biggest takeaway from the courses.
I haven’t suddenly started approaching every ticket by thinking about ITIL terminology.
If anything, I’d find that quite frustrating.
What has changed is the questions I sometimes ask myself while I’m doing the work.
Is this actually achieving the outcome the user needs?
Why does this keep happening?
Where is this work getting stuck?
Is the process helping or getting in the way?
Does the person I’m handing this over to have what they need?
Is there something we could improve?
Are we creating value for the people using the service?
Those questions are useful even if you never use the ITIL terminology.
The framework just gives me a better way of understanding why those questions matter.
I’m still learning#
There is still a big difference between studying service management and spending years working in a formal service management role.
I’m conscious of that.
What I can say is that studying ITIL v5 has changed the way I look at the work I’m already doing.
I’m still troubleshooting devices, investigating Microsoft 365 issues, working with Entra ID and Intune, supporting users and dealing with the practical problems that turn up in an IT support environment.
That hasn’t changed.
What has changed is that I’m increasingly aware of the service around those individual problems.
For me, that’s the useful combination.
The practical experience gives me something real to relate the learning to, and the learning gives me a better way of thinking about what I’m seeing.
I think that’s a much more useful outcome than simply having another certificate on the wall. For me, that’s the useful combination.