The 7 Guiding Principles of ITIL 4
by Markos Symeonides, on 02-Jan-2020 15:45:00
The 7 Guiding Principles of ITIL 4 are the key messages of ITIL. They are designed to guide decisions and actions so the people who are responsible for managing and operating the organization’s service portfolio can benefit from these high-level best practices.
These principles aren’t new. They’re influenced by ideas born in disciplines outside of service management (such as manufacturing and software development) but have now been proven in the service context.
These principles don’t stand alone either. They overlap and interact; they are mutually beneficial. For example, the think and work holistically principle relies on the collaborate and promote visibility principle. The progress iteratively with feedback principle will help you ensure you are always focused on value; especially in a rapidly changing environment.
The interplay between these principles means that they cannot be “implemented” or adopted one by one. You cannot simply decide that from now on, you are going to “Focus on value” and next week you will “Start where you are”.
We will look at each of the seven 7 principles in detail, but first let’s take a step back.
What is a principle?
A principle is an idea or notion which communicates how decisions should be made and actions taken. A principle is universally accepted because it has been tried-and-tested across many different variations of the same broad situation. Fundamentally, principles convey wisdom: a way of thinking about a situation which has been proven as valuable.
In business, principles are valuable because they allow leaders to broadly influence the way people think and work without getting directly involved in every problem or challenge. They enable leaders to devolve decision-making down the organization, empower employees to make decisions and take actions without escalation. When people internalize these ideas, they become part of the ethos and character of the organization. They become part of the organization’s culture; part of its “muscle memory”. Through the establishment of principle, an organization’s culture changes and people behave in a certain way without constant direction.
Focus on value
It seems strange to say that service management shouldn’t focus on services, but focusing on value is about recognizing services for what they are—a vehicle for value. It is the outcome of the service which is of value to the customer, not the service itself. For example, a car hire service isn’t about having access to a car, it’s about getting from A to B. The car service is a means to an end. The technology, assets, people, and other elements are simply a part of that. And when people focus too much on the components of a service, it’s easy to become detached from the bigger picture of value, and wasteful elements can creep into the service ecosystem. The obsession with value, and the identification and elimination of wasteful activity, comes from Lean thinking.
The people who are part of the service supply chain must always ask: “Who is the customer?”, “Why do they need this service?” and “Is what I’m doing now helping to create value for them?” To focus on value, you must have a clear idea of what value means in each instance. To do this, you need empathy for the service consumer (a Design Thinking concept). Organizations must make efforts to identify the true needs of customers—so they can avoid designing services based on assumptions.
Start where you are
It was American tennis player Arthur Ashe who first said “Start where you are, use what you have, do what you can”. It was a new expression, but the sentiment was already an old one.
Outside of a start-up, few business opportunities happen in a “greenfield” site; an empty space where there is no pre-existing capability. Most of the time, the challenge is to build something new and better where some capability already exists. It can be tempting to throw everything you have away, start from scratch and aim for something fresh and perfect. But starting from scratch usually means walking backwards from where you are now.
You will already have some of the people, skills, knowledge, processes and assets that you need, so think about how you can move forward with what you’ve got. To do this, you need to assess where you are now—using a combination of measurement and direct observation to triangulate the truth about your current capabilities and performance, so you can objectively identify what you can adapt and reuse to get you closer to where you need to be, more quickly.
It is easy to assume that every part of a sub-optimal capability is also sub-optimal, but this is often not the case. Many of the old “components” may be fit-for-purpose in the new context.
So, when you are facing a challenge and wondering where to begin, start where you are—but be aware that you will need to apply organizational change methods to get people to adapt old behaviors. People change is always the trickiest aspect of moving forward.
Progress iteratively with feedback
You can’t do everything at once—or to use the cliché, you shouldn’t try to “boil the ocean”. Trying to tackle too many things at once is a recipe for staff burnout. Aim to deliver small chunks of value early; have the customer validate what you are doing to make sure you really are heading in the right direction; build on what you have done based on what you have learned from the customer.
The Progress iteratively with feedback principle integrates agile principles into ITIL 4. The idea of making progress in small steps and validating each with the customer comes from the agile development philosophy. Where the waterfall process model uses a single monolithic cycle, an agile approach involves short, timeboxed iterations, framed by engagement with the customer to validate the value created.
In an age where innovation happens quickly, the customer’s view of value can change quickly. The Agile Manifesto recommends “Responding to change over following a plan”. An iterative approach will enable you to respond to changes in the perception of value; but a rigid waterfall approach “locks-in” the definition of value at the start—and any shifts are usually discovered when it is already too late.
Collaborate and promote visibility
Typically in large organizations, processes, projects, and service value streams can flow across many teams and departments—there are many moving parts working across different disciplines, operated by different Subject Matter Experts (SMEs). In an organization it is necessary to develop specialist expertise so that tasks can be routed to the people who have the skills to perform them. This is the benefit of specialization. The problem with specialization is that it promotes “tunnel vision”—a narrow focus.
For this reason, when it comes to solving problems spanning multiple specialist teams (for example, the network, datacenter, database, and application teams), finding a solution (or more accurately, the best solution) requires collaboration. However, typically an issue will be bounced around from team to team. The network team will pass it to the application team. The application will pass it to the database team. The database team may decide it’s an infrastructure issue and pass it to the datacenter team.
Sometimes this works. On other occasions, the issue may be caused by a combination of underlying factors, but these teams are not collaborating to consider all the possible angles. Specialization creates siloes. Siloes prevent the flow of information and knowledge; one team does not have visibility of what another team is doing. Collaboration and making work visible between teams are the antidotes to the inherent problems of a siloed organization.
The collaborate and promote visibility principle is closely connected to the think and work holistically principle (which we will look at next). For people to collaborate effectively on projects which span many teams, they must all understand the holistic perspective—they must see the bigger picture.
DevOps is a prime example of a situation where there is a need to both think and work holistically and collaborate and promote visibility. Development and operations people must see the bigger picture—that Dev and Ops are part of a larger value chain. Developers must consider the downstream implications of new and altered code. Ops people must consider the upstream impact of changes to the production environment. Both must consider the impact of what they are doing on the customer.
Clearly, enabling a faster, safer flow of value from Dev to Ops to customer, requires better collaboration and clear visibility. As a result, collaborative organizations are typically more agile and resilient.
Think and work holistically
Like collaborate and promote visibility, this is another anti-silo principle. A holistic viewpoint is necessary because nothing happens in isolation—there is always a bigger picture to be seen. The delivery of services requires coordination of activities performed by different teams and automated systems. Thinking and working holistically means thinking and working across teams, departments, systems and other boundaries to focus on creating value. The parts need to work together to create a clean flow of value across the value chain.
Few of an organization’s products and services start and end within the same team or department. More often, the chain of activities that makes up a service involves many moving parts. So, the people and teams who perform the different parts of a value stream must be aware of how the work that they do fits in with the rest of the value stream, and that there is a customer at the end of it.
It is important to understand how the value chain integrates into a complete, end-to-end process. What are the inputs and outputs of each step? Are the handovers efficient? Is there a smooth flow? Or do teams need to constantly loop backwards to ask for more information on what was passed down?
This holistic perspective is particularly important when change is applied: a change to one step in the value stream can have an impact on upstream and downstream steps, so changes must be assessed from a whole-view perspective. Often, a well-intentioned improvement made by one team can break a value chain.
Working in siloes means people often fail to spot opportunities and risks. So, to deliver optimized services (and minimized risks), it is important to work with the various stakeholders to ensure that everybody is on the same page.
The 4 Dimensions of ITIL 4 provide a useful tool here to ensure you are considering all the necessary angles. The 4 dimensions cover value streams and processes, information and technology, organizations and people, and partners and suppliers. People are the collective representatives of the whole system, so close collaboration is critical. When change is required, it is necessary to pull together the people who represent parts of the system to discuss the change from both the systemic perspective and the holistic outcome perspective. It is necessary to appreciate the complexity and fragility of a value chain—and this cannot happen when teams operate as black-box siloes. Transparency is critical to getting the holistic perspective.
Keep it simple and practical
Like focus on value, this principle is heavily focused on the prevention of waste. Waste correlates with complexity. Higher complexity means there are more opportunities for waste to creep into a system.
Focus on delivering the desired outcome, not building the most elegant and elaborate solution. Use the minimum number of steps to deliver that outcome, ensuring you are not over-processing (delivering quality above and beyond what is required).
Apply the Pareto Principle (the 80:20 rule) to service mainstream demand without trying to solve for every possible exception. A simple process will be able to handle 80% of variation. Adding decisions and actions to support non-mainstream demands (the outliers) will only complicate the process and slow it down for the 80%. It’s better to apply general exception handling e.g. mainstream demand is handled by a simple, standardized process (possibly automated)—and the less frequent outliers are handled on a case-by-case basis.
Optimize and automate
Optimize and automate is about using people (often the most scarce resource) and automation effectively. The number of people you have is often the primary constraint on progress, so technology should be used to its full potential to ensure your people can avoid wasting time on simple, repetitive tasks and focus on the complex decisions and problem-solving tasks which require human intervention.
While a person is working on a task that ought to be automated, they’re not working on a task which cannot (yet) be automated, so this is a form of waste. Automate the automatable to ensure people are used more wisely. This means automating standard processes and decision-making which can be modelled algorithmically.
However, you should be careful what you automate—and when. It might be more accurate to call this principle “Optimize then automate”, as automating a faulty process simply gets you to the wrong outcome faster.
Nothing is ever perfect first time. Ever. Although the waterfall model tries to do this, it rarely works out, because it starts with trying to capture the customer’s requirements perfectly (an impossible task) and degenerates from there. The optimization principle ties in with the progress iteratively with feedback principle. Using specific optimization practices documented in ITIL—or borrowed from DevOps, Lean, and other areas—iterative improvements can be applied and validated through holistic metrics such as customer satisfaction. When working to optimize and automate, the think and work holistically, and collaborate and promote visibility principles also come into play, so that optimization is done from the value chain perspective and all the necessary stakeholders are involved.
The 7 guiding principles of ITIL 4 are the core, high-level messages of ITIL. They represent tried-and-tested ways of thinking and working; proven in the areas from which they originated (such as Lean Manufacturing)—and proven in their application to service management. When an organization absorbs and embodies these principles, it can avoid many of the pains and obstacles which commonly plague IT departments and service organizations today.
Read next: What are the 4 dimensions of ITIL 4