ITIL Service Value System practice questions

Service level agreement

Why it fails: A Service Level Agreement (SLA) is a documented agreement between a service provider and a customer that specifies the services to be provided, the responsibilities of both parties, and the agreed-upon service levels. While essential for defining expectations and managing service delivery, an SLA is an output or artifact resulting from service management practices, rather than a foundational, structural component of the ITIL Service Value System itself. The SVS provides the overarching framework within which such agreements are developed and managed.

Service owner

Why it fails: A Service Owner is a specific role within an organization, accountable for the end-to-end management, performance, and continual improvement of a particular service. While crucial for effective service management and operating within the ITIL framework, a role is not considered one of the five high-level components that constitute the ITIL Service Value System (SVS). The SVS defines the system's structure, whereas roles operate within that structure to achieve service value.

Incident management

Why it fails: Incident management is a practice within the service management domain, not a component of the ITIL Service Value System (SVS), which consists of the guiding principles, governance, service value chain, practices, and continual improvement. It is tempting because incident management is a core operational process in ITIL 4, but the SVS defines the overarching system that coordinates all practices, not the practices themselves.

Keep it simple and practical

Why it fails: This option describes one of the seven ITIL guiding principles, which are universal recommendations that can guide an organization in all circumstances, regardless of changes in its goals, strategies, or management structure. Guiding principles provide a foundational mindset and approach for decision-making and actions across the entire service value system. They are not specific operational activities within the service value chain itself, which are focused on the practical transformation of demand into value.

Service catalogue management

Why it fails: Service catalogue management is an ITIL management practice, specifically categorized under service management practices, focused on providing a single source of consistent information on all services and service offerings. Practices are sets of organizational resources designed for performing work or accomplishing an objective, detailing how specific types of work are done. While this practice is crucial for defining and presenting services, it is a detailed operational capability that supports the service value chain activities, rather than being one of the six high-level activities that directly transform demand into value.

Guiding principles

Why it fails: Guiding principles are fundamental recommendations that can guide an organization in all circumstances, regardless of changes in its goals, strategies, type of work, or management structure. While they are a core component of the ITIL 4 Service Value System (SVS), they function as universal principles that influence all decisions and actions within the service value chain, rather than serving as direct inputs that initiate its activities.

Practices

Why it fails: Practices are sets of organizational resources designed for performing work or accomplishing an objective, such as service desk or incident management. Within the service value chain, practices are utilized to execute specific activities and transform inputs into outputs. They represent the capabilities and methods applied during value creation, but they are not the initial triggers or raw materials that start the service value chain itself.

Governance

Why it fails: Governance refers to the means by which an organization is directed and controlled, ensuring that the organization's activities are aligned with its strategic objectives and policies. It is a critical component of the Service Value System (SVS), providing overarching direction and control across all activities and practices. Governance acts as a framework that guides *how* the service value chain operates, rather than being a direct input that initiates the chain's activities.

Continual improvement

Why it fails: Continual improvement is an ongoing organizational activity and a dedicated practice that ensures services, products, and practices are continuously aligned with stakeholder needs and expectations. It drives the evolution and enhancement of all components within the Service Value System (SVS), including the service value chain. However, continual improvement functions as a mechanism for enhancement and optimization throughout the SVS, rather than an initial input that directly initiates the service value chain's operation.

Governance

Why it fails: In ITIL 4, governance refers to the means by which an organization is directed and controlled, ensuring that the organization's strategy is implemented and objectives are achieved. It establishes policies, assigns responsibilities, and defines decision-making authority. While governance provides the necessary oversight and direction that enables improvement, it does not itself perform the systematic activities of identifying, planning, and implementing improvements; that is the role of a dedicated practice.

The guiding principles

Why it fails: The ITIL guiding principles are universal recommendations that can guide an organization in all circumstances, regardless of changes in its goals, strategies, or type of work. They provide a foundational philosophy and a set of values to influence decisions and actions across the service value system. However, these principles offer general advice and a mindset for improvement, rather than a structured, systematic process or practice for how to execute specific improvement initiatives.

