Key Concepts of IT Service Management practice questions

Incident management

Why wrong: Incident management focuses on minimizing the negative impact of incidents by restoring normal service operation as quickly as possible. Its primary objective is reactive, addressing unplanned interruptions or reductions in service quality. While crucial for service restoration, it does not proactively control or prevent unauthorized changes that could cause such outages in the first place, making it unsuitable for the stated problem of preventing outages due to unauthorized changes.

Problem management

Why wrong: Problem management aims to reduce the likelihood and impact of incidents by identifying and resolving the root causes of actual and potential incidents. While it might identify that unauthorized changes are a root cause of frequent outages, its role is to analyze and recommend solutions, not to directly govern or control the implementation of changes themselves. It provides insights that inform change enablement, but does not execute the change control function.

Service desk

Why wrong: The service desk serves as the single point of contact between the service provider and its users, primarily handling incident resolution, service requests, and communication. Its focus is on user support and facilitating service access, not on the governance or control of infrastructure and service changes. While a service desk might log change requests, it does not possess the authority or processes to assess, authorize, or prevent unauthorized changes from being implemented.

Keep it simple and practical

Why wrong: The 'Keep it simple and practical' principle advocates for minimizing complexity in processes, services, and activities to achieve desired outcomes with the least amount of effort. While beneficial for efficiency and maintainability, its primary focus is on avoiding unnecessary steps or solutions within the service management system itself. It does not, however, directly ensure that the service's core offering inherently delivers value to the customer, though it can make value delivery more efficient.

Progress iteratively with feedback

Why wrong: This principle emphasizes breaking down work into smaller, manageable iterations and continuously seeking and incorporating feedback throughout the service lifecycle. Its main objective is to enable adaptation, learning, and improvement, reducing the risk of large-scale failures by making adjustments early and often. While crucial for refining a service and ensuring it remains relevant, it primarily addresses the methodology of development and improvement, rather than the initial definition or guarantee of customer value during the design phase.

Collaborate and promote visibility

Why wrong: The 'Collaborate and promote visibility' principle stresses the importance of working together across organizational boundaries and making information transparent to all relevant stakeholders. This fosters shared understanding, improves decision-making, and builds trust among teams involved in service delivery. However, its core function is about how people interact and share information, rather than being the foundational principle that defines or directly ensures the inherent value proposition of a newly designed service for its end-users.

Customer satisfaction score

Why wrong: While customer satisfaction is a crucial outcome for any service organization, it serves as a lagging indicator influenced by numerous factors beyond just the speed of service restoration, such as communication quality, professionalism, and perceived value. It does not directly provide actionable insights into the operational efficiency or speed of the restoration process itself. Therefore, it's not the most direct metric for pinpointing areas to improve the technical performance of service restoration.

Number of tickets closed per agent

Why wrong: The number of tickets closed per agent is primarily a productivity metric, reflecting an individual's workload capacity and output volume. While it indicates how busy an agent is, it does not inherently measure the quality, complexity, or, crucially, the speed and effectiveness of service restoration for critical incidents. Focusing solely on this metric could incentivize closing simple tickets quickly, potentially overlooking the timely resolution of more impactful service outages.

First Call Resolution (FCR) rate

Why wrong: First Call Resolution (FCR) rate measures the percentage of incidents or service requests resolved during the initial contact with the service desk, significantly contributing to customer satisfaction and efficiency. However, FCR specifically focuses on immediate resolution at the first point of contact, not the overall average time taken to restore *all* services, especially those requiring escalation or deeper investigation. Therefore, while valuable, it doesn't directly capture the end-to-end speed of service restoration across the entire incident lifecycle.

Problem management

Why wrong: Problem management aims to reduce the likelihood and impact of incidents by identifying and resolving the root causes of problems. While it leverages CMDB data to understand the relationships between CIs and potential impact areas when investigating problems, the CMDB's fundamental purpose isn't solely to support problem investigation; rather, it provides the foundational data that problem management consumes to achieve its objectives.

Incident management

Why wrong: Incident management focuses on restoring normal service operation as quickly as possible. It utilizes CMDB data to identify affected configuration items (CIs), understand their dependencies, and determine potential impact on services, thereby aiding in diagnosis and resolution. However, the CMDB's core function is to maintain an accurate record of CIs and their relationships, which incident management then consumes for operational purposes, rather than being the practice that defines or is the CMDB.

Change enablement

