The ITIL Service Value System practice questions

Progress iteratively with feedback

Why wrong: While crucial for continuous improvement and agile development, the "Progress iteratively with feedback" principle is primarily applied *after* an initial understanding of value has been established and design work has commenced. It guides the incremental delivery and refinement of services, ensuring that solutions evolve based on stakeholder input and learning. However, it does not define the initial purpose or direction of a new service, making it a subsequent step rather than the first consideration.

Keep it simple and practical

Why wrong: The "Keep it simple and practical" principle is vital for designing efficient and manageable services by eliminating unnecessary complexity and focusing on outcomes. However, its effective application relies on a clear understanding of what constitutes "practical" and what outcomes are desired. Without first defining the value a new IT service aims to deliver, efforts to simplify might inadvertently remove essential functionalities or fail to address core customer needs.

Start where you are

Why wrong: The "Start where you are" principle encourages leveraging existing, proven resources, processes, and services to avoid reinventing the wheel and to accelerate delivery. While highly relevant for optimizing or integrating new components into an existing landscape, it is not the foundational principle for initiating a *new* service. Before assessing existing assets, an organization must first determine what value the new service intends to create, providing the necessary context for evaluating current capabilities.

Four dimensions of service management

Why wrong: The Four Dimensions of Service Management (Organizations and People, Information and Technology, Partners and Suppliers, Value Streams and Processes) provide a holistic framework for understanding the complexities of service provision. While they ensure all aspects are considered when designing or operating a service, they do not prescribe the specific activities or steps for implementing improvements to a process following a major outage. They are descriptive of service components, not prescriptive for improvement actions.

Guiding principles

Why wrong: ITIL's Guiding Principles, such as 'Focus on Value' or 'Progress Iteratively with Feedback,' offer universal recommendations that guide an organization in all circumstances, regardless of changes in its goals, strategies, or type of work. While these principles inform the approach to improvement, they do not provide the concrete activities or framework for how to execute specific process improvements after a major service outage. They are foundational philosophies, not operational steps.

Governance

Why wrong: Governance refers to the means by which an organization is directed and controlled, ensuring that policies and strategies are implemented and that objectives are achieved. It provides the framework for decision-making and accountability, including setting the strategic direction for improvement. However, governance itself does not perform the actual process improvement activities; rather, it ensures that the appropriate structures and processes, like those within the Service Value Chain, are in place and effective for delivering continual improvement.

Problem management

Why wrong: Problem management aims to reduce the likelihood and impact of incidents by identifying and eliminating their root causes, often leading to permanent solutions. While a workaround might be documented as a 'known error' within problem management for future reference, the actual act of implementing it to restore service is an incident management activity. Problem management's focus is on analysis, diagnosis, and prevention, not the immediate restoration of a disrupted service.

Change management

Why wrong: Change management is the practice of ensuring that changes are recorded, evaluated, authorized, planned, and implemented effectively to minimize risk and maximize value. While a workaround might eventually lead to a permanent change, the immediate act of implementing a temporary workaround to restore service operation is typically not considered a formal change requiring change authority. It is a reactive measure to an incident, not a planned modification to a service or configuration item.

Service request management

Why wrong: Service request management focuses on fulfilling pre-defined, standard requests from users, such as providing information, access to a service, or a standard change. These requests are typically low-risk, routine, and part of normal service delivery, often initiated by the user. Implementing a workaround for an unexpected service disruption, however, is a reactive measure to an incident, not a pre-approved, standard request for a service component or information.

Guiding principles

Why wrong: Guiding principles are a set of universal recommendations that can guide an organization in all circumstances, promoting good decision-making and behavior across the entire service value system. While foundational for an IT department's culture and strategy, they do not prescribe a specific sequence of operational activities or processes for directly creating value or transitioning a service delivery model.

Governance

Why wrong: Governance in ITIL 4 refers to the means by which an organization is directed and controlled, ensuring that the organization's activities align with its overall strategy and objectives. It involves evaluating, directing, and monitoring performance and compliance across the service value system. While crucial for effective management and oversight, governance itself is not a set of interconnected operational activities that an IT department would use to directly create value or transition its service delivery model.

Four dimensions of service management