The service value chain activities

Why it fails: The service value chain (SVC) is an operational model in ITIL 4 that outlines the six core activities (Plan, Improve, Engage, Design & Transition, Obtain/Build, Deliver & Support) required to transform demand into value through the creation and management of products and services. While 'Improve' is one of these activities, the SVC itself describes the flow of work for value creation, not a standalone, systematic method for continuous improvement across the entire organization. The 'Improve' activity within the SVC leverages the dedicated continual improvement practice to achieve its objectives.

Output: improved end-user productivity; Outcome: fewer server incidents

Why it fails: This option incorrectly reverses the definitions of output and outcome. "Fewer server incidents" is a direct, measurable result of the monitoring system's operation and the IT team's actions, making it a clear output. Conversely, "improved end-user productivity" represents a broader business benefit or value realized by the organization due to the reduction in incidents, which correctly identifies it as an outcome. The pairing fails because an output is a direct deliverable, while an outcome is the resulting benefit.

Output: increased server availability; Outcome: monitoring software installed

Why it fails: This pairing is incorrect because "monitoring software installed" is a direct deliverable or an activity completed, making it an output, not an outcome. An outcome represents the value or benefit derived from that output, not the output itself. Furthermore, "increased server availability" is also a direct, measurable consequence of the monitoring system's effective operation, classifying it as an output rather than a higher-level business outcome like enhanced user experience or revenue generation. The option misclassifies both elements.

Output: monitoring software installed; Outcome: decreased server incidents

Why it fails: While "monitoring software installed" is correctly identified as an output, representing a tangible deliverable from the IT team's project, "decreased server incidents" is also an output. A decrease in incidents is a direct, measurable result of the monitoring system's successful operation and the IT team's subsequent actions, not a higher-level business outcome. An outcome, in ITIL 4, refers to the value or benefit realized by stakeholders from the consumption of outputs, such as improved business operations or enhanced user satisfaction, which "decreased server incidents" does not directly represent.

Start a problem investigation to find the root cause

Why it fails: Starting a problem investigation to find the root cause is premature for an initial service disruption. Problem management focuses on identifying the underlying causes of incidents to prevent recurrence, which typically begins after an incident has been resolved or when recurring incidents indicate a deeper issue. The immediate priority for a service desk receiving a call about users being unable to access a system is to restore service, not to embark on a lengthy root cause analysis.

Submit a change request to fix the system

Why it fails: Submitting a change request to fix the system is inappropriate for an unplanned service disruption. Change management is designed for planned modifications to services or components, ensuring they are assessed, authorized, and implemented in a controlled manner to minimize risk. A live system failure requires immediate incident response to restore functionality, not the formal, often time-consuming, process of a change request, which would delay service restoration.

Escalate to second-level support immediately

Why it fails: Escalating to second-level support immediately bypasses the critical initial steps of incident management. The service desk's primary role is to be the first point of contact, log the incident, and attempt initial diagnosis and resolution using available knowledge and tools. Escalation is a subsequent step, typically occurring when first-level support cannot resolve the incident within agreed service level targets or requires specialized expertise, not the default first action.

Focus on value

Why it fails: "Focus on value" is a foundational ITIL guiding principle that ensures all activities, including improvement efforts, are aligned with delivering tangible outcomes and perceived benefits to stakeholders. While essential for defining what to improve and why an improvement is necessary, this principle primarily addresses the objective and justification of an activity. It does not specifically describe the methodology or process by which improvements are incrementally developed, tested, and refined over time, which is a distinct aspect of improvement activities.

Collaborate and promote visibility

Why it fails: "Collaborate and promote visibility" emphasizes the importance of fostering a culture of shared understanding, transparency, and cooperation among all relevant stakeholders. While vital for the successful execution of any improvement initiative by ensuring diverse perspectives are considered and efforts are coordinated, this principle primarily defines the social and communication aspects of working. It describes how people should work together during improvement, rather than the fundamental structure or lifecycle of the improvement process itself.

