ITIL 4 Foundation common mistakes
ITIL 4 Foundation · Understand the traps and how to avoid them.
Recites the six service value chain activities as if they were the whole service value system, or mixes guiding principles into the value chain list.
The SVS components and the value chain activities are taught close together and both appear as short lists, so they blur into one memorised set.
What to do instead
Draw a one-page map: the SVS contains guiding principles, governance, the service value chain, practices, and continual improvement; the value chain itself has only plan, improve, engage, design and transition, obtain/build, and deliver and support.
Uses 'output' and 'outcome' as synonyms when answering scenario questions, e.g. calling a deployed application the outcome.
Everyday language treats results and deliverables interchangeably, while ITIL distinguishes what is produced from the result stakeholders experience.
What to do instead
For each scenario, label the deliverable as the output (a product, service component, or document) and the changed business or customer result as the outcome; value is then the perceived benefit, risk reduction, and cost optimisation.
Names only 'people, process, and technology' for the four dimensions, or treats the dimensions as sequential project phases.
Older process-model thinking and common IT shorthand omit partners/suppliers and value streams/processes, and dimensions sound like stages.
What to do instead
Memorise the exact four: organisations and people; information and technology; partners and suppliers; value streams and processes. Apply all four to every service, practice, and value chain activity at the same time, not in sequence.
Treats the guiding principles as mandatory ordered steps or as a compliance checklist that must be completed one after another.
Principles are presented as a numbered-looking list and candidates confuse guidance with process.
What to do instead
State that the seven principles are recommendations that apply universally and can be used together in any order; in scenario questions, choose the principle that best explains the recommended behaviour rather than looking for a fixed sequence.
Confuses incident management, problem management, and change enablement by labelling any recurring issue a problem incident or any fix as a change without checking definitions.
The practices overlap in real work: incidents are resolved, problems investigate causes, and changes modify services.
What to do instead
Use boundary definitions: an incident is an unplanned interruption or degradation of service; a problem is a cause, or potential cause, of one or more incidents; a change is an addition, modification, or removal that could affect services. Match the scenario to the practice purpose before choosing an answer.
Assumes every change must go through a full change advisory board or that change enablement exists to prevent all changes.
CAB and approval are familiar from older processes, and 'enablement' is misread as control for its own sake.
What to do instead
Remember change enablement maximises successful service and product changes by assessing risk and using appropriate change models and authorities; only some changes need CAB or high-level authorisation, and standard/low-risk changes may follow pre-authorised models.
Treats an SLA as an internal technical target or uses SLA, OLA, and underpinning contract interchangeably.
All three are agreements with targets, and organisations often call every target an SLA.
What to do instead
Separate the parties: SLA is between the service provider and the customer; OLA is internal between teams in the same organisation; UC is with an external supplier. In questions, identify who signed the agreement and whether the target is customer-facing, internal, or supplier-facing.
Calls every metric a KPI or uses KPI and CSF as synonyms without linking them to objectives.
Dashboards label many measures as KPIs, and both terms concern performance.
What to do instead
Define a CSF as something that must go well for an objective to be met, and a KPI as a measurable indicator that shows how well a CSF is being achieved. Check that each proposed KPI traces to a CSF and a service or business objective.
Describes continual improvement as a one-off retrospective or a final phase after incidents, rather than an ongoing activity across the value chain.
Improvement is often experienced as post-incident review or an annual project.
What to do instead
Place continual improvement inside the SVS and across all value chain activities; use the continual improvement practice and iterative models such as Plan-Do-Check-Act, and look for recurring identification, measurement, and implementation of improvements rather than a single end stage.
Memorises practice names without their purpose and confuses the service desk with incident management or with a single physical help desk.
Practice names sound self-explanatory, and the service desk is the visible entry point for incidents.
What to do instead
Learn each practice by its purpose and boundary: the service desk captures demand and is the user's entry point, while incident management restores normal service as quickly as possible; other practices such as problem management and change enablement have separate purposes. In scenarios, choose the practice whose purpose matches the outcome being sought.