There are Seven Guiding Principles in the new ITIL 4 Foundation book. These principles are not in fact new – they were initially published in the ITIL Practitioner book a couple of years ago, but they have only really gained traction through ITIL 4. The Guiding Principles are intended to set the boundaries and direction for everything: organisations and people, information and technology, value streams and processes, partners and suppliers – building on the familiar management analysis tool of PESTLE (political, economic, social, technological, legal, environmental).
So, let’s go through them.
Focus on value
This is a reminder that everything we do must add value to the organisation, whether to our internal users or our external members. Essentially, if it’s adding no value, don’t do it, don’t invest in it. Everything we do “needs to map, directly or indirectly, to value” for our stakeholders. And yes, that means you also have to consider the value of what you want to do for stakeholders in other areas:
- you want a new tool – have you considered what tooling you already have that could do the same job?
- you want to create a new report – have you done your homework to see if someone is already collating the same or similar data?
- you need to fix a process – do you know who the process owner is, and have you spoken to them about improvements coming?
Value is in more than your immediate circle – to understand the true value of what you want to do, you need to embrace your circles of influence.
Start where you are
One of the biggest mistakes often made is throwing out the baby with the bathwater. How often do we fail to capitalise on existing success stories in the pursuit of innovation? This Guiding Principle states, “Do not start from scratch and build something new without considering what is already available to be leveraged… there is likely to be a great deal in the current services, processes, programmes, projects, and people that can be used to create the desired outcome”. This, in short, is about understanding that your existing state is as much about what works really well and what can be taken forward as about what are the pain points. Don’t assume that the pain points are caused by the existing situation as a whole. There will be things that work fine – keep them! They will provide a degree of continuity when embracing change, and this will make the change easier to sell.
Progress iteratively with feedback
This is a well-known agile principle but does not have to be limited to software development. Essentially this means, “Do not attempt to do everything at once”. Work can be organised into smaller, manageable sections. It becomes easier to keep focus and achieve the desired outcome. You should not underestimate the feedback part of this Principle – it is key. What is the point of making tweaks to your process if you do not test for its usability or effectiveness? It might make perfect sense to you, but if the people using the process find it non-intuitive or cumbersome, they will not use it. Allowing your stakeholders to communicate their perceptions allows you to build more value in to your process. There’s that value word again!
Collaborate and promote visibility
When many of us are working in relatively small, focussed groups, utilising agile methodology to deliver products and services, this Principle can be a real challenge. We tell ourselves that as a team we are collaborating on a grand scale and sharing our knowledge with each other, perhaps forgetting that we are failing to collaborate and share knowledge with other small, focussed groups who are our stakeholders (either upstream or downstream of us). This Principle is derived from the understanding that, “working together across boundaries produces results that have a greater buy-in and more relevance to objectives, as well as an increased likelihood of long-term success”.
Achieving objectives requires information, understanding and trust. Trust, here, is the key word. People within an organisation need to believe that their needs will be catered for: for example, one squad/tribe will consider the needs of the other squads/tribes, in addition to the needs of Centres of Excellence (CoE) and any other teams that are not a squad, tribe or CoE. Likewise, a CoE will consider the need to enable autonomy across squads/tribes without stifling innovation but still protecting service. Interestingly, ITIL 4 states quite blatantly that “hidden agendas need to be avoided”. There should be no secrets between friends.
Think and work holistically
“No service, or element used to provide a service, stands alone. The outcomes achieved by a service provider and service consumer will suffer unless an organisation works on the service as a whole, not just on its parts”. Again, this is a real challenge when you are working in smaller, focussed groups. The advent of DevOps ways of working should address this: those who build also support, but unless an organisation shifts its focus to a holistic approach, the service or system interactions will still be missed. Consider: Service A is built and supported by Squad 1, but has interactions with Service B which is built and supported by Squad 2. In addition, it also interfaces to legacy Service X which is managed by teams outside of the squads. How then do you make sure that your iterative progress is holistic – it demands cross working, not just within your focussed team, to drive the real value.
Keep it simple and practical
“If a process, service, action or metric fails to provide value or produce a useful outcome, eliminate it. Use the minimum steps necessary to accomplish the outcome”. Sounds easy, but this can often be difficult to achieve. When you have developed and matured a process over years, it can be difficult to let go of your ‘baby’. However, this goes back to focussing on value – we all need to look very hard at our ways of working:
- Why do we do that? What outcome are we after?
- Who do we engage with? Who are we trying to influence?
- Does the process/service add value to our organisation’s objectives?
So, the first thing to look at is how we are adding value to our objectives. Keeping something just because it has always been there is not the answer; continuing to provide a particular report to management may also not be the answer – have you checked recently why management want that report, have the drivers behind the initial need been removed by improvements? These are the types of questions we need to ask ourselves in the pursuit of simplicity.
Optimise and automate
Essentially, this Principle is about eliminating anything that is truly wasteful and using technology to achieve whatever it is capable of. Resources of all types, and particularly people, should be used to their best effect. The ITIL 4 Principle states that, “Human intervention should only happen where it really contributes value”. So then, the way we use our people should be focussed on where they can deliver value – not on repeatable processes or procedures that could be automated, but on safeguarding service, managing stakeholders, designing holistic services and embracing/incorporating feedback from our members and customers.
All the ITIL 4 Guiding Principles make perfect sense in our modern world. The challenge to us is embracing them wholesale in the ways that we work, not just within our own teams, but across the entire eco-systems that are our organisations.