Think and work holistically

Why it fails: "Think and work holistically" encourages organizations to consider all components of a service and its management system as an integrated whole, taking into account all four dimensions of service management. This principle is crucial for ensuring that improvements in one area do not inadvertently create problems elsewhere, promoting a comprehensive perspective. However, it provides a broad contextual framework for understanding interdependencies, rather than detailing the step-by-step approach or iterative nature of how improvements are actually designed, implemented, and refined.

The service value chain

Why it fails: A centralized IT department, even if it fosters organizational silos, does not inherently mean the service value chain is not functioning. The service value chain represents the operational model for value creation, encompassing various activities. While silos significantly impede the efficient flow of information and collaboration across these activities, thereby reducing the value chain's effectiveness and speed, they do not necessarily halt its fundamental operation or existence. The problem is more about how well the value chain performs under such conditions.

Continual improvement

Why it fails: Continual improvement is an ITIL guiding principle and a practice that an organization should embrace, irrespective of its departmental structure. A centralized IT department might still engage in improvement initiatives focused on its internal processes and services. However, while these efforts might enhance specific IT functions, they often fail to address the broader organizational inefficiencies and lack of end-to-end value understanding caused by the very silos that a centralized structure can foster. The issue is the impact of the structure, not the absence of improvement efforts.

The guiding principles

Why it fails: The ITIL guiding principles represent a set of recommendations for an organization's behavior and decision-making, such as "Collaborate and promote visibility" or "Think and work holistically." While a centralized IT department might struggle to embody these principles due to its inherent structure, the principles themselves are not the problem being created. Rather, the organizational silos are the tangible outcome that demonstrates a lack of adherence to these principles, making the silos the direct issue stemming from the centralized structure.

Service level agreements

Why it fails: Service Level Agreements (SLAs) are formal agreements between a service provider and a customer, defining the services provided and the expected performance levels. While crucial for managing service expectations and measuring performance within the ITIL SVS, SLAs are operational artifacts and outputs of service relationships, not one of the foundational components that constitute the Service Value System itself. They are tools used within the SVS to manage and deliver value.

Service desk

Why it fails: The service desk is a key organizational function and a type of ITIL practice, specifically focused on handling incidents, service requests, and providing a single point of contact for users. While integral to effective service delivery and a vital part of the 'Engage' and 'Deliver and support' service value chain activities, the service desk itself is an organizational capability or practice, rather than one of the overarching, foundational components that collectively form the ITIL Service Value System.

ITIL maturity model

Why it fails: An ITIL maturity model is a framework used to assess and improve an organization's capabilities and processes against a defined scale of maturity levels. While valuable for organizational improvement and demonstrating progress in adopting ITIL practices, maturity models are external assessment tools or frameworks, not one of the intrinsic, foundational components that define the structure and operation of the ITIL Service Value System itself. They measure how well the SVS is implemented, rather than being a part of it.

Reverse the change to printer drivers immediately

Why it fails: While reversing a recent change (often referred to as a 'back-out' or 'remediation') might be a valid resolution strategy for an incident, it is not the immediate first step in ITIL. Before any action is taken, especially one that could impact other services or users, the incident must first be formally logged. This logging ensures proper tracking, communication, and adherence to established incident management procedures, allowing for a structured and controlled response rather than an impulsive one.

Inform users that a known error exists

Why it fails: A 'known error' in ITIL is a problem that has a documented root cause and a workaround or permanent solution. It is identified and recorded after a problem investigation has successfully determined the underlying cause of one or more incidents. At the point of receiving multiple calls, the root cause is not yet identified, meaning it cannot be classified as a known error. The immediate priority is to log and manage the incidents, not prematurely declare a known error.

Raise a problem record to investigate the root cause of the driver change

