A team designing a new access request workflow tries to build a path for every rare exception into the main flow. The result is a form of 40 conditional questions that nearly every user must work through in order to make a routine request. What does 'keep it simple and practical' advise here?
ITIL 4 Foundation, objective 2. The ITIL guiding principles hard
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Not correct Retain every question already in use, because each one encodes knowledge that would otherwise be lost
That is a misreading of 'start where you are', which asks what existing material is worth reusing, not that everything currently in place must be preserved.
Not correct Automate all 40 questions so that users spend less time working through them
That is 'optimize and automate' applied in the wrong order. Automating a needlessly complex flow preserves the complexity and makes it faster; the question here is whether the steps should exist at all.
Not correct Keep the exceptions in the main flow and gather user feedback after each release so the wording can be refined
That is 'progress iteratively with feedback'. It is a reasonable way to improve a design over time, but it leaves the steps that add no value for most users in place.
Correct Design the flow for the majority of cases and handle the exceptions separately, adding complexity only where it produces a worthwhile outcome
Correct. The principle says to use the minimum number of steps needed to accomplish the objective, and to eliminate anything that fails to produce a useful outcome. Rare cases are handled as exceptions rather than designed into everyone's path.
Why
The distractors here are all real guiding principles applied to the wrong problem, which is the usual way this goes wrong in practice. Keep it simple and practical owns the judgement about whether a step should exist; optimize and automate speaks to how well the steps that survive are executed. Doing them in the wrong order is how organizations end up with fast waste.
Where this comes from
- Cited
- ITIL 4 syllabus clause 2
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 2 and space the ones you get wrong.
More questions on this objective
- A team has been asked to replace an ageing service desk tool. Before designing anything, the team inventories the existing tool's integrations, workflows and data, and finds that several components work well and can be carried forward. Which guiding principle is the team applying? machine-checked
- An organization decides to introduce robotic process automation for its user access request handling. Its ITIL adviser insists that the approval steps are first reviewed and the redundant ones removed. What is the reasoning behind this advice? machine-checked
- A programme has been running for eleven months with no deliverable released, because the team intends to hand over the complete solution in one go. Which guiding principle is being ignored? machine-checked
- A manager plans a service improvement using only the monthly summary reports produced by the supplier, and does not observe how the service actually runs. Which guiding principle most directly cautions against this? machine-checked
- During an improvement review, a team finds that a weekly reconciliation report is produced, circulated and archived, but no one uses it for any decision. Which guiding principle states directly that an activity like this should be eliminated? machine-checked
- A change to a payment service is planned by the application team alone. When deployed, it breaks a downstream reporting service and leaves the support team without updated documentation. Which guiding principle would most likely have prevented this? machine-checked