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.
Focus on value
Start where you are
Progress iteratively with feedback
Collaborate and promote visibility
Think and work holistically
Keep it simple and practical
Optimize and automate
[ 1 ] 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.
[ 2 ] 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 backward 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 to old behaviors. People's change is always the trickiest aspect of moving forward.
[ 3 ] 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.
[ 4 ] 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 data center 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.
They 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 the customer, requires better collaboration and clear visibility. As a result, collaborative organizations are typically more agile and resilient.
continue reading ... Part-2