What the ITIL 4 Guiding Principles Look Like in the Real World

Erika Flora
Written by Erika Flora

At first glance, ITIL 4’s guiding principles may seem a little pie in the sky, rainbows and unicorns, not-so-practical advice. However, when translated into tangible behavior, they can help frame the right mindset when implementing ITIL concepts. This article will discuss what ITIL’s guiding principles look like as behaviors, complete with examples (both good and bad) of the principles being put to work.

A Brief Overview of the ITIL 4 Guiding Principles

In 2016, AXELOS, the organization that owns the intellectual property for ITIL, published a book called ITIL Practitioner that attempted to answer the question, “How do you actually go about implementing ITIL?” Ever since the ITIL books were first published back in the 1980s, there was a lot of content on the what and why of IT Service Management, but fewer details around how to implement these concepts and where to start.

This original set of principles was updated with the release of ITIL 4 – and from there they were off and running. They’ve been refreshed and refined – newly pulling from common improvement frameworks like Lean, Agile, and DevOps, along with input from those of us who help clients implement ITIL in their organizations – and now consist of the following:

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

 

These are excellent principles to live by, but sans context, they tend to be little more than nice sayings to hang on the wall and promptly ignore. Let’s talk about what these principles look like when done well.

 

Turning the ITIL 4 Guiding Principles into Action

When starting down the path of implementing ITIL concepts, it’s critical to talk with teams about what each of these principles look like in everyday decision making. When coaching and training our clients on ITIL, we step them through an exercise where their teams turn each of these lofty principles into specific, new behaviors they will then hold one another accountable to. We also have teams compare ITIL’s guiding principles to the organization’s overall values, principles, and beliefs.

Focus on Value

What this looks like: Teams define technology products and services by using words that makes sense to their customers. Working with IT is easy and straightforward – there’s one phone number to call, for example, and the service desk is well trained and can solve issues quickly. Teams take the time each week to meet with customers face-to-face (through focus groups, one-on-one conversations, etc.) and make sure they understand their customer’s perspective – how they use technology, what they value, the challenges they’re facing, etc.

Story time: A client of ours – a fast-food chain – does a great job living this principle. Each year, every employee spends one week working in one of their stores. They use the cash register, prepare and serve food, the full gamut. As a result, every employee has a crystal-clear understanding of how their role fits into the larger organization and how what they do directly benefits their customers. Lots of new and improved products and services have been rolled out as a result.

Start Where You Are

What this looks like: Teams always ask others before creating new templates or kicking off new projects. The organization seeks out “pockets of excellence” and works to re-create these behaviors and resulting successes elsewhere. The organization doesn’t try to improve everything at once, but rather finds ways to make small, consistent improvements that, over the long run, add up to large improvements.

Progress Iteratively with Feedback

What this looks like: Large projects are broken down into smaller projects (incorporating Agile and/or Scrum concepts, too). Teams regularly gather feedback, both internally as well as from customers, and a culture of failure and improvement is pervasive. The organization is data-driven. Prototyping is regularly done.

Collaborate and Promote Visibility

What this looks like: Teams take the time to share information across departments. Knowledge is regularly created (wikis, videos, etc.), freely shared, and kept-up-to-date, so that others can benefit from it. Informal cross-training and mentoring regularly happens throughout the organization.

Think and Work Holistically

What this looks like: Leaders and teams find creative ways to regularly bring together people that wouldn’t normally work together (building Centers of Excellence, creating cross-functional teams, literally breaking down walls and moving desks so teams can work more closely together, etc.).

Keep it Simple and Practical

What this looks like: Teams respect people and their time by having fewer and focused meetings. Process are simple, streamlined, and regularly improved. Communication is uncomplicated, clear, and easy to understand. Teams take on less new projects, are able to focus on them, and get them done more quickly.

Optimize and Automate

What this looks like: Teams regularly meet to discuss repetitive, mundane tasks that are taking a lot of time and see whether they can automate these “lower value” tasks through technology. Teams take the time to discuss and simplify how work is done before “throwing a tool at the problem”.

What NOT to do When Implementing ITIL

And now, because it’s fun, here’s a nowhere-near-comprehensive list of ITIL Misguided Principles. Don’t let your teams fall into these traps.

Don’t Let the Customer Bother You

What this looks like: Teams hide behind their computers rather than go out and talk with their customers. People buy technology because it’s new and cool, not because anyone asked for it or needs it. Teams often don’t know who their customers are or how their work fits into the larger picture, nor do they really care. “I show up, I do my work, and I go home”.

Throw Everything Out

What this looks like: People re-create the wheel every time they do something, ending up with lots of projects and documents that solve the exact same problem. Lots of repetitive work abounds throughout the organization.

Create the Largest Project Possible

What this looks like: Teams take forever to start something, preferring to talk about the same issues at every meeting and never actually do anything about it. Leaders expect perfection, so mistakes are covered up and projects never seem to end. The organization says “yes” to every idea and request, is constantly starting new work, everyone’s really busy and getting pulled in several directions at once, but nothing ever seems to get finished.

Be Secretive in All Things

What this looks like: People don’t share information because they cherish job security and like looking smarter than everyone else. Teams have an “us versus them” attitude and don’t like helping one another. People don’t freely share knowledge or take the time to mentor, cross-train, or document procedures.

Focus Solely on Your Own Stuff

What this looks like: Teams work in silos, to the detriment of other teams and departments. You hear people say, “that’s not my job” a lot. Teams actively work against one another, either outright or in secret. Teams are resistant to change and sabotage it whenever possible.

Make it Complicated and Confusing

What this looks like: People live by the saying, “If you can’t convince them, confuse them”. Initiatives are over-architected, complicated, and need a PhD to understand, much less follow.

Story time: The worst ITIL implementation I ever saw was an organization that kicked off a massive project to implement twenty-six ITIL processes all at once. Six months into the project, people lost sight of what was expected of them or whether they were making any progress. Fatigue sat in, they lost interest, and everyone went back to the way things were before they ever started the project.

The More Manual Work, the Better

What this looks like: People constantly work on mundane, repetitive tasks that technology could do instead. Work takes forever to complete because someone always has to “check it themselves”. Data is also often prone to error.

Originally published June 06 2019, updated August 08 2019
ITIL/ITSM