ITIL 4 Problem Mgmt common mistakes
ITIL 4 Problem Mgmt · Understand the traps and how to avoid them.
Treating every incident as a problem and stating that problem management must open a problem record for each major incident, rather than applying the criteria for when problem management is engaged.
Candidates conflate the incident and problem lifecycles because both use similar language (identification, logging, investigation), and study material on 'major incident' escalation is often memorised more strongly than the trigger criteria for problem management.
What to do instead
Learn the distinction explicitly: problem management is triggered where the cause is unknown or where recurring incidents suggest an underlying error, and not every incident needs a problem record. Practise classifying scenarios (single transient failure with a known workaround vs repeated failures across multiple users) and justify the decision against the trigger criteria rather than the incident severity alone.
Using 'problem', 'known error' and 'workaround' interchangeably, for example describing a known error as a problem that has been closed, or saying a workaround is the permanent resolution.
The three terms appear together in almost every problem scenario, and the definitions are short, so candidates skim them and rely on everyday English meaning instead of the formal ITIL relationships.
What to do instead
Build a one-line definition for each and a rule for how they relate: a problem is the cause (or potential cause) of one or more incidents; a known error is a problem that has been analysed and has a documented root cause and/or workaround but is not permanently resolved; a workaround reduces or eliminates the impact of an incident for which a full resolution is not yet available. Then test yourself by rewriting scenarios using all three terms correctly in one sentence.
Describing problem management as purely reactive, or as purely proactive, instead of recognising both reactive (responding to incidents) and proactive (identifying problems before incidents occur through trend analysis and analysis of the environment) aspects.
Many candidates learn problem management from an incident-driven workflow and never revisit the proactive element, or conversely over-correct and claim problem management only works on trends.
What to do instead
Memorise the two modes as a pair and attach an example to each: reactive problem management is triggered by incident analysis and major incident review; proactive problem management identifies weaknesses through trend analysis, monitoring data and continual improvement activity. When a question asks about the scope, state both and name the input that drives each.
Skipping the problem identification and logging activities in a scenario answer, jumping straight from 'incidents are recurring' to 'root cause analysis', and omitting the recording of the problem with its symptoms, affected services and links to incidents.
Candidates focus on the technically interesting investigation phase and treat logging as administrative trivia, so they lose marks on process-sequence questions that test whether the earlier activities were performed.
What to do instead
Learn the problem management workflow as an ordered chain - problem identification, problem control (including problem logging, categorisation and prioritisation), error control (root cause analysis, workaround and known error management), and closure - and in scenario answers state the logging and prioritisation steps explicitly, including what information is captured and how the problem is linked to the originating incidents.
Performing root cause analysis without first defining the problem statement and scope, so the analysis drifts, covers unrelated symptoms, or never terminates.
Candidates associate problem management with techniques like the 'five whys' or Ishikawa diagrams and believe the technique itself is the answer, forgetting that the technique needs a bounded problem statement and a defined success criterion.
What to do instead
In any scenario answer, state the problem statement and scope before naming the technique, and state the exit condition (for example, the cause is identified to the level where a permanent fix can be defined). Practise writing a two-sentence problem statement from a set of incident symptoms, then choose the technique that fits the data available.
Assuming problem management owns the permanent fix and closes the problem once the root cause is found, rather than recognising that implementing the change is handled through change enablement and that problem closure depends on effectiveness review.
The root cause analysis is the most visible part of problem management, so candidates treat finding the cause as the end of the process and forget the interfaces to change enablement, release and knowledge management.
What to do instead
Map the interfaces explicitly: problem management raises a change request (through change enablement) to remove the error, may depend on release management to deploy it, and should not close the problem until the change has been verified as effective and the known error record and knowledge articles have been updated. In scenario answers, name the change request and the post-implementation review as separate steps.
Confusing the problem manager's accountability with the technical investigation work, for example stating that the problem manager personally performs root cause analysis and determines the technical cause.
The role title suggests ownership of the whole activity, and candidates who have worked in small teams where one person does everything generalise that experience to the exam's role model.
What to do instead
Separate the accountabilities: the problem manager owns the practice - its workflow, prioritisation, escalation, reporting, and coordination of investigation - while technical and specialist teams (in-house or suppliers) perform the analysis and propose the fix. Learn the distinction between practice owner, process manager and the technical resolver role, and check each scenario answer for who does what.
Ignoring the role of suppliers and other parties in problem investigation, and writing answers that assume all root cause analysis happens inside the organisation.
Problem scenarios often describe a complex service with multiple components, and candidates default to an internal-only view because supplier and contract language feels like procurement rather than problem management.
What to do instead
Learn that problem management coordinates investigation across the service value chain, including suppliers and partners, and that shared or unclear ownership of a component must be resolved before analysis can conclude. In scenarios involving third-party components, state how the investigation is coordinated, what information is shared, and how the known error is recorded when the fix sits with a supplier.
Prioritising problems purely by incident severity or by the seniority of the person reporting them, instead of using an agreed prioritisation approach based on impact and urgency and the potential benefit of resolving the problem.
Candidates carry over incident prioritisation habits and do not realise that problem prioritisation has its own logic, including the size of the risk and the effort required to investigate.
What to do instead
Learn that problem prioritisation considers impact and urgency together with the severity of the associated incidents and the likely effort and benefit of investigation, and that the approach is agreed and documented. Practise ranking three problems described in a scenario and justifying the order using those factors rather than the loudest stakeholder.
Treating tools and techniques as a memorised list of names - five whys, Ishikawa, Pareto, Kepner-Tregoe - without being able to say which technique fits a given situation or what its output is.
Technique names are easy to recall and appear frequently in revision material, so candidates learn the labels but not the selection logic, and scenario questions that ask for an appropriate technique expose the gap.
What to do instead
For each technique, learn three things: the type of problem it suits (for example, causal chains for a single clear failure, cause-and-effect diagrams for a problem with many possible contributing factors, Pareto analysis for prioritising among many causes), what it produces as an output, and its limitation. Also learn how problem management records and shares its outputs through the knowledge management practice so that known errors and workarounds are usable at the service desk.