Why wrong: Change enablement ensures that changes are assessed, authorized, and implemented without causing undue disruption. It heavily relies on CMDB data to perform thorough impact assessments, identifying all affected CIs and services before a change is approved. While critical for change success, the CMDB itself is the repository of configuration information, and change enablement is the practice that acts upon that information to manage transitions, not the practice that defines or is the CMDB.

Business case

Why wrong: A business case is primarily an internal document used to justify the investment in a new service or project by outlining its expected costs, benefits, and risks. While it demonstrates the *provider's* rationale for developing the service, it does not serve as the formal, external-facing documentation of the service's value proposition for the *consumer*. Its purpose is financial and strategic justification, not the detailed description of the service itself.

Service portfolio

Why wrong: The service portfolio encompasses the complete set of services managed by a service provider, including pipeline services (under development), live services (operational), and retired services. It is a high-level management tool for strategic oversight of all service investments, not the detailed formal description of the value proposition for a single new IT service. While a new service offering would eventually be part of the portfolio, the portfolio itself does not contain the specific value proposition details.

Service level agreement (SLA)

Why wrong: A Service Level Agreement (SLA) is a documented agreement between a service provider and a service consumer that specifies the service levels and metrics the provider is committed to delivering. It defines performance targets, responsibilities, and remedies, but it does not formally describe the service's fundamental value proposition or how it will enable value for the consumer. The SLA is established *after* the service and its value have been defined and agreed upon, focusing on ongoing performance rather than initial value articulation.

Incident management

Why wrong: While incident management is critical for restoring normal service operation as quickly as possible following a service interruption, its primary focus is on immediate resolution and minimizing business impact, not on investigating the underlying cause. It addresses the symptoms of service degradation or failure to get services back up, but it does not prevent the recurrence of incidents stemming from the same root cause. Therefore, it would not effectively address a high number of recurring incidents in the long term.

Service request management

Why wrong: Service request management is the practice of fulfilling pre-defined, routine requests from users, such as requests for information, access to services, or standard changes to IT components. It operates within established parameters and does not involve diagnosing complex issues, performing root cause analysis, or investigating the underlying reasons for recurring service failures. Its scope is entirely separate from addressing systemic problems indicated by frequent incidents.

Change enablement

Why wrong: Change enablement is the practice of ensuring that changes are implemented smoothly and successfully, minimizing risk and impact to services. While it is an essential practice for implementing the permanent fixes identified by problem management, its role is not to diagnose why incidents are recurring or to identify the underlying problem itself. It acts as the controlled mechanism for deploying solutions, not for initial problem identification or root cause analysis.

Change enablement

Why wrong: Change enablement is the ITIL practice focused on maximizing successful service and product changes by ensuring risks are properly assessed, authorized, and managed. Its scope involves the introduction or modification of services and components in a controlled manner, not the rapid restoration of a service that has unexpectedly failed or degraded. Therefore, it is not the practice responsible for improving the speed of service restoration after an unplanned disruption.

Problem management

Why wrong: Problem management aims to reduce the likelihood and impact of incidents by identifying and analyzing the root causes of actual and potential incidents. While it seeks to prevent future incidents and improve long-term service stability, its focus is on understanding underlying issues and implementing permanent solutions, not the immediate, rapid restoration of a service that is currently down or degraded. Its activities typically follow incident resolution, rather than performing the initial restoration.

Service level management

Why wrong: Service level management establishes clear, business-based targets for service performance and ensures that the organization meets these agreed-upon service levels. While it defines *what* the restoration speed should be (e.g., within an SLA), it does not *perform* the restoration activities or define the operational processes for achieving that speed. Its role is more about defining, monitoring, and reporting on service performance, including restoration targets, rather than actively managing the restoration process itself.

Incident management

Why wrong: Incident management focuses on restoring normal service operation as quickly as possible following an unplanned interruption or reduction in the quality of a service. A request for a *new* software installation, even if pre-approved, represents a standard, pre-defined user need for a new capability, not a disruption to an existing service. Therefore, it falls outside the scope of incident resolution.

Change enablement

Why wrong: Change enablement, formerly change management, is the practice of ensuring that changes are assessed, authorized, and managed to minimize risk and maximize value. While a new software installation *is* a change to the IT environment, if it's a pre-approved, standard offering, it is typically fulfilled as a service request rather than requiring a separate change authorization process. Standard service requests are often pre-authorized changes.

Problem management

Why wrong: Problem management aims to reduce the likelihood and impact of incidents by identifying and resolving the root causes of actual and potential incidents. A customer requesting a new software installation is a proactive demand for a new service or capability, not an indication of an underlying defect or recurring issue within an existing service. Therefore, it is unrelated to problem identification or resolution.