Why it fails: Raising a problem record is a function of Problem Management, which typically focuses on identifying the root cause of incidents to prevent recurrence. While the driver change might be the underlying cause, the immediate priority for a service desk analyst receiving multiple calls is Incident Management: restoring normal service operation as quickly as possible. Problem records are usually raised after incidents have been logged, and often after initial service restoration, to conduct a more thorough, less time-critical investigation.

Output

Why it fails: An output, in ITIL terms, is a tangible or intangible deliverable of an activity or service. While the cloud storage service itself is an output, the question describes a problem with *how* that output performs and is consumed by the user, rather than the mere existence or provision of the service. The service is indeed provided, but its effectiveness is compromised, indicating the issue lies beyond simply delivering the output.

Warranty

Why it fails: Warranty ensures that a service is "fit for use," addressing aspects like availability, capacity, security, and continuity. The scenario describes issues with the service's usability and performance (poor interface, slow speed), which relate to its ability to meet functional requirements effectively, not its fundamental reliability or assurance. Since there's no mention of the service being unavailable, insecure, or lacking sufficient capacity, warranty is not the primary concern.

Outcome

Why it fails: An outcome is the result enabled by a service, as perceived by a stakeholder, which contributes to achieving their objectives. While a poor user interface and slow speed will undoubtedly lead to a suboptimal outcome for the user, the question points to the *direct cause* of that poor outcome: the service's inability to effectively facilitate the user's desired actions. Therefore, the immediate problem is the service's utility, which then subsequently impacts the ultimate outcome.

Metrics and reports

Why it fails: Metrics and reports are crucial for monitoring performance and driving improvement within an organization, but they are not considered a standalone foundational component of the ITIL 4 Service Value System. Instead, they serve as vital outputs and tools utilized across various SVS components, particularly within Continual Improvement and Practices, to measure progress, identify areas for optimization, and demonstrate value. They support the SVS, rather than being a primary structural element.

Service catalog

Why it fails: The service catalog is an important artifact or tool within service management, providing a structured list of available services and their details to customers. However, it is not one of the six foundational components that constitute the ITIL 4 Service Value System itself. While essential for service consumption and provisioning, the service catalog is an outcome produced by the Service Value Chain activities and supported by various ITIL practices, rather than a core building block of the SVS structure.

Service level agreements

Why it fails: Service Level Agreements (SLAs) are formal, documented agreements between a service provider and a customer, defining the services to be provided and the expected performance levels. While critical for managing service expectations and performance, SLAs are not a foundational component of the ITIL 4 Service Value System. They represent agreements established and managed through specific ITIL practices, such as service level management, and are outputs of the 'Engage' and 'Deliver and Support' activities within the Service Value Chain, rather than a structural SVS element.

Initiate the problem management process to find the root cause

Why it fails: Problem management focuses on reducing the likelihood and impact of incidents by identifying and resolving their root causes. While crucial for long-term stability, it is not the immediate first response to a live service disruption. The initial priority in ITIL 4 is to restore service as quickly as possible through incident management, before a deeper, more time-consuming investigation into underlying issues begins.

Implement a known workaround from a previous similar incident

Why it fails: While implementing a known workaround can be an effective technique for restoring service quickly during incident resolution, it is not the initial action. Before any resolution activity, even one that seems immediately obvious, the incident must first be formally logged. This ensures proper tracking, communication, and data collection for future analysis and reporting, adhering to ITIL's structured approach.

Update the known error database with the symptoms

Why it fails: The Known Error Database (KEDB) is a repository for information about problems that have a documented root cause and a workaround. Updating it with mere symptoms is premature and incorrect as a first step when a new disruption occurs. Symptoms are initially logged as part of an incident, and only after a problem has been identified, analyzed, and a root cause determined, would a known error entry be created or updated.

Keep it simple and practical

