The ITIL Guiding Principles

Rules and procedures cover the situations someone foresaw. Most of daily IT work falls outside them: an unusual request, a new tool, a team that disagrees about priorities. ITIL's seven guiding principles give direction in exactly those moments. They are part of the ITIL Value System and are the same in ITIL 4 and ITIL (Version 5). Each section below explains one principle, shows it at Kestrel Energy and names the mistake people most often make with it; the last section shows how they work together.

Focus on value

Focus on value means that everything the organization does should link, directly or indirectly, to value for its stakeholders. To apply it you have to know who the consumer is in a given situation, what they actually need, and how they experience the service — including the parts that are not in any agreement.

At Kestrel: the service desk wanted a new rule that every call must be logged with fifteen categories. Mei, the desk team lead, asked who would use those categories and for what. Nobody could answer, so the desk kept five categories that problem management actually used, and spent the saved time on callers.

Common mistake: deciding what is valuable from inside IT. A faster server is only valuable if someone notices the difference in their work.

Start where you are

Start where you are means looking at what already exists before building something new. Current services, processes, tools and people often contain much that works and can be reused. Observe the current situation directly instead of relying only on reports, which can be outdated or tell a nicer story than reality.

At Kestrel: when the old ticketing tool was replaced, Tomasz first spent a week at the service desk. He found that the desk's knowledge articles and its category list were good and well used, so both moved to the new tool. What needed replacing was the tool's slow search, not the way the desk worked.

Common mistake: "rip and replace" — throwing everything away because part of it is bad, and losing knowledge and goodwill in the process.

Progress iteratively with feedback

Progress iteratively with feedback means dividing work into smaller pieces that can be finished, used and evaluated, and collecting feedback before, during and after each piece. Even a large initiative becomes a series of steps, each of which delivers something and teaches you something. Feedback lets you change course while that is still cheap.

At Kestrel: the self-service password reset was first offered to one department of 120 people. Their feedback showed that the verification text message was often delayed; that was fixed before the other 1,900 employees used it.

Common mistake: iterations without feedback. Delivering in small pieces only helps if you actually look at how each piece is received and adjust.

Collaborate and promote visibility

Collaborate and promote visibility means working together across team boundaries and involving the right people at the right time, and making work and its progress visible. When people can see what is happening, why, and what is blocked, they make better decisions and trust each other more.

At Kestrel: the NOC and the app team started sharing one board of open incidents and planned changes. The service desk can now see that a slow portal coincides with a planned database maintenance and tell callers immediately, instead of logging forty separate tickets.

Common mistake: confusing visibility with volume. Dumping every metric on a dashboard hides what matters; show the information people need to decide.

Think and work holistically

Think and work holistically means recognizing that no service, team or component stands on its own. Results depend on how all parts work together: people, information and technology, partners and the way work flows. A change in one place affects others. The four dimensions are a useful checklist for this.

At Kestrel: a firewall rule clean-up in the NOC looked purely technical. Because Tomasz checked which services depended on the rules, he found the nightly payment file to the bank among them and kept that rule in place.

Common mistake: optimizing one team or tool in isolation, which often moves the bottleneck somewhere else instead of removing it.

Keep it simple and practical

Keep it simple and practical means using the fewest steps needed to reach the goal, and removing anything that adds no value. Each step, field and approval should earn its place. Simple solutions are easier to understand, follow and change.

At Kestrel: the change request form had 42 fields, many copied from an old template. A review by Yara Haddad, the release manager, showed that approvers looked at nine of them. The new form asks for those nine and lets the tool fill in the rest from the configuration data.

Common mistake: designing for every exception. A process that handles every rare case on paper becomes so heavy that people work around it in the normal case.

Optimize and automate

Optimize and automate means first making work as effective and lean as it can sensibly be, and then using technology to take over repetitive steps, so that people can spend their time where human judgment adds most. The order matters: automating a poor process only produces poor results faster, at scale.

At Kestrel: account unlocks used to need a ticket, a phone call and a manual check. Amara first removed the duplicate check, then automated the rest through the self-service portal. Unlocks now take a minute, and the desk handles the cases that need a person.

Study material for ITIL (Version 5) describes this principle as also covering AI: when AI takes over work, effective governance must be in place — clear limits, human oversight where needed and someone accountable for the results. See AI in Service Management.

Common mistake: automating first and asking later, or automating so much that nobody understands the process anymore when the automation fails.

Using them together

Each of the seven is a guiding principle: a recommendation that helps an organization make good decisions in any circumstance, regardless of its size, goals, methods or structure. Unlike a procedure, a principle does not tell you what to do; it tells you what to consider.

The principles reinforce each other. When Kestrel replaced its ticketing tool, the team started where they were by observing the desk, then progressed iteratively by moving one team at a time, collaborated with desk agents in weekly demos, and kept it simple by moving only the categories that were used. They can also pull against each other: "keep it simple" may suggest one form for every request, while "focus on value" shows that field engineers need a different one. The principles do not settle such tensions automatically; they make sure the right questions are asked.

Not every principle is equally important in every decision. Use judgment about which ones matter most in the situation at hand, but check that none is completely ignored.