ITIL 4 IM common mistakes
ITIL 4 IM · Understand the traps and how to avoid them.
Treating 'incident' and 'problem' as interchangeable when answering definitional items, for example labelling a recurring outage as a problem without noting the incident that triggered it.
Everyday IT language uses 'issue', 'incident' and 'problem' loosely, and candidates carry that habit into the exam instead of applying the formal ITIL distinction between an unplanned interruption or reduction in quality of service and the underlying cause of one or more incidents.
What to do instead
Before answering, write the two definitions in your own words and test the scenario against them: if the statement describes something users experience now, it is an incident; if it describes an unidentified cause or a workaround-driven investigation, it is a problem. Practise sorting ten short scenarios into incident, problem, and known error until the sorting is automatic.
Calling every unplanned event an incident, including events detected by monitoring that have not yet affected a service, or conversely refusing to log degraded-but-working services as incidents.
Candidates conflate 'event' with 'incident' because both come from monitoring and alerting, and they forget that a reduction in quality, not only a full outage, qualifies as an incident.
What to do instead
Rehearse the boundary: an event is any change of state that has significance for a service; it becomes an incident only when it causes or could cause an unplanned interruption or quality reduction. Check each scenario for the words 'degraded', 'slower', 'intermittent', or 'not yet affecting users' before deciding.
Assigning the incident manager role to whoever is technically fixing the fault, and describing the role as owning the resolution.
In small teams the same person often does both, so candidates project their workplace onto the exam. They miss that the incident manager coordinates, communicates, and escalates, while technical specialists perform diagnosis and recovery.
What to do instead
Learn the role as a set of accountabilities rather than a job title: coordination, escalation, communication, and progress tracking. In practice questions, ask 'who keeps stakeholders informed and drives the timeline?' for incident management, and 'who performs the restore?' for the technical team.
Skipping major incident handling and treating major incidents as ordinary tickets with a longer timeline.
Candidates without operational exposure underestimate that major incidents require a separate, accelerated path with defined triggers, a nominated owner, and business-level communication, so they answer with generic escalation language.
What to do instead
Memorise the distinguishing features of a major incident: predefined trigger criteria, a single accountable coordinator, priority communication to business stakeholders, and often a temporary team. Practise writing the first three actions you would take within fifteen minutes of a major incident declaration.
Describing the incident value stream as a linear checklist that starts at logging and ends at closure, omitting detection, diagnosis, and the feedback into problem management.
Process diagrams in study material are often simplified, and candidates memorise the labels without understanding the flow of work and information between them, so they cannot answer questions about handoffs or where delay accumulates.
What to do instead
Walk the stream end to end with a concrete example: detection, logging, categorisation, prioritisation, initial diagnosis, escalation, investigation and diagnosis, resolution and recovery, closure, plus the handoff to problem management for recurring incidents. Note at each step who acts and what information passes forward.
Prioritising incidents by impact alone or by urgency alone instead of combining both, and misreading a scenario where impact is high but urgency is low.
Candidates reduce priority to a single dimension because that is how many ticketing tools display it, and they confuse urgency (how quickly the business needs a resolution) with impact (how much the business is affected).
What to do instead
Use the two-axis test on every prioritisation question: state the impact in business terms, state the urgency in time terms, then derive priority from the pair. Practise scenarios where a single user is blocked from a deadline (low impact, high urgency) against a whole site on a degraded workaround (high impact, lower urgency).
Treating categorisation as cosmetic and not linking it to routing, reporting, and the knowledge base.
Candidates see categorisation as a data-entry chore, so they cannot explain why consistent categories matter for trend analysis, automation, and matching incidents to known errors.
What to do instead
Learn categorisation as the input to routing rules, SLA reporting, and known-error matching. When a question asks why categorisation matters, answer in terms of consistent routing, trend detection, and reuse of previous resolutions, not in terms of tidy records.
Confusing workarounds with resolutions, and closing incidents on the basis of a workaround without recording it.
In practice a workaround often restores service, so candidates treat it as the fix. They then fail items that ask what should be recorded when service is restored by a temporary measure.
What to do instead
Define resolution as restoration of service to the user, and a workaround as a temporary way to restore it while the root cause is unresolved. For any scenario where service returns, ask whether the underlying cause is known; if not, the incident closes with a documented workaround and a problem record is raised.
Assuming the tool automatically enforces the practice, for example that a ticketing system's priority field, SLA timer, or auto-close rule delivers correct incident management.
Candidates equate workflow configuration with good practice and forget that data quality, human judgement, and agreed definitions are what make tooling useful. They also overlook that poor categorisation or stale known-error records make automation harmful.
What to do instead
Separate tool capability from practice design: the tool records and routes, but people define categories, priorities, and escalation criteria, and keep the knowledge base current. When a question mentions automation, ask what data it depends on and who maintains that data.
Answering questions about incident management's place in the service value system as if it were an isolated process, ignoring its interfaces with problem management, change enablement, service desk, and continual improvement.
Candidates study incident management in isolation and do not map the inputs and outputs to other practices, so they miss questions about where incident trends feed improvement or where a change causes a spike in incidents.
What to do instead
Draw a one-page map of interfaces: incidents feed problem management and continual improvement; changes and releases generate incidents; the service desk is the main detection and communication channel; knowledge management supplies workarounds. For each interface, note one concrete input and one output.