Why it fails: This principle advocates for using the minimum number of steps or components necessary to achieve a desired outcome, eliminating anything that does not produce value or is overly complex. While reviewing existing work might ultimately lead to simplification, the principle itself is about the deliberate act of simplifying and optimizing processes or services, rather than the initial assessment of the current state. The question implies an initial assessment or leveraging of existing resources, not primarily a simplification effort.

Progress iteratively with feedback

Why it fails: This principle focuses on organizing work into smaller, manageable iterations, allowing for continuous feedback loops and adjustments throughout the development or improvement lifecycle. It emphasizes learning and adapting based on feedback received after each iteration, driving continuous improvement and refinement. While assessing the current state might be part of an initial iteration, the core of this principle is about the method of incremental delivery and refinement, not the foundational act of identifying existing resources.

Focus on value

Why it fails: This principle directs all activities towards the creation of value for stakeholders, encompassing customers, users, and the organization itself. It requires a clear understanding of what constitutes value from the consumer's perspective and ensuring that all efforts contribute directly or indirectly to this outcome. While leveraging existing processes can be a means to deliver value efficiently, the principle itself is about the overarching objective of value delivery, not the specific action of reviewing or reusing current assets.

Optimize and automate

Why it fails: The "Optimize and automate" guiding principle focuses on improving the efficiency and reliability of services and processes through continuous enhancement and the application of technology. While reusing components might contribute to optimization by avoiding redundant work, the core action described in the question—implementing a new service quickly by reusing—primarily emphasizes reducing complexity and effort to achieve speed and practicality, rather than the ongoing refinement and automation of established practices. This principle typically applies to mature processes seeking further gains.

Focus on value

Why it fails: The "Focus on value" guiding principle dictates that all activities undertaken by the organization must directly or indirectly contribute to the creation of value for its stakeholders. While implementing a service quickly through reuse can certainly deliver value, such as faster time-to-market or reduced development costs, the principle itself is about understanding and delivering what is valuable. The question describes a specific method of working—reusing components—which is a practical approach to achieve speed and simplicity, rather than the fundamental commitment to value definition and realization.

Collaborate and promote visibility

Why it fails: The "Collaborate and promote visibility" guiding principle advocates for working together across organizational boundaries and ensuring transparency in all service management activities. It emphasizes shared understanding, information flow, and stakeholder engagement to achieve better outcomes. While identifying reusable components might involve collaboration, the act of reusing them to implement a service quickly is a design and implementation decision focused on reducing complexity and effort, rather than primarily promoting teamwork, communication, or transparency as its core objective.

To ensure compliance with regulations

Why it fails: Regulatory compliance is one governance consideration within the Service Value System, not its primary purpose, which is enabling value co-creation through the service value chain and guiding principles. Compliance is the right emphasis when the objective is meeting external legal or regulatory obligations.

To manage IT assets and configurations

Why it fails: Asset and configuration management is the purpose of ITIL 4's management practises, not the Service Value System, which describes how all components and activities combine to co-create value. Configuration management would be the correct focus when the goal is maintaining accurate records of IT assets.

To manage the cost of IT services

Why it fails: Cost management is a financial management practise activity, not the purpose of the Service Value System, which integrates principles, governance, the value chain and practises to create value. Cost control would be the correct focus when the aim is budgeting and accounting for IT services.

Service desk

Why it fails: A service desk is an operational function for incident and request handling, not a component of the Service Value System (SVS), which comprises the guiding principles, governance, service value chain, practices, and continual improvement. It is tempting because the ITIL 4 SVS includes practices, and service desk is a key practice; however, the question asks for SVS components, not individual practices.

Service portfolio

Why it fails: A service portfolio represents the complete set of services managed by a service provider, encompassing current, retired, and pipeline services. While crucial for service management, the service portfolio is an output or artifact of the 'Service portfolio management' practice, rather than a foundational component of the overarching Service Value System itself. The SVS defines how an organization creates value, whereas the portfolio describes what services are offered.

ITIL maturity model

