SkarpChapter 9 of 13
Stability and Change: Problem Management, Change Enablement, and Release
Behind every recurring outage and risky deployment is a story of root causes and change decisions. Learn how ITIL 5 frames these practices so you can recognize them instantly in exam questions and real-world scenarios.
Big Picture: Stability and Change in ITIL 5
Stability and Change Practices
In ITIL 5, stability and change rely on four key practices: incident management, problem management, change enablement, and release management. Each plays a distinct role in keeping services reliable while still evolving.
Typical Flow
A common pattern is: 1) something breaks (incident), 2) a pattern or serious impact appears (problem), 3) a fix is decided (change enablement), 4) that fix is packaged and deployed (release and deployment).
What You Need to Recognize
At Foundation level, you must recognize which practice is active in a scenario, what it is trying to achieve, and whether the situation is about short-term stability, long-term prevention, or safely delivering change.
ITIL 5 Context
ITIL 5 builds on ITIL 4, keeping similar ideas but emphasizing value and outcomes. The term change enablement is now preferred over older labels like change management, but the goal of balancing risk and speed remains.
Problem vs Incident: Purpose and Key Terms
Incident vs Problem
An incident is an unplanned interruption or reduction in service quality. A problem is a cause or potential cause of one or more incidents. Incidents are about fast restoration; problems are about causes and prevention.
Problem Management Focus
Problem management aims to understand and reduce root causes. It looks at patterns in incidents, investigates why they happen, and plans actions that prevent recurrence or reduce impact over time.
Problem, Error, Known Error
A problem is the underlying cause. Once analyzed, it may become a known error: a problem with documented root cause and/or workaround, even if no permanent fix is in place yet.
Exam Tip
If the scenario is about restoring service fast, choose incident management. If it is about stopping the issue from happening again or understanding the cause, choose problem management.
Example: From Incident to Problem to Known Error
First Outage: Incident
The LMS goes down during online exams. An incident is logged and the database cluster is restarted. Service is restored in 15 minutes, and the restart is noted as a temporary workaround.
Pattern: Problem Raised
After three similar Monday outages, the pattern is spotted. A problem record is created: "Repeated LMS outage during exam peak load" to investigate the underlying cause.
Investigation and Known Error
Analysis shows database connection limits are misconfigured. A known error is recorded with root cause and a workaround: pre-emptive restarts and limiting concurrent exam sessions.
Hand-off to Change Enablement
A permanent fix requires changing DB configuration. That proposed change moves into change enablement (and possibly release management) for assessment and safe implementation.
Change Enablement in ITIL 5: Purpose and Types of Change
Purpose of Change Enablement
Change enablement aims to maximize successful changes by assessing risk, authorizing changes, and minimizing service disruption. It is about enabling beneficial change, not blocking it.
High-Level Steps
Typical steps: 1) record and classify the change, 2) assess and plan impact and risk, 3) authorize, 4) coordinate implementation, 5) review and close, especially for significant changes.
Types of Change
Standard changes are low-risk and pre-authorized. Normal changes are assessed individually. Emergency changes are urgent but still need some assessment and authorization.
Exam Signal
If a question focuses on assessing risk and authorizing changes, the practice is change enablement, not release management or problem management.
Release and Deployment: Getting Changes Into Use
Release vs Change Enablement
Change enablement focuses on deciding and authorizing changes. Release management focuses on planning, scheduling, and controlling how those authorized changes are packaged and moved into use.
What Is a Release?
A release is a specific version of a service or component, or a set of components, made available for use. Release management defines what is in the release and how it will be delivered and rolled back.
Deployment
Deployment is the act of moving a release package into an environment: installing, configuring, or pushing updates. It can use methods like blue/green, canary, or phased rollouts.
Exam Signal
If a question is about authorization and risk, choose change enablement. If it is about building, testing, and delivering a version, choose release management (and deployment).
Thought Exercise: Map the Scenario to Practices
Thought Exercise: Map the Scenario to Practices
Read this scenario and answer the questions mentally (or jot down notes):
"A payment service experiences intermittent timeouts during peak shopping hours. The service desk receives many tickets. The operations team restarts the API gateway to restore service. After several weeks, the pattern continues. An engineer discovers that a third-party library has a memory leak. The team proposes upgrading the library and rolling out the new version via their CI/CD pipeline."
Questions to think through step-by-step:
- Which part is incident management?
- Identify the actions that focus on restoring service quickly.
- When does problem management start?
- Pinpoint the moment the focus shifts from "fix it now" to "why does this keep happening?".
- Where does a known error appear?
- Once the memory leak is understood, how would you document it as a known error and workaround?
- Which step is change enablement?
- Who needs to assess the risk of upgrading the third-party library, and what are they deciding?
- Where do release and deployment fit?
- How is the CI/CD pipeline involved in packaging and moving the new version into production?
Try to label each sentence in the scenario with one or more practices:
- Incident management
- Problem management
- Change enablement
- Release management / deployment
Then, compare your mapping with this suggested outline:
- Tickets and restarts: incident management
- Recognizing the repeated pattern and investigating: problem management
- Identifying the memory leak and documenting it with a workaround: known error (problem management)
- Assessing and approving the upgrade: change enablement
- Building, testing, and deploying via CI/CD: release and deployment
Check Understanding: Problem vs Incident vs Change
Answer this Foundation-style multiple-choice question.
Users cannot access the student portal. The service desk applies a known workaround that restores access within minutes. Later, a team is assigned to investigate the underlying cause and propose a permanent fix. Which practices are primarily involved in these two phases?
- Incident management first, then problem management
- Problem management first, then change enablement
- Change enablement first, then release management
- Release management first, then incident management
Show Answer
Answer: A) Incident management first, then problem management
The first phase (restoring access quickly with a workaround) is incident management. The second phase (investigating the underlying cause and proposing a permanent fix) is problem management. Change enablement would come into play later when the permanent fix is being assessed and authorized.
Check Understanding: Change Enablement vs Release
Another quick Foundation-style question.
A team has already received approval to upgrade the university's Wi‑Fi firmware. They now need to group access points into batches, schedule maintenance windows, test the upgrade in a lab, and plan a rollback. Which ITIL 5 practice is MOST directly responsible for this work?
- Incident management
- Problem management
- Change enablement
- Release management
Show Answer
Answer: D) Release management
Once the change is approved, **release management** is responsible for planning, scheduling, and controlling the movement of the new firmware into live use, including batching, testing, and rollback planning. Change enablement handled the risk assessment and authorization earlier.
Flashcards: Key Terms Review
Flip through these cards to reinforce the core concepts.
- Incident
- An unplanned interruption to a service, or reduction in the quality of a service. Focus: restore service quickly.
- Problem
- A cause, or potential cause, of one or more incidents. Focus: understand and reduce root causes, prevent recurrence or reduce impact.
- Known error
- A problem that has been analyzed and has a documented root cause and/or workaround, even if a permanent fix is not yet implemented.
- Problem management
- The practice focused on identifying, analyzing, and managing problems and known errors to reduce the likelihood and impact of incidents.
- Change enablement
- The practice that ensures changes are properly assessed, authorized, and scheduled, balancing risk and value to maximize successful changes.
- Standard change
- A low-risk, pre-authorized change that follows a documented procedure, such as routine user access requests.
- Normal change
- A change that must be assessed and authorized individually, with risk that can range from low to high.
- Emergency change
- A change that must be implemented as soon as possible, for example to resolve a major incident or apply a critical security patch.
- Release
- A version of a service or component, or a set of components, made available for use.
- Release management
- The practice that plans, schedules, and controls the movement of releases to test and live environments.
- Deployment
- The act of moving a release package into an environment, such as installing or rolling out a new version of a service.
Key Terms
- Problem
- A cause, or potential cause, of one or more incidents; focuses on understanding and addressing underlying issues.
- Release
- A specific version of a service or component, or a set of components, made available for use.
- Incident
- An unplanned interruption to a service, or reduction in the quality of a service, requiring immediate action to restore normal operation.
- Deployment
- The activity of moving a release package into an environment, such as installing or enabling new or changed functionality.
- Known error
- A problem that has been analyzed and has a documented root cause and/or workaround, even if a permanent fix is not yet implemented.
- Normal change
- A change that is not standard or emergency; it is assessed, authorized, and scheduled individually.
- Standard change
- A pre-authorized, low-risk change that follows a documented procedure and is frequently implemented.
- Emergency change
- A change that must be implemented as soon as possible, for example to resolve a major incident or apply a critical security patch.
- Change enablement
- The ITIL practice that ensures changes are properly assessed, authorized, and scheduled to maximize value and minimize risk.
- Problem management
- The ITIL practice that manages the lifecycle of problems to prevent incidents from happening or reduce their impact.
- Release management
- The ITIL practice that plans, schedules, and controls the movement of releases to test and production environments.