Why wrong: The four dimensions of service management describe the perspectives that are critical to the holistic management of services, ensuring a balanced focus on all relevant aspects. These dimensions—Organizations and people, Information and technology, Partners and suppliers, and Value streams and processes—provide a framework for considering internal and external factors. However, they are conceptual lenses for analysis and design, not a sequential or interconnected set of operational activities that an IT department would execute to create value or transition its service delivery approach.

Guiding principles

Why wrong: While Guiding Principles, such as 'Collaborate and promote visibility,' certainly encourage cross-team interaction and shared understanding, they are foundational recommendations for organizational behavior and decision-making. They provide a mindset and cultural guidance but do not offer a concrete, structured model or set of operational activities that directly outlines *how* different teams should functionally integrate their work to co-create value in a systematic, end-to-end manner.

Four dimensions of service management

Why wrong: The Four Dimensions of Service Management (Organizations and People, Information and Technology, Partners and Suppliers, Value Streams and Processes) provide a holistic framework for considering all aspects critical to effective service management. While essential for ensuring a comprehensive approach, these dimensions are analytical lenses for understanding an organization's capabilities and context, not an operational model or a set of activities designed to directly integrate diverse teams into a unified workflow for value delivery.

Governance

Why wrong: Governance in ITIL 4 refers to the means by which an organization is directed and controlled, ensuring that policies and strategies are implemented and followed. It provides strategic direction, oversight, and accountability mechanisms, but it does not prescribe the operational activities or the direct, day-to-day workflow integration required for different functional teams to collaboratively produce and deliver services. Governance sets the 'what' and 'why,' not the 'how' of team integration for value co-creation.

Four dimensions of service management

Why wrong: The Four Dimensions of Service Management (Organizations and People, Information and Technology, Partners and Suppliers, Value Streams and Processes) are critical perspectives that apply to *all* components of the Service Value System (SVS). They are not standalone components *within* the SVS itself, but rather a framework for ensuring a holistic approach to service management. Each SVS component, such as the service value chain or practices, must be considered through the lens of these four dimensions to achieve effective and balanced service delivery.

Service level agreements

Why wrong: Service Level Agreements (SLAs) are documented agreements between a service provider and a customer that specify the services to be provided and the expected level of service. While crucial for defining service expectations and performance, SLAs are operational outputs and artifacts primarily generated and managed by specific ITIL practices, such as Service Level Management. They are not foundational components that constitute the structure of the ITIL Service Value System itself.

Organizational structure

Why wrong: Organizational structure refers to the hierarchy and reporting relationships within an enterprise, defining how activities are directed to achieve organizational aims. While essential for any functioning organization and a key consideration within the "Organizations and People" dimension, it is not explicitly defined as a direct, named component of the ITIL Service Value System itself. The SVS provides a framework for value creation, which an organization then implements through its chosen structure.

How do we keep the momentum going?

Why wrong: This question aligns with step 7, "How do we keep the momentum going?", in the ITIL 4 Continual Improvement Model. This final step focuses on embedding the successful improvement into standard operations, communicating achievements, and identifying further opportunities for iteration or new initiatives. However, it is premature to address this immediately after "Take action" (step 5) without first confirming the actual success and impact of the current improvement effort through evaluation.

How do we get there?

Why wrong: This question represents step 4, "How do we get there?", of the ITIL 4 Continual Improvement Model. This step is dedicated to planning the improvement, which includes designing the solution, outlining the specific actions required, and allocating necessary resources. Since the team has already "completed step 5 take action," the planning phase has already been executed, making this question irrelevant to the current stage of the improvement cycle.

Where do we want to be?

Why wrong: This question corresponds to step 3, "Where do we want to be?", in the ITIL 4 Continual Improvement Model. This step involves defining the specific target state and setting clear, measurable objectives for the improvement initiative. This foundational work occurs early in the improvement cycle, well before any actions are taken or results are evaluated, making it an inappropriate question for a team that has just completed the "Take action" phase.

The problem report provided a temporary workaround to resolve the incident.

Why wrong: This statement is incorrect because, while Problem Management can provide workarounds, the exhibit specifies that the workaround derived from the problem report was specifically for testing purposes related to the problem investigation. It was not intended or utilized as a temporary measure to resolve the active incident itself. Workarounds for incident resolution typically aim to restore service functionality quickly, which was not the stated purpose of this particular workaround.

The incident was resolved by implementing the workaround from the problem report.