Why it fails: The ITIL maturity model is an external assessment tool used to evaluate an organization's current level of IT service management capability and identify areas for improvement. It provides a structured approach for measuring the effectiveness and efficiency of an organization's practices against ITIL best practices. However, it is not an intrinsic component that makes up the Service Value System; instead, it is a diagnostic instrument applied to the SVS and its practices.

Keep it simple and practical

Why it fails: This principle focuses on delivering outcomes with the fewest possible steps and resources, avoiding unnecessary complexity. It encourages identifying and eliminating activities that do not contribute to value, ensuring solutions are straightforward and efficient. While reviewing existing work might reveal complexities, the principle itself is about the *design* and *execution* of simpler solutions, not primarily the initial assessment of the current state.

Progress iteratively with feedback

Why it fails: This principle advocates for breaking down work into smaller, manageable iterations, allowing for continuous learning and adaptation based on feedback. It emphasizes building solutions incrementally, testing assumptions, and making adjustments throughout the process to ensure the desired outcome is achieved. While reviewing existing work might inform the starting point of an iteration, the core of this principle lies in the ongoing cycle of development, deployment, and refinement, rather than an initial assessment of what currently exists.

Focus on value

Why it fails: This principle mandates that all activities undertaken by the organization must directly or indirectly contribute to the creation of value for stakeholders. It requires a clear understanding of who the service consumers are, what they perceive as valuable, and how services enable desired outcomes. While reviewing existing work can help identify current value delivery, the principle itself is a foundational driver for *all* decisions and actions, ensuring alignment with stakeholder needs, rather than a specific method for initial assessment.

Incident

Why it fails: An incident is defined as an unplanned interruption to a service or a reduction in the quality of a service. While a slow laptop might be considered an incident requiring resolution, the user's action of *requesting a new laptop* is not an incident itself. This request is a user-initiated action to obtain a pre-defined service, rather than reporting a service failure.

Standard change

Why it fails: A standard change is a low-risk, pre-authorized change that is well-understood and can be implemented without additional authorization. While a laptop replacement involves a change to an individual's assets, ITIL typically categorizes the *provision* of a standard item like a new laptop as a service request. Changes, in the context of change enablement, usually refer to modifications to services, products, or their components, not the routine fulfillment of user requests for standard items.

Problem

Why it fails: A problem is the cause, or potential cause, of one or more incidents, often not immediately known and requiring investigation and diagnosis. While a consistently slow laptop might indicate an underlying problem (e.g., outdated hardware standard, software incompatibility), the user's *request for a new laptop* is not the problem itself. It is a user's desired resolution, not the root cause of the performance issue.

Focus on value

Why it fails: The 'Focus on value' principle emphasizes ensuring all activities contribute to value for stakeholders. While mitigating risk certainly supports value by preventing negative impacts and ensuring successful outcomes, the direct action of assessing risk is fundamentally about optimizing the decision-making process for the change. It's about finding the most effective and efficient path to achieve value, which is an act of optimization, rather than solely defining or pursuing the value itself.

Keep it simple and practical

Why it fails: The 'Keep it simple and practical' principle advocates for using the minimum number of steps and resources to achieve an outcome. While a risk assessment process should ideally be designed to be as simple and practical as possible, the core purpose of performing the assessment itself—evaluating potential impacts and probabilities to inform a decision—is to optimize the outcome of the change. It's about making the most effective decision, which may sometimes require a thorough, rather than merely simple, evaluation to ensure optimal results.

Optimize and automate

Why it fails: Assessing risk before approving a change directly applies the "Optimize and automate" guiding principle. This involves ensuring the change enablement process is as effective and efficient as possible, preventing wasted effort or resources on changes that carry unacceptable risks. By thoroughly evaluating potential impacts and probabilities, the service provider is optimising the decision-making process, aiming to achieve the best possible outcomes and maximise value from the change. This proactive risk assessment is a key part of optimising service delivery.