Practicing the practices I: support and operations

Practices are the fourth component of the value system, and they generate more Foundation questions than any other single topic except definitions. ITIL describes 34 management practices, kept in Version 5, grouped as general management practices and product and service management practices. Foundation does not test all 34. It tests the purpose and key terms of a selection, and a smaller set in more depth. This lesson and the next work through the practices most often tested, with practice questions. Check your syllabus for the exact list for your exam; the ones covered here appear in most Foundation materials.

This lesson covers the support and operations practices: the service desk, incident management, problem management, service request management, change enablement and monitoring and event management. ITIL-140 taught them in depth. Here we focus on purpose statements, key terms and the distinctions examiners like to test.

How practice questions are built

Practice questions come in three main forms. Purpose questions ask 'What is the purpose of the X practice?' and offer four purpose statements, three of which belong to other practices. Recognition questions describe an activity and ask which practice it belongs to. Detail questions, for the practices tested in depth, ask about specific ideas such as how incidents are prioritized, what a known error is or who authorizes a normal change.

For purpose questions, the technique from lesson 3 applies: learn each purpose's signature words. The purposes below are paraphrased study versions; your exam materials give the official wording. Compare the two and learn the official version for any practice you find hard.

Service desk

Purpose: to capture demand for incident resolution and service requests, and to be the entry point and single point of contact for the service provider with all of its users. The signature words are 'capture demand' and 'single point of contact'. ITIL stresses that the service desk's focus has moved from technical skill alone to supporting people and business, with understanding of the wider organization, empathy and effective communication. Service desks may be physical or virtual and use many channels: phone, chat, portals, email, walk-in and messaging.

A typical distractor offers 'to restore normal service as quickly as possible' as the service desk's purpose. That is incident management. The service desk logs and often resolves incidents, but its defining purpose is to capture demand and act as the single point of contact.

Incident management

Purpose: to minimize the negative impact of incidents by restoring normal service operation as quickly as possible. An incident is an unplanned interruption to a service or a reduction in its quality. Key ideas include prioritization based on impact and urgency, agreed target resolution times, and the use of workarounds and knowledge to resolve incidents quickly. Incidents may be handled by the service desk, by support teams, by suppliers, or by swarming, where many people work on an incident together until it is clear who is best placed to resolve it.

Incident management questions often test the difference from problem management. Incident management restores service; problem management finds and manages causes. If a question describes restoring service quickly, choose incident management. If it describes finding why incidents happen or reducing their recurrence, choose problem management. Questions also test that incidents should be logged and managed so that resolution meets agreed targets, and that information about incidents should be stored in records with links to related configuration items, changes, problems and known errors.

Problem management

Purpose: to reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents, and managing workarounds and known errors. ITIL describes three phases: problem identification, problem control and error control. Problem identification finds problems, for example through trend analysis of incidents. Problem control analyses problems and documents workarounds and known errors. Error control manages known errors, including assessing whether a permanent fix should be made, usually through change enablement.

A known error is a problem that has been analyzed but not resolved. A workaround is a solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available. Questions on problem management often hinge on these two definitions and on the three phases. Note that problem management and incident management are closely linked but separate: problem management may continue long after the incidents are resolved.

Service request management

Purpose: to support the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner. A service request is a request from a user or a user's representative that initiates a service action agreed as a normal part of service delivery, such as a password reset, a new laptop, access to an application or information about a service. Service requests are not failures; that is the key difference from incidents.

ITIL advises that service requests should be standardized and automated as far as possible, that policies should say which requests can be fulfilled with limited or no approval, and that users should be told realistic fulfillment times. Some requests need approval as part of their workflow. A frequent question describes a request for a new mobile phone or software access and asks which practice handles it: service request management.

Change enablement

Purpose: to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed and managing the change schedule. In ITIL 4 this practice was introduced under the name change control and later renamed change enablement, a name that Version 5 keeps. A change is the addition, modification or removal of anything that could have a direct or indirect effect on services.

Questions on change enablement test the three change types, the idea of a change authority (the person or group who authorizes a change) and the change schedule (used to plan changes, help communication, avoid conflicts and assign resources). A favorite distractor says that all changes must be approved by a change advisory board. ITIL says the change authority should be appropriate to the type and risk of the change, and that decentralizing authority, for example to peer review in a pipeline, often improves speed without raising risk.

Monitoring and event management

Purpose: to systematically observe services and service components, and record and report selected changes of state identified as events. An event is any change of state that has significance for the management of a service or configuration item. ITIL distinguishes informational events, which need no action; warning events, which allow action before a negative impact; and exception events, which indicate a breach of an established norm and require action. Some events lead to incidents, some to changes, and many simply inform.

Questions might ask which practice is responsible for identifying and prioritizing infrastructure, service or application events, or which type of event indicates that a threshold has been exceeded. Remember the order of severity: informational, then warning, then exception.

Seeing the practices together

Exam scenarios often involve several practices at once, and the question asks for the one that fits a specific action. A failed booking server might trigger an event (monitoring and event management), which raises an incident (incident management), logged and communicated through the service desk; repeated failures lead to a problem (problem management), whose fix requires a change (change enablement). Practice identifying the practice for each action in a chain like this.

# Map actions in a scenario chain to the practice that owns each one
chain = [
    ("Disk usage passes 95 % and an alert is raised", "monitoring and event management"),
    ("User calls to report the portal is down", "service desk"),
    ("Service restored by restarting the server", "incident management"),
    ("Trend shows the same failure every Monday", "problem management"),
    ("Root cause documented with a workaround", "problem management (known error)"),
    ("Fix to the batch job scheduled and authorized", "change enablement"),
    ("User asks for read access to the shipment report", "service request management"),
]
for action, practice in chain:
    print(f"{practice:<34} <- {action}")
from collections import Counter
print(Counter(p.split(' (')[0] for _, p in chain).most_common(2))

monitoring and event management    <- Disk usage passes 95 % and an alert is raised
service desk                       <- User calls to report the portal is down
incident management                <- Service restored by restarting the server
problem management                 <- Trend shows the same failure every Monday
problem management (known error)   <- Root cause documented with a workaround
change enablement                  <- Fix to the batch job scheduled and authorized
service request management         <- User asks for read access to the shipment report
[('problem management', 2), ('monitoring and event management', 1)]

Practice set

Building practice flashcards

For each practice in this lesson, Kofi wrote a flashcard with the practice name on one side and three things on the other: the purpose in signature words, two key terms, and the practice most often confused with it. Six practices produced eighteen facts, small enough to review in five minutes. He found that the confusion line mattered most, because almost every wrong answer he gave in this area chose the neighboring practice.