Supplier management

Why wrong: Supplier management is an ITIL practice focused on ensuring that an organization's suppliers and their performance are managed appropriately to support the seamless provision of quality products and services. While crucial for outsourcing, it describes the *activities* and *controls* applied to suppliers, rather than defining the fundamental, cooperative *relationship* between the service provider (the outsourced company) and the service consumer (the organization). It is a means to manage, not the overarching relationship itself.

Service portfolio

Why wrong: The service portfolio is a comprehensive collection of all services an organization manages across their entire lifecycle, encompassing current, retired, and pipeline services. While it lists the specific IT support services that might be outsourced, it fundamentally represents the *offerings* and their status, not the dynamic, interactive engagement or the cooperative connection that forms between the organization and its external IT support provider. It defines the scope of services, not the nature of the interaction.

Service level agreement (SLA)

Why wrong: A Service Level Agreement (SLA) is a documented agreement between a service provider and a service consumer that specifies the services to be provided, the expected service levels, and the responsibilities of both parties. While an SLA is a critical component *within* a service relationship for defining performance expectations and obligations, it is a specific contractual instrument rather than the overarching conceptual framework that describes the cooperative interaction and value co-creation between the parties.

Change enablement

Why wrong: Change enablement focuses on minimizing the negative impact of changes by ensuring they are properly assessed, authorized, and managed. A simple password reset to resolve an incident, such as a user being locked out, does not constitute a "change" to a service or service component in the ITIL sense. This action is a standard operational procedure to restore service, not an alteration to the configuration or design of the IT system itself. Therefore, it falls outside the scope of change enablement.

Problem management

Why wrong: Problem management aims to reduce the likelihood and impact of incidents by identifying and resolving the root causes of actual or potential incidents. While a recurring issue with password resets might trigger problem management, the act of resolving a single incident by resetting a password is not problem management itself. This practice focuses on restoring normal service operation as quickly as possible, rather than delving into the underlying reasons why the user needed a reset in the first place, which would be the domain of problem management.

Service request management

Why wrong: Service request management supports the agreed quality of a service by handling pre-defined, user-initiated requests for service provision, information, or standard changes. While a user *requesting* a password reset when they simply want to change it is a service request, in this scenario, the reset is performed *because* the user is experiencing an incident (e.g., unable to log in, locked out). The agent is not fulfilling a routine request but rather resolving an unplanned interruption to service, which is the core purpose of incident management.

Cost

Why wrong: Cost, within the ITIL framework, refers to the amount of money spent or resources consumed in delivering a service or product. It represents the financial outlay and resource expenditure required to produce an outcome, rather than the perceived benefits derived from that outcome. While cost is a critical factor in service management and value co-creation, it is distinct from the subjective perception of usefulness or importance that defines value.

Outcome

Why wrong: An Outcome, in ITIL 4, is a result achieved by a stakeholder, enabled by the use of one or more service outputs. While outcomes are the desired results that services aim to facilitate, they are distinct from the perceived benefits or usefulness that constitute value. Value is the subjective appreciation of these outcomes, whereas an outcome is the tangible or intangible effect itself.

Risk

Why wrong: Risk, in ITIL 4, is defined as a possible event that could cause harm or loss, or make the achievement of objectives more difficult. It represents the uncertainty of an outcome, which can be either negative (threat) or positive (opportunity), but fundamentally relates to the possibility of deviation from expected results. Risk management aims to mitigate potential negative impacts and leverage opportunities, but risk itself is not the perceived benefits or usefulness of a service.

Identifying root causes of incidents

Why wrong: Identifying the root causes of incidents is a primary purpose of the Problem Management practice, not the Service Desk. While the Service Desk records incident details, its role is focused on restoring normal service operation as quickly as possible, often through workarounds, rather than conducting in-depth analysis to prevent recurrence. Problem Management systematically investigates underlying causes to eliminate or reduce the likelihood of future incidents.

Managing the lifecycle of all changes

Why wrong: Managing the entire lifecycle of all changes, from submission and approval to implementation and review, is the responsibility of the Change Enablement practice. The Service Desk's involvement is typically limited to receiving change-related inquiries or communicating planned outages to users, not governing the change process itself. Its focus is operational support, not strategic change governance.

Increase speed

Why wrong: Increase speed is not one of the seven ITIL guiding principles. While efficiency and timely delivery are important outcomes of effective service management, 'Increase speed' itself is a performance metric or an objective often pursued within specific practices like high-velocity IT, rather than a foundational principle guiding all organizational activities. The principles focus on how to approach work to achieve value, not merely on the pace of execution.

