ITIL Foundation Key Practices Examined in Detail Flashcards

24 sample cards from the Key Practices Examined in Detail deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

1. How does ITIL 4 define a known error?

   A problem that has been analysed but has not been resolved, i.e. one for which the cause is understood and (often) a workaround exists.

2. What is a workaround in problem management?

   A solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available; some workarounds become permanent if resolving the problem is not viable.

3. What are the three phases of the problem management practice?

   Problem identification, problem control (analysis and documenting workarounds/known errors), and error control (managing known errors and potential permanent solutions, often via change enablement).

4. What is the key relationship between incidents and problems?

   Incidents are unplanned interruptions or quality reductions experienced by users; problems are the underlying causes of those incidents. Problem management addresses causes, while incident management restores service from the symptoms.

5. Why are incident management and problem management kept as separate practices despite being closely related?

   Because they have different goals: incident management focuses on rapid restoration of service (speed), while problem management focuses on understanding and removing root causes to prevent recurrence (analysis), which require different timeframes and skills.

6. What is the purpose of the service request management practice?

   To support the agreed quality of a service by handling all predefined, user-initiated service requests in an effective and user-friendly manner.

7. How does ITIL 4 define a service request?

   A request from a user or user's authorised representative that initiates a service action which has been agreed as a normal part of service delivery.

8. How do service requests differ from incidents?

   Service requests are predefined, planned parts of normal service delivery (e.g. a password reset, access request, or information), whereas incidents are unplanned interruptions or quality reductions; requests are not failures.

9. What are key guidelines for fulfilling service requests effectively?

   Standardise and automate requests as far as possible, establish workflows and self-service, set expectations for fulfilment times, and identify opportunities for improvement; policies should allow streamlined fulfilment with minimal approvals.

10. What is the purpose of the change enablement practice?

    To maximise the number of successful service and product changes by ensuring that risks are properly assessed, authorising changes to proceed, and managing the change schedule.

11. How does ITIL 4 define a change?

    The addition, modification, or removal of anything that could have a direct or indirect effect on services.

12. What are the three types of change in change enablement?

    Standard changes (low-risk, pre-authorised, well understood, often automated); Normal changes (scheduled, assessed and authorised following a process); and Emergency changes (must be implemented as soon as possible, e.g. to resolve a major incident).

13. What is a standard change and who authorises it?

    A low-risk, pre-authorised change that is well understood and fully documented; it can be implemented without additional authorisation because the authorisation is given once when the procedure is created.

14. What is an emergency change and how is its assessment handled?

    A change that must be implemented as soon as possible (e.g. to fix a major incident or apply a security patch); assessment and authorisation are expedited, sometimes with a separate emergency change authority (ECAB), and documentation may be completed afterwards.

15. What is a change authority in change enablement?

    The person or group that authorises a change; ITIL 4 recommends decentralising change authorisation to the appropriate level to balance speed and control, rather than relying on a single central body.

16. How does change enablement balance speed and risk?

    By matching the level of control to the risk of the change: low-risk standard changes are pre-authorised and automated for speed, while higher-risk normal/emergency changes get more rigorous assessment and authorisation to control risk without unnecessarily slowing the business.

17. Why should change enablement avoid being overly bureaucratic?

    Because excessive control slows the flow of changes and can push people to bypass the process; the practice must balance the need to make beneficial changes quickly against the need to protect customers and users from adverse effects.

18. What is the purpose of the service level management practice?

    To set clear business-based targets for service performance, so that the delivery of a service can be properly assessed, monitored and managed against these targets.

19. How does ITIL 4 define a service level agreement (SLA)?

    A documented agreement between a service provider and a customer that identifies both the services required and the expected level of service.

20. What are the key requirements for an SLA to be effective in ITIL 4?

    It must relate to a defined service, relate to defined outcomes (not just operational metrics), reflect an agreement between provider and customer, and be written simply and easy to understand and use for all parties.

21. What is the 'watermelon SLA' problem in service level management?

    When SLA reports show all green (targets met) on the outside but the customer is unhappy (red) on the inside, because the metrics measured do not reflect the actual customer experience or business outcomes.

22. What sources should service level management use to understand service performance beyond simple metrics?

    Customer engagement (listening and discussing with customers), customer feedback (surveys, key business-related measures), operational metrics, and business metrics, to gain a balanced and realistic view of performance.

23. In SLA metrics, what is the difference between an output/operational metric and an outcome/business metric?

    An operational metric measures a single, technical aspect of delivery (e.g. uptime percentage), whereas an outcome/business metric reflects the actual result the customer cares about (e.g. ability to complete transactions); good SLAs focus on outcomes.

24. Why is ongoing engagement, not just measurement, central to service level management?

    Because targets and metrics alone can hide dissatisfaction; regular listening, business-focused conversation and feedback ensure the service is measured against what the customer actually values and allow continual improvement.

What this deck covers

Key Practices Examined in Detail flashcards FAQ