If ITIL's models are its skeleton, the seven guiding principles are its personality — and they're the part most worth carrying into rooms where nobody's mentioned ITIL at all. They're not processes to implement; they're habits of judgement for any decision, at any level. Here they are without the committee varnish.
The seven, translated
- 1. Focus on value. Every action should trace to value for someone — the outcome lens from earlier on this trail. The test: if you can't say who benefits from a task and how, why is it happening?
- 2. Start where you are. Resist the seductive rip-it-out-and-start-again instinct. Observe what actually exists (not what the documentation claims exists), keep what works, fix what doesn't. Most "legacy chaos" contains load-bearing wisdom nobody wrote down.
- 3. Progress iteratively with feedback. Big-bang projects fail big. Slice work into small improvements, ship one, learn, adjust, repeat. If this sounds like agile thinking — yes, ITIL 4 deliberately absorbed it. The ring-based rollout beloved of infrastructure teams (pilot ten devices, then a hundred, then everyone) is this principle wearing work clothes.
- 4. Collaborate and promote visibility. Work in the open: visible queues, honest status, no hero-hoarding of knowledge. Hidden work and hidden problems both compound in the dark.
- 5. Think and work holistically. No service is delivered by one team or one tool — remember the four dimensions. Optimising your silo can pessimise the whole (the security setting that "improves" posture and breaks a business process is the classic).
- 6. Keep it simple and practical. If a process step adds no value, remove it. Every form field, approval, and category must earn its existence. This principle is ITIL apologising in advance for every over-engineered implementation you'll meet.
- 7. Optimise and automate. In that order — a subtlety with teeth. First make the process good; then automate it. Automating a broken process buys you a machine that produces mistakes faster than humans could.
Notice the principles argue with each other on purpose. Start where you are tempers focus on value ("burn it all down for value!"). Keep it simple restrains work holistically from becoming analysis paralysis. Real decisions weigh several at once — which is exactly why these are called principles, not rules. Rules execute; principles deliberate.
Why this page outlives the certification
Long after exam trivia fades, the principles keep paying because they're portable: they apply to a helpdesk queue, a cloud migration, a career decision. "Should we replace the ticketing system or fix how we use it?" — principles 2, 3, and 6 practically answer it for you. And when you're the junior person in the room, "what does the current process actually do well before we replace it?" is a principle-shaped question that makes you sound twenty years more experienced than your badge suggests. Frameworks impress interviewers; judgement impresses colleagues. This is the judgement page.