Manage risk

Why wrong: Manage risk is not an ITIL guiding principle. While effective risk management is an essential component of sound service management and is implicitly addressed across various ITIL practices and the service value system, it is considered a critical activity or a capability to be developed, not a foundational principle that dictates the overall approach to service co-creation. Principles offer overarching guidance, whereas risk management is a specific discipline.

Reduce cost

Why wrong: Reduce cost is not one of the ITIL guiding principles. While cost optimization is a desirable outcome of efficient service management and is often a key business objective, it is not a guiding principle that dictates the approach to service delivery. ITIL principles prioritize value co-creation and holistic thinking, recognizing that excessive focus on cost reduction without considering value or quality can be detrimental to long-term organizational success.

Finance and accounting

Why wrong: While financial management is undeniably critical for any organization, ITIL 4 does not designate "Finance and accounting" as a standalone dimension of service management. Instead, financial considerations, including budgeting, cost management, and investment decisions, are integral aspects embedded within the "Organizations and people" dimension. They relate to organizational structures, governance, and resource allocation necessary for effective value creation and service delivery.

Security and compliance

Why wrong: "Security and compliance" is not recognized as a distinct, separate dimension within the ITIL 4 framework for service management. Instead, security management, encompassing information security, cybersecurity, and adherence to relevant regulatory and legal compliance standards, is primarily addressed as a crucial aspect within the "Information and technology" dimension. It ensures the protection of information assets and the integrity of technological components supporting services.

Close the incident and archive it

Why wrong: Closing an incident and archiving it immediately after applying a workaround is an incomplete and shortsighted approach. While the immediate service disruption might be mitigated, this action neglects the critical step of investigating the underlying cause of the incident. Such premature closure prevents proactive problem management from identifying and eliminating the root defect, increasing the likelihood of the incident recurring and negatively impacting service stability and customer satisfaction in the future.

Reassign the incident to change management

Why wrong: Reassigning a resolved incident directly to Change Management is inappropriate at this stage. Change Management is responsible for controlling the lifecycle of all changes, ensuring beneficial changes are made with minimal disruption. While a permanent solution to the underlying problem might eventually require a change, the immediate priority after a workaround is to understand why the incident occurred. Problem Management is the correct practice to investigate the root cause before any potential changes are designed or implemented.

Update the resolution code to 'Permanent Solution'

Why wrong: Updating the resolution code to 'Permanent Solution' when only a workaround has been applied is inaccurate and misleading. A workaround is a temporary measure that restores service functionality but does not eliminate the root cause of the incident. Falsely classifying a temporary fix as a permanent solution creates a deceptive impression of service stability and bypasses the crucial process of root cause analysis, which is essential for long-term service improvement and preventing future incidents.

Penalize the service provider financially

Why wrong: While financial penalties, often termed service credits, can be stipulated in a contract for failing to meet Service Level Agreement (SLA) targets, they are a consequence rather than a proactive ITIL-aligned action. The immediate focus should be on understanding the underlying performance issues and implementing constructive improvements to restore service levels. Solely penalizing the provider does not resolve the service deficiency or prevent future occurrences, which is contrary to ITIL's emphasis on continual improvement and value co-creation.

Ignore the gap as it is within acceptable tolerance

Why wrong: Ignoring a gap in service performance, even if numerically small (e.g., 0.4% below target), contradicts the fundamental ITIL principle of 'progress iteratively with feedback' and the Continual Improvement practice. Any deviation from agreed-upon Service Level Agreement (SLA) targets signifies a potential impact on value delivery and warrants investigation. Dismissing such a shortfall as 'acceptable tolerance' risks customer dissatisfaction and allows underlying issues to persist, potentially escalating into more significant problems.

Renegotiate the SLA to lower the target

Why wrong: Renegotiating a Service Level Agreement (SLA) to lower a target should be considered a last resort, typically only after thorough investigation reveals that the current target is genuinely unachievable with reasonable effort or if business requirements have fundamentally shifted. The initial and preferred ITIL approach is to identify the root causes of underperformance and implement improvements to meet the established target. Prematurely lowering the target avoids addressing the core problem and may reduce the value delivered to the customer.

Roll back the change

Why wrong: Rolling back a change is an action typically reserved for situations where an implemented change has failed or introduced unforeseen negative consequences, necessitating a return to the previous stable state. Since the question implies the change request is still in an early stage (awaiting approval, not yet implemented), initiating a rollback at this point is entirely premature and illogical. A rollback plan is usually developed *before* implementation as a contingency, but the execution of the rollback itself only occurs post-implementation if the change proves unsuccessful or harmful.

