Simplicity, iteration and how the principles combine

The seven principles as one set: a trigger line for each so a scenario can be routed quickly, why the exam treats them as interdependent rather than selectable, and how simplicity and iteration behave when a question puts them together.

Lesson 3 of 4 in objective 2. The ITIL guiding principles, part of ITIL 4 Foundation.

What went wrong in the scenario, and the principle that names it. Left column, The missing thing in the scenario; right column, The principle that names it. Nobody looked at the existing system points at Start where you are. Nothing was delivered for months points at Progress iteratively with feedback. Steps that produce nothing, Categories that change nothing and A main path built for rare cases all point at Keep it simple and practical (If removing it loses nothing, remove it). Something downstream broke points at Think and work holistically. Nobody could see the work points at Collaborate and promote visibility. Nobody wanted it points at Focus on value. Technology applied to a mess points at Optimize and automate. The missing thing in the scenario The principle that names it Nobody looked at the existing system Start where you are Nothing was delivered for months Progress iteratively with feedback Steps that produce nothing Categories that change nothing A main path built for rare cases Keep it simple and practical If removing it loses nothing, remove it Something downstream broke Think and work holistically Nobody could see the work Collaborate and promote visibility Nobody wanted it Focus on value Technology applied to a mess Optimize and automate
What went wrong in the scenario, and the principle that names it.

Routing a scenario in one pass

Learning the seven names is worth almost nothing on its own, because the exam never asks for the list. It gives a situation and offers four real principles, of which two or three are broadly relevant and one names the actual failure described. The skill being tested is specificity: find the principle that describes what went wrong, not one that could be said about any project.

Reading the scenario for the missing thing is faster than reading it for the right answer. Nobody looked at the existing system — start where you are. Nothing was delivered for months — progress iteratively with feedback. Steps that produce nothing — keep it simple and practical. Something downstream broke — think and work holistically. Nobody could see the work — collaborate and promote visibility. Nobody wanted it — focus on value. Technology applied to a mess — optimize and automate.

Simplicity, in the two shapes it is tested in

The first shape is too many distinctions that change nothing. An incident categorisation scheme with a hundred and forty categories, where analysts routinely pick the wrong one and the choice does not change how the incident is handled, is complexity that costs accuracy and buys nothing. The fix is to cut the scheme to the categories that actually change what happens next, and the principle that says so is "keep it simple and practical".

The second shape is designing the main path around rare exceptions. Building a route for every unusual case into one flow produces a form nearly every user has to fight through to do something routine. The principle's guidance is to design for the majority and handle exceptions separately, adding complexity only where it produces an outcome worth having. Both shapes share a test: if removing it loses nothing, remove it.

The two shapes over-complexity takes, and the fix each one gets. Too many distinctions — What it looks like: 140 categories, routinely picked wrong; What it costs: Accuracy lost, and nothing changes; The fix: Keep what changes the handling. Built around rare cases — What it looks like: Every exception in the one flow; What it costs: Routine requests fight the form; The fix: Majority first, exceptions apart Too many distinctions Built around rare cases What it looks like 140 categories, routinely picked wrong Every exception in the one flow What it costs Accuracy lost, and nothing changes Routine requests fight the form The fix Keep what changes the handling Majority first, exceptions apart
The two shapes over-complexity takes, and the fix each one gets.

Why they are applied together

The principles interact and reinforce one another, and the exam has a specific wrong answer in mind: the organisation that adopts the two or three principles it likes and ignores the others. That is not how they are meant to be used. An organisation should consider all of them and work out which are relevant to the situation in front of it, which is a different thing from choosing a permanent subset.

They also frequently apply at once, and a well-built question will make one of them the most specific fit rather than the only true one. A team cutting a twelve-month improvement into six reviewed cycles is iterating, but it is also probably starting where it is and keeping things practical; the question asks which principle the described STEP illustrates most directly, and the answer is the one that names that step rather than the one that describes the surrounding good behaviour.

Several principles fit at once, so the answer is the one that names the step. In order: Read the step described (the thing the team actually did), then Expect more than one to fit (the principles frequently apply at once), then Set aside what is merely true (good behaviour around the step, not the step), then Answer with the one that names it (twelve months in six reviewed cycles is iterating). Read the step described the thing the team actually did Expect more than one to fit the principles frequently apply at once Set aside what is merely true good behaviour around the step, not the step Answer with the one that names it twelve months in six reviewed cycles is iterating
Several principles fit at once, so the answer is the one that names the step.

Worth carrying in

Interdependent
The principles reinforce each other. Adopting a subset is the standard wrong answer.
No fixed order
Not a sequence, not one per value chain activity, not limited to improvement work.
Minimum viable steps
The simplicity test: if removing it loses nothing, remove it.
Design for the majority
Main path for the common case; exceptions handled separately.

What the exam does with this

Objective
2. The ITIL guiding principles
Share of the exam
15% (the whole objective)
Questions in this lesson
4
Signed for by a person
0

Partly checked. None of the 4 questions here has been read against the cited source by a person. 4 questions have been checked against their cited clause by an automated pass — which is not the same thing, and is not a signature.

Only questions a person has signed for are used in mock exams here. That is the whole difference between the two kinds of checking above.

How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.

Drill this lesson

A lesson is one sitting: the trainer draws a short run from these questions alone and spaces the ones you get wrong.

Practise Simplicity, iteration and how the principles combine

Questions in this lesson

Practise Simplicity, iteration and how the principles combine

The rest of objective 2