SMITS common mistakes
SMITS · Understand the traps and how to avoid them.
Treating the service value chain activities (plan, engage, design and transition, obtain/build, deliver and support, improve) as a strict sequential waterfall, so questions asking where a given activity occurs get answered by 'stage order' rather than by the actual flow of value.
Candidates carry over a lifecycle-stage mental model from earlier frameworks and assume each activity happens once, in order. The value chain is a set of interacting activities that can be combined in many sequences, and exam items probe those combinations.
What to do instead
Draw the six activities as a wheel and, for each practice, ask which activities it touches. Practise mapping a scenario (e.g. onboarding a new supplier) to multiple activities simultaneously. Explicitly contrast 'activities' with the four dimensions and with the value streams that connect them.
Confusing the purpose of incident management with problem management under time pressure, choosing 'find root cause' answers for incident questions and 'restore service fast' answers for problem questions.
Both practices deal with the same symptoms and share tooling, and candidates optimise for the word 'cause' appearing in the stem rather than for the stated objective. Incident management restores service; problem management reduces likelihood and impact by managing errors.
What to do instead
Anchor on the objective verb: restore (incident) versus reduce/eliminate (problem). For each practice, memorise its inputs and outputs (incident: restored service, workaround documented; problem: known error, root cause, permanent fix, problem record). Re-sort a mixed set of 20 scenario stems by objective before answering.
Answering change-enablement questions by picking the most heavyweight change type (normal/full CAB) whenever risk is mentioned, instead of selecting the type that matches the actual risk and urgency described.
Candidates equate 'safe' with 'most approvals' and ignore that standard changes are pre-authorised precisely because risk is understood and low, and that emergency changes exist for urgent restoration. The stem's risk language is read as a cue for maximum control.
What to do instead
Build a decision rule: is the change pre-authorised and low risk (standard), does it need assessment and authorisation before deployment (normal), or must it be deployed now with retrospective authorisation (emergency)? Practise classifying 15 short change descriptions and justify each against the change authority model.
Treating the service level agreement as a document to be written once and filed, so questions on SLM are answered with 'negotiate and sign' rather than with the ongoing cycle of agree, monitor, report, review and improve.
SLA is learned as a contract artefact rather than as a management practice. Candidates miss items about service level reviews, breaches, underpinning agreements and the customer-experience dimension of service levels.
What to do instead
Learn SLM as a loop with named outputs at each turn (service level requirements, SLA, OLAs and underpinning contracts, service reports, review actions). Practise distinguishing SLA from OLA from underpinning contract by who the parties are, and rehearse what happens at a service level review when targets are missed.
Reading the four dimensions of service management as four departments or four process groups, and answering questions about them with organisational-structure answers.
The dimensions (organisations and people, information and technology, partners and suppliers, value streams and processes) sound like org units, and candidates map them to teams. Exam items instead test that all four must be considered together for any service.
What to do instead
For each dimension, write one concrete factor it covers and one example of a failure when it is ignored (e.g. supplier dimension ignored: no exit plan). Practise taking a single service and listing a consideration under each of the four dimensions.
Selecting 'eliminate the problem' or 'prevent recurrence' as the answer for every continual improvement question, ignoring the measurement, baseline and feedback steps that the stem is actually asking about.
Improvement is memorised as an outcome rather than as a method. Candidates skip the identify-measure-analyse-improve-control sequence and the role of the continual improvement register and the improvement model's 'what is the vision / where are we now' questions.
What to do instead
Memorise the improvement model's seven questions in order and match each to its output. For scenario items, ask which step the organisation is currently at before choosing. Practise writing a one-line baseline and a one-line target for a stated service issue.
Treating the configuration management system and the asset register as the same thing, and answering CMDB questions with 'list of hardware' answers.
Both hold records about components, so candidates conflate them. Configuration items are the components whose relationships matter for delivering services; assets are items with financial or ownership value. The exam tests the relationship and dependency angle.
What to do instead
Learn the distinction by purpose: configuration data supports impact analysis and incident/problem resolution; asset data supports cost and lifecycle. Practise drawing a small relationship map (service, application, server, network link) and asking which questions each record type can answer.
Answering security and risk items by choosing the strongest control (e.g. full encryption everywhere, deny all access) rather than the control proportionate to the stated risk and business need.
Candidates equate 'secure' with 'most restrictive' and overlook that service management balances confidentiality, integrity and availability against usability and cost, and that risk treatment includes accept, avoid, transfer and mitigate.
What to do instead
For each scenario, identify the asset, the threat, the likelihood and the impact before choosing a treatment. Memorise the four treatment options and practise choosing among them for five short scenarios, justifying why 'mitigate' is not always correct.
Assuming automation and tooling questions want the most automated answer, so items about workflow, orchestration and data quality are answered with 'fully automate it' even when the stem describes a judgement-heavy or poorly defined process.
Candidates read 'efficiency' as 'automate' and miss that automation amplifies a bad process, that data quality and integration constrain what can be automated, and that human authorisation remains for high-risk changes.
What to do instead
Apply a screen before choosing: is the process stable, high-volume, rules-based and low-risk? If not, the answer is usually to standardise or improve first. Learn the tool capability areas (workflow, knowledge, monitoring, automation, reporting) and match each to the practice it primarily supports.
Answering release and deployment questions by choosing 'deploy everything at once' or 'deploy continuously to all users', rather than selecting the release approach and deployment pattern that the stem's risk, scale and rollback needs imply.
Release, deployment and change are conflated, and candidates miss that release moves the tested service into the live environment while deployment moves components, and that phased, big-bang, push and pull patterns each carry different risk.
What to do instead
Memorise the release approaches (big-bang, phased, pull/push) with one risk profile each, and the deployment patterns (canary, blue-green, rolling) with their rollback characteristics. For each scenario, state the rollback plan before choosing the pattern.