Implement the change immediately

Why wrong: Implementing a change immediately, without prior assessment and formal approval from the change authority, bypasses critical governance and risk management controls. This approach significantly increases the likelihood of service disruption, security vulnerabilities, or non-compliance, as the change's potential impact has not been adequately evaluated. Proper change management dictates that implementation activities, such as building, testing, and deploying, only proceed once the change has received explicit authorization, confirming its viability and alignment with organizational policies.

Close the change record

Why wrong: Closing a change record signifies the completion of the entire change lifecycle, meaning the change has been successfully implemented, verified, and post-implementation reviews have been conducted. Since the change request is still in an early stage, awaiting approval and certainly not yet implemented, closing the record at this point would be highly premature and indicate a failure to follow the established change management process. The record remains open to track progress through approval, implementation, and review stages.

Hire additional service desk agents to handle the increased incident volume

Why wrong: Hiring additional service desk agents is a reactive, capacity-based solution that addresses the symptom of increased incident volume rather than its underlying cause. While it might temporarily improve response times, it fails to identify and resolve the root technical issues causing authentication failures and slow load times, leading to unsustainable operational costs and continued service instability without improving the core service quality.

Conduct a training session for all IT staff on incident management best practices

Why wrong: Conducting a training session for IT staff on incident management best practices primarily focuses on improving the efficiency and effectiveness of the *process* for handling incidents. While valuable for operational excellence, it does not address the fundamental technical issues or system vulnerabilities that are causing the authentication failures and slow load times, meaning the incidents themselves would continue to occur.

Upgrade the service desk tool to automate incident resolution

Why wrong: Upgrading the service desk tool to automate incident resolution, without prior root cause analysis, risks automating workarounds or symptomatic responses rather than true fixes. If the underlying problems are not understood through problem management, automation efforts could perpetuate inefficient processes, potentially escalating issues by rapidly applying temporary solutions without addressing the core system deficiencies causing the incidents.

Require all changes to go through a change advisory board (CAB) meeting

Why wrong: Requiring all changes, regardless of their urgency or risk profile, to undergo a Change Advisory Board (CAB) meeting introduces significant delays and bureaucratic overhead. This approach is particularly detrimental for emergency changes, which demand immediate action to restore critical services, as waiting for a scheduled CAB meeting would prolong outages and increase business impact. ITIL 4 advocates for a more agile approach, leveraging different change types and appropriate Change Authorities to streamline approvals where appropriate, rather than creating a universal bottleneck that hinders service restoration and agility.

Document the incident but take no further action to avoid bureaucracy

Why wrong: Merely documenting an incident without taking further action to address its underlying cause is a critical failure in IT service management. This inaction ensures that the root problem remains unresolved, significantly increasing the likelihood of recurrence and potential future service disruptions. ITIL principles emphasize learning from incidents through problem management to identify and eliminate root causes, thereby preventing their reoccurrence, improving service stability, and delivering continuous value. Passive documentation without subsequent action is an unacceptable strategy that perpetuates service instability.

Restrict change implementation to only the senior administrator

Why wrong: Restricting all change implementation to a single senior administrator creates a severe single point of failure, introducing significant operational risks. This approach severely limits the organization's agility and capacity to implement multiple changes concurrently, leading to bottlenecks and delays in service improvement and restoration. Furthermore, it creates an over-reliance on one individual, making the system vulnerable to their absence, burnout, or errors, thereby undermining service resilience, efficiency, and the ability to scale operations effectively.

Service level agreements

Why wrong: SLAs are not a component of the SVS; they are outputs of service level management.

Service desk

Why wrong: The Service Value System (SVS) consists of the guiding principles, governance, service value chain, practices, and continual improvement — not operational support functions. A service desk is a specific practice within the SVS’s "practices" component, not a separate SVS component. It tempts because service desks are central to ITIL service operation, but the SVS is a higher-level framework for value co-creation, not a list of support tools.

Configuration management database

Why wrong: A configuration management database (CMDB) is a tool used to store and manage information about configuration items (CIs) and their relationships, but it is not a component of the ITIL Service Value System (SVS). The SVS components are specifically the guiding principles, governance, service value chain, practices, and continual improvement. A CMDB is tempting because it supports the *practices* component (specifically service configuration management), but it is an operational database, not a structural element of the SVS itself.