Why wrong: This statement is inaccurate as the incident's resolution method was explicitly a rollback, not the implementation of a workaround from the problem report. Incident Management focuses on restoring service operation as quickly as possible, and in this scenario, a rollback was the chosen and effective method. The problem report's findings, including any workarounds, might inform future actions but did not directly resolve this specific incident.

The incident caused the problem, so problem management closed the problem as duplicate.

Why wrong: This statement misrepresents the relationship between incidents and problems in ITIL 4. Incidents are symptoms of an underlying problem; problems are the root causes of incidents, not the other way around. Furthermore, the problem was identified as a 'known issue,' indicating it was already recognized or under investigation, rather than being caused by this specific incident. Therefore, closing it as a duplicate due to the incident's causation is incorrect.

Conduct a root cause analysis to fully understand the memory leak.

Why wrong: Conducting a Root Cause Analysis (RCA) is a core activity of Problem Management, aimed at identifying the underlying cause of an incident to prevent recurrence. While crucial for long-term stability and preventing future incidents, RCA is not the immediate priority during active incident management, which focuses on restoring service as quickly as possible. The question implies an active incident where the immediate goal is service restoration, not deep investigation into the already known memory leak.

Increase the application server's CPU capacity to handle the load.

Why wrong: Increasing the application server's CPU capacity would not resolve a memory leak, as the issue stems from inefficient memory utilization, not a lack of processing power. A memory leak causes the application to consume increasing amounts of RAM until exhaustion, leading to performance degradation and eventual crashes, regardless of CPU availability. This action merely delays the inevitable impact by providing more resources for the leak to consume, failing to address the fundamental problem.

Escalate the incident to the service desk for faster resolution.

Why wrong: Escalating the incident to the service desk is inappropriate because the service desk is typically the initial point of contact for users reporting incidents, not a higher-level technical resolution group for complex issues. For a known technical problem like a memory leak, the incident would likely already be with a technical support team or specialist. Escalation usually involves moving the incident to a higher technical tier or management for specialized expertise or decision-making, not back to the front line.

Audit

Why wrong: Audit is not an activity of the service value chain.

Monitor and control

Why wrong: Monitor and control is not a separate activity; it is embedded in Deliver & Support.

1. Detection and logging, 2. Categorization, 3. Solution identification, 4. Root cause analysis, 5. Closure

Why wrong: This order is incorrect because identifying a solution prior to conducting thorough root cause analysis is a common anti-pattern in problem management. Without understanding the true underlying cause, any proposed solution is likely to be a temporary workaround or address only symptoms, leading to recurring issues and wasted resources. Effective problem resolution demands that root cause analysis precedes solution identification to ensure sustainable fixes.

1. Categorization, 2. Detection and logging, 3. Root cause analysis, 4. Solution identification, 5. Closure

Why wrong: This sequence is fundamentally flawed as categorization cannot logically precede the detection and formal logging of a problem. A problem must first be recognized, recorded, and assigned a unique identifier within the problem management system before it can be classified or grouped based on its characteristics. Attempting to categorize an unlogged event would bypass essential tracking and accountability mechanisms, hindering effective management.

1. Detection and logging, 2. Root cause analysis, 3. Categorization, 4. Solution identification, 5. Closure

Why wrong: This order is inefficient and deviates from ITIL 4 best practices, as attempting root cause analysis before categorization can hinder the investigation process. Categorization helps to group similar problems, assign them to appropriate teams, and apply relevant diagnostic tools or knowledge articles, thereby streamlining the analysis effort. Skipping this crucial step can lead to disorganized investigations, delayed resolution, and misallocation of resources.

Governance: Sets of organizational resources designed for performing work or accomplishing an objective.

Why wrong: This statement incorrectly defines Governance. The description provided, 'Sets of organizational resources designed for performing work or accomplishing an objective,' actually refers to ITIL 4 Practices. Governance, in contrast, is the means by which an organization is directed and controlled, ensuring accountability and alignment with strategic objectives across all levels.

Practices: The means by which an organization is directed and controlled.

Why wrong: This option incorrectly defines Practices. The description, 'The means by which an organization is directed and controlled,' accurately describes ITIL 4 Governance. Practices, instead, are sets of organizational resources, including people, processes, and technology, specifically designed to perform work or accomplish a particular objective, such as incident management or service desk operations.