In ITSM, continually reviewing and improving your services and underlying components creates value. This is where change enablement comes in: the practice of managing changes within your ITSM domain. The change enablement activity includes adding or modifying features to align with customer and business needs, enhancing efficiency or efficacy within internal processes, or implementing controls to satisfy compliance and governance.
Historically, change enablement is emphasized in the deployment phase, but it is far more relevant in the conceptual and development phases. Therefore, we must ensure change enablement is designed and implemented to address the entire value chain of service management. Today, speed is a mandate for most companies, so a challenge is establishing a balance between making beneficial changes quickly while managing risks to existing services. The right change enablement processes are necessary—let’s get started.
Download Now: ITIL 4 Best Practice e-Books
These all-new for 2020 ITIL e-books highlight important elements of ITIL 4 best practices. Quickly understand key changes and actionable concepts, written by ITIL 4 contributors.
Change enablement in ITIL 4
ITIL v4 defines the change enablement practice as maximizing the number of successful service and product changes in three areas:
- Ensuring that risks have been properly assessed
- Authorizing changes to proceed
- Managing the change schedule
(Note: in previous ITIL versions, this practice was known as both “change management” and “change control”. This terminology shift underscores ITIL 4’s embrace of flexible, less rigid environments.)
ITSM defines a variety of changes, but the activities involved are fundamentally the same, no matter your scenario. The five main activities involved in change enablement are:
- Record
- Plan
- Approve
- Execute
- Review
These activities are iterative in nature, as shown in the diagram below. This process can always be adjusted based on the type of change, scale, and approach to the change. Each activity can also be automated, either partially or entirely. Now, let’s take a look at each of these activities.
1. Record
The Record activity includes logging or documenting the change in a common location so that all stakeholders can understand the reason for and priority of a change. Recording facilitates review, assessment, evaluation, and prioritization of changes.
No matter what type of change—standard, normal, or emergency—it must be recorded. The level of detail can vary, but failure to record changes can result in significant challenges like justifying priority and risk level, tracking correlation with incidents, problems, and other changes, or providing evidence during compliance audits.
Recording the change must be documented appropriately, whether in a project proposal or business case, an ITSM platform which assigns a unique ID, or a Kanban board as a backlog item. Recording includes information such as:
- The description, author, and reason for the change
- Services and components the change may impact
- The proposed date and time for the change
- The impact, urgency, risk, and priority of the change
2. Plan
Activities in the Plan phase include aligning tasks and preparing resources and components. The goal of the Plan phase is to ensure a successful change while causing minimal disruption to existing services and components.
Planning can take place during traditional project management or sprint planning. During this phase, you’ll want to:
- Look beyond a single change, aligning with additional changes. This might involve packaging multiple changes into a release and defining joint deployment run books.
- Determine backout/rollback plans—what happens if things go wrong.
During this phase, stakeholder engagement and communication is essential, so that the change can address maximum need. If external third parties are involved, you’ll need to involve contract and vendor management practices.
Standard changes might not require much planning, but stakeholder communication and resource planning will still be required. Despite the urgency, emergency changes will require planning, but this can be high-level, requesting less detail compared to normal changes.
3. Approve
Formal authorization is required for changes. The level of authorization is driven by the change and your company’s culture: high-risk changes combined with a risk averse culture might require more stakeholder approval.
- Where changes could significantly impact business operations, the highest level of approval might be required, including approval from the CEO, board of directors, and/or regulators and auditors.
- Lower risk changes can be approved by the product team as part of sprint planning, a project steering committee, change advisory board (CAB), or supervisors.
- High-velocity organizations may consider decentralizing authority to the minimum possible to encourage efficiency and ownership.
Approval provides clearance for procurement, detailed planning, and scheduling. Conversely, failure to approve changes might result in challenges around accountability or resource allocation, particularly if the change goes poorly.
Record approval details for both accountability and compliance requirements. A standard change may not require further authorization beyond the model preauthorization, except when deviations occur. An emergency change would still require authorization, but this would be done by a separate authority, such as an emergency CAB, in order to expedite the approval process.
4. Execute
The Execute phase includes just that: the implementation of the change. Execute and implement the change per the agreed schedule and steps recorded by all stakeholders. Communication is critical. Customers, employees, and other users (such as auditors or third parties) need to know what to expect from the change, both in the short-term and over time.
Execution can be done in a staging environment for validation, or it can be released during a sprint. Testing is vital to ensure functional and non-functional requirements, though the level of testing might vary depending on the type of change.
Emergency change execution is expedited. Normal changes, however, might follow the planned change schedule or be automated if your company has implemented the necessary infrastructure, such as CI/CD platforms. When a change goes wrong, activate your backout/rollback plan.
5. Review
After a change is executed, conduct a post-evaluation to determine whether the change was successful. Particularly when a change fails, the post-eval offers sources for continual improvement. Your review should:
- Confirm that the change met original objectives that were recorded and approved
- Ensure stakeholders are satisfied with the outcome
- Verify no major or unexpected side effects resulted
- Consider root causes and corrective and preventative actions, in cases when a change failed
In an agile environment, the review is usually conducted during the sprint review (focus on the outputs) and the sprint retrospective (focus on the process). Where a CAB is involved, a post-implementation review might take place during the following meeting. A project status or closeout meeting might also provide a platform for review of changes.
Communication of the change review is vital for stakeholder engagement. Failure to perform this activity might lead to loss of improvement opportunities as well as lack of closure or feedback from key stakeholders on the change.
No matter the type, approach, or sequence to change, remember the importance of change enablement: ensuring the right level of control is maintained, particularly in high-risk situations. Balance meeting business and customer needs quickly and protecting the same needs from undue risk.
