1. About this document
It is split into five main sections, covering:
- general information about the practice
- the practice’s processes and activities and their roles in the service value chain
- the organizations and people involved in the practice
- the information and technology supporting the practice
- considerations for partners and suppliers for the practice.
1.1 ITIL® 4 QUALIFICATION SCHEME
Selected content of this document is examinable as a part of the following syllabus:
- ITIL Specialist: Create, deliver and support
- ITIL Specialist: High Velocity IT
Please refer to the syllabus documents for details
2. General information
2.1 PURPOSE AND DESCRIPTION
Key message
The purpose of the change enablement practice is to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule.
The change enablement practice aims to ensure that changes to services and their components are controlled and that they meet the organization’s change-related needs. Authorized changes should enable the desired outcomes and meet the organization’s requirements regarding change throughput (the number of changes made and the speed of change realization) and risk management. Flexibility and agility permeate this practice because they are key aspects of a modern organization.
The change enablement practice incorporates three premises:
- Changes are planned and realized in the context of value streams. The practice is integrated into value streams and ensures that changes are effective, safe, and timely in order to meet stakeholders’ expectations.
- The practice does not aim to unify all the changes planned and carried out in an organization into one big picture: in a digital environment, where hundreds of changes may be happening simultaneously, this is neither possible nor required.
- The practice should focus on balancing effectiveness, throughput, compliance, and risk control for all changes in the defined scope.
2.2 TERMS AND CONCEPTS
Change
The addition, modification, or removal of anything that could have a direct or indirect effect on services.
The change enablement practice ensures that every change achieves the intended outcomes. This aligns with the guiding principle ‘focus on value’. Stakeholders are more interested in the value that a change enables than in the technical details of the change. Changes that are implemented with technical precision, but which fail to enable the desired outcomes, fall short of expectations. Additionally, changes may have unintended outcomes, including negative impacts on users, service downtime, degradation, and destabilization. It is important to control these outcomes.
Changes are accomplished using various approaches and methodologies, each of which represents a different level of business risk. Changes in software are often made through frequent and regular deployment of new features and modifications. These changes can be delivered through continuous integration/continuous delivery (CI/CD), as practised in DevOps and other forms of
iterative/Agile delivery (for more information on CI/CD, see ITIL Specialist: Create, Deliver and Support). Changes in physical infrastructure may be slower, requiring a staged, ‘waterfall’ approach. Some changes of this type may be run as projects, using relevant project management techniques and controls.
In practice, however, few organizations are fully at one extreme or the other. Organizations have multiple value streams, most of which include changes. The change enablement practice must be adaptive to meet the needs of various approaches to change development.
2.2.1 Complexity-based approach to changes
The change enablement practice should ensure a balance between change effectiveness, change throughput, and risk control. This means that the approaches to change planning authorization and ongoing control need to be selected carefully.
Changes are possible in all business situations, from business as usual to catastrophic (see Figure 2.1). Organizations should be able to make changes in any situation on this spectrum.
Business-as-usual situations are relatively predictable, with low levels of uncertainty. Catastrophic situations have the highest levels of uncertainty. Changes in any type of situation, however, have varying levels of complexity and predictability.
Changes can be standardized and automated where uncertainty is low, which helps to decrease the costs and accelerate the changes. Check-lists, templates, and standardized ways of working can be used in these situations. This is reflected in the definition of a standard change.
Standard change
A low-risk, pre-authorized change that is well understood and fully documented, and which can be implemented without needing additional authorization.
Examples of standard changes include:
- fulfilment of a service request
- maintenance of infrastructure
- routine testing of contingency measures
- routine software updates.
When the procedure for a standard change is created or modified, the procedure should be authorized and undergo a full risk assessment. This risk assessment does not need to be repeated for every change; it is needed only if the procedure itself undergoes another modification.
Although standard changes are usually associated with business-as-usual situations, there are multiple examples of standardization in situations with higher levels of uncertainty. These include:
- standard incident resolutions
- standard responses to disasters.
These may help organizations to decrease uncertainty in extreme situations by following a pre- defined routine and applying pre-tested solutions.
However, standard solutions may be unavailable or fail. These cases require a different approach to the change enablement practice.
When there is no effective standardized approach to a change, organizations usually attempt to plan, authorize, and control that change. They follow a process that includes collective expert assessment, authorization, and control. The process is performed by a group of people combining expertise and authority. These are ‘normal changes’, some of which are low risk. The change authority for these is usually someone who can make rapid decisions, often using automation to accelerate the change. When a normal change is high risk, the change authority might be the management board or the equivalent.
Change authority
A person or group responsible for authorizing a change.
A normal change can be triggered by the creation (manual or automated) of a change request. However, organizations with an automated pipeline for CI/CD often automate most of the change enablement practice processes. Some steps (such as service request registration) may become practically invisible.
Change models provide guidance for handling normal changes. Organizations usually develop change models that determine procedures and roles for the assessment, authorization, and ongoing control of changes based on their type.
Change model
A repeatable approach to the management of a particular type of change.
Change models can be defined based on factors such as:
- systems/technologies to change
- scale of change
- locations/territories
- customers
- regulatory requirements affecting the change.
The models may determine an approach to the change enablement practice in all four dimensions of service management which is shown in Table 2.1.
Table 2.1 Examples of factors that may be determined by change models in the four dimensions of service management
| Value streams and processes | Organizations and people | Information and technology | Partners and suppliers |
|---|---|---|---|
| Change process and procedures, including the level of formalization Level and form of the change authority Acceptance criteria | Competencies needed Organizational solutions (such as change advisory board, or peer review) Accountability Responsibilities Delegation rules | Information requirements Tooling Automation | Involvement of third parties to the change planning and realization Communications with partners and suppliers |
In addition, organizations need to consider a change’s risk level. An organization may, for example, decide to limit a change’s potential risk by deconstructing it into iterations. Each iteration of the change is then below an agreed risk-level threshold, introducing limited and manageable risk. Generally, smaller changes also cost less and are easier to control. Based on these considerations, many organizations limit the size of individual changes, particularly of software and other digital resources.
Change models may be helpful when managing uncertainty in complex situations. For example, a process determined by the change model may include the safe-to-fail testing of several hypotheses before one or some of the solutions are implemented. This may help to address incidents and disasters where there is no clarity around what changes are needed. Although this approach is more common for unstable situations, it is also applicable to business-as-usual situations.
The change enablement practice should ensure that changes are implemented effectively, safely, and promptly in emergency situations. Changes that help to correct emergency situations are commonly known as emergency changes.
Emergency change
A change that must be introduced as soon as possible.
Although some emergency scenarios may be predicted and provided with a standard solution (including standard changes required), many situations do not have a ready solution or the time for safe-to-fail testing. Change models for emergency changes often include bypassed or delayed procedures, such as change request registration or updating of the change schedule. They may also determine a dedicated change authority of high power and availability, together with other special arrangements. The aim is to accelerate changes while keeping risks at an acceptable level.
Two important considerations regarding emergency changes:
- ‘Emergency’ does not mean ‘no rules or control’. Emergency changes can be standardized and automated. This can accelerate them without compromising control. Emergency does not always mean completely unpredictable and unknown.
- Some emergency changes do deal with unpredictable and unknown situations. They may need fast implementation of the best available solution without sufficient information or time for testing. This applies to situations where the cost of delay is equal to or higher than the risks associated with unsuccessful change.
Key message
The change enablement practice should include approaches to situations of different complexity and predictability. These approaches may include:standard changeschanges planned and controlled based on expert analysis of the situationchanges planned based on multiple safe-to-fail experimentsemergency changes implemented without sufficient assessment and planning.The first three approaches are applicable in all types of situations in business, from business as usual to catastrophic disasters. The last approach applies to chaotic situations where the cost of delay is higher than the cost of a wrong action.Standardization and automation can be hugely beneficial for this practice, because they allow for significantly accelerated change while retaining sufficient control. This is the recommended method of change enablement for digital resources, products, and services.Decreasing the size of changes can increase the effectiveness and throughput of the practice while decreasing the level of risk. Size should be an important consideration for organizations’ change models.
2.2.2 Change definition and scope
The change enablement practice supports all value streams and can be used with any other practice because they can all initiate changes to products and services. However, organizations usually limit the application of the change enablement practice to a finite number of change types based on what is being changed and the context in which the changes are occurring.
Typically, the practice is used for changes to the information and technology dimension of the organization’s products and services. Other practices may significantly contribute to the enablement of changes in the three other dimensions of service management. Respective changes, although formally covered by the change definition, may be excluded from the scope of the change enablement practice (see Table 2.2 for examples of changes).
Organizations define which changes, at which level of control, should be addressed by the change enablement practice. This is based on several considerations, usually including:
- Level of risk Risks that are addressed and introduced by the change should be considered
to determine the level of control. - Costs and losses Costs of the change and losses addressed by the change should be evaluated
to determine the level of control. - Scope of configuration and asset control Registered configuration items and assets usually require control of modifications. The change enablement practice provides means for this.
- Internal and external regulatory requirements The organization may be obliged to comply with explicit change-related requirements.
- Need for visibility of the change impact In the environment where components are dynamically interconnected, the visibility of planned and ongoing changes and change progress is important.
Table 2.2 Examples of changes in the four dimensions of service management
| Dimension of service management | Areas subject to potential change | Scoping considerations |
|---|---|---|
| Information and technology | Hardware and software Service architecture Service design Technical and user documentation | Usually addressed by the change enablement practice in conjunction with the project management, service design, and architecture management practices |
| Organizations and people | Organizational structure Roles and responsibilities Culture and rules of work behaviour | Usually addressed by the organizational change management and project management practices |
| Personal competencies | Usually addressed by the workforce and talent management practice | |
| Value streams and processes | Value streams architecture Work processes and procedures Process documentation | May be addressed by the change enablement and/or other practices |
| Partners and suppliers | Service dependencies on third parties at the architecture level Contractual arrangements with third parties (new suppliers, change of responsibilities, etc.) Contract and other documents (version changes, prolongation, etc.) | May be addressed by the change enablement practice, in conjunction with the supplier management and/or other practices |
Based on these and other considerations, organizations decide whether modifications to products and services should be treated as changes and, if so, whether they should be considered as minor, medium, or major. The change enablement practice usually includes different approaches to changes of different scales which are normally detailed in the change models.
2.2.3 Automation of the change enablement practice and its effect on visibility
When changes are made to software and other digital resources, controls that ensure change success may be automated, including change scheduling, integrity control, version control, compatibility control, and many others. Automation increases the throughput and keeps the risks associated with changes to an acceptable level, particularly when combined with the decrease in size of the individual changes (see section 5 and the practice guides for software development and management, release management, and deployment management).
The full scope of planned and ongoing changes may be hard to oversee across an organization when change enablement is highly automated. It becomes difficult to identify what change is being made where. This is due to the high level of complexity of the controlled environments.
Organizations should embrace this complexity and adapt to the higher level of uncertainty while ensuring that the level of control is sufficient.
Again, the primary means of achieving sufficient levels of control are by decreasing the change size, standardizing, and automating.
2.3 SCOPE
The scope of the change enablement practice includes:
- planning changes to controlled environments in the organization
- planning change models and change standardization
- planning individual change workflows, activities, and controls
- scheduling and coordinating all ongoing changes
- controlling the progress of changes from initiation to completion
- communicating change plans and progress to relevant stakeholders
- assessing change success, including outputs, outcomes, efficiency, risks, and costs.
There are several activities and areas of responsibility not included in the change enablement practice, although they are still closely related to changes. These are listed in Table 2.3, along with references to the practice guides in which they can be found. It is important to remember that the ITIL practices are merely collections of tools to use in the context of value streams; they should be combined as necessary, depending on the situation.Table 2.3 Activities related to the change enablement practice that are described in other practice guides
| Activity | Practice guide |
|---|---|
| Change initiation | All other practices |
| Change realization | Architecture management Deployment management Infrastructure and platform management IT asset management Release management Service catalogue management Service configuration management Service design Service level management Software development and management Supplier management Workforce and talent management |
| Change risks assessment and control | Risk management |
| Costs control, financial evaluation of changes | Service financial management |
| Management of projects | Project management |
| Management of organizational changes | Organizational change management |
| Testing | Service validation and testing |
2.4 PRACTICE SUCCESS FACTORS
Definition: Practice success factor
A complex functional component of a practice that is required for the practice to fulfil its purpose.
A practice success factor (PSF) is more than a task or activity; it includes components from all four dimensions of service management. The nature of the activities and resources of PSFs within a practice may differ, but together they ensure that the practice is effective.
The change enablement practice includes the following PSFs:
- ensuring that changes are realized in a timely and effective manner
- minimizing the negative impacts of changes
- ensuring stakeholder satisfaction
- meeting change-related governance and compliance requirements.
2.4.1 Ensuring that changes are realized in a timely and effective manner
The focus of the change enablement practice is the effectiveness and timeliness of the changes.
Change effectiveness can be measured by the levels of outputs and outcomes of the change. In the context of change outputs, effective change can be described as ‘a change that successfully transforms resources from the initial state to the pre-defined target state’. However, the target state is rarely the goal of the change; the target state enables an outcome. At the outcome level, effective change can be described as ‘a change that successfully contributed to the achievement of the desired pre-defined outcomes’.
It is important that both perspectives are considered and included in the change planning, ongoing control, and assessment. The definition and assessment of outputs can be used at the level of individual changes; outcomes are usually enabled by multiple changes and other initiatives. The difference is extremely important for ongoing management and control at the level of teams involved in realization of the changes. These teams should be aware of both the content and the context of the changes they realize. Teams’ performances should be assessed based on their contributions to the outcomes that are within their responsibilities.
Effectiveness may include various characteristics of quality defined for the resources and services in the scope of the change. These may include security, performance, conformance to regulations, and usability.
The timeliness of change is a measure of meeting the expectations and requirements of the change initiator for the time of change completion. Timeliness of change can be measured against the approved change plan, but meeting the change initiator’s needs is the main concern. This should be an important consideration when changes are being planned, controlled, and assessed.
Sometimes failure to meet timeliness requirements makes a change ineffective, useless, or harmful.
Effectiveness and timeliness of changes can be improved by:
- decreasing the size of individual changes
- standardizing and automating changes
- including a feedback loop in every iteration of change planning and realization
- capturing expectations and communicating the progress of changes
- effectively integrating multiple ITIL practices for changes in the context of value streams.
2.4.2 Minimizing the negative impact of changes
Changes are sources of disruption and risk. The change enablement practice is expected to keep risks to an acceptable level. In a simple, slow-changing environment, this could be achieved by imposing controls on every step of the change, introducing more stakeholders in the authorization step, and creating a contingency plan for every occasion. However, these controls would lead to ineffective and delayed change realization, which is unacceptable in today’s complex environment.
To balance the timeliness, effectiveness, and risk level of change, organizations define change models where manual and automated controls are combined to standardize changes, continually reduce change size, and monitor and assess the impact of changes on the infrastructure, services, and stakeholders. Minimization of risks is achieved by reducing the impact of every individual change, enabling a quick automated return to the previous stable state in case of change failure, and automated configuration management.
2.4.3 Ensuring stakeholder satisfaction
Many stakeholders have an interest in changes, including:
- service provider teams
- users
- customers
- sponsors of service provision
- sponsors of service consumption
- suppliers and partners.
The change enablement practice ensures that stakeholders are identified and that their expectations are captured, considered, and met as appropriate. This is done in conjunction with the relationship management, risk management, and business analysis practices, among others. The change enablement practice mostly focuses on the continual monitoring of stakeholder engagement and satisfaction during change realization and after the change is complete. Ongoing communication, status updates, and feedback collection are important components of satisfaction management.
2.4.4 Meeting change-related governance and compliance requirements
Many change-related governance and compliance requirements affect the change enablement practice in general as well as individual changes. It is important that organizations capture them, understand them, and ensure that they are met. The change enablement practice supports this by:
- including required controls in change models, processes, and procedures
- providing required information
- initiating improvement to prevent or correct non-compliance.
2.5 KEY METRICS
The effectiveness and performance of the ITIL practices should be assessed within the context of the value streams to which each practice contributes. As with the performance of any tool, the practice’s performance can only be assessed within the context of its application. However, tools can differ greatly in design and quality, and these differences define a tool’s potential or capability to be effective when used according to its purpose. Further guidance on metrics, key performance indicators (KPIs), and other techniques that can help with this can be found in the measurement and reporting practice guide.
Key metrics for the change enablement practice are mapped to its PSFs. They can be used as KPIs in the context of value streams in order to assess the contribution of the practice to the effectiveness and efficiency of those value streams. Some examples of key metrics are given in Table 2.4.
Table 2.4 Examples of key metrics for the practice success factors
| Practice success factors | Key metrics |
|---|---|
| Ensuring that changes are realized in a timely and effective manner | Aggregated timeliness processing index (TPI)a over the period Average time of change realization per change model Change initiators’ satisfaction with change outcomes Change initiators’ satisfaction with change timeliness Change success/acceptance rate over period TPI for individual changes |
| Minimizing the negative impact of changes | Business impact of change-related incidents Impact of changes identified as sources of problems/errors Number and duration of change-related incidents |
| Ensuring stakeholder satisfaction with changes and change enablement | Stakeholder satisfaction with the procedures and communications for the change enablement practice Stakeholder satisfaction with realization of individual changes |
| Meeting change-related governance and compliance requirements | Compliance with formally stated requirements, according to audit reports Number and criticality of change-related audit findings and non- compliances Number and impact of change-related compliance incidents |
The correct aggregation of metrics into complex indicators will make it easier to use the data for the ongoing management of value streams, and for the periodic assessment and continual improvement of the change enablement practice. There is no single best solution. Metrics will be based on the overall service strategy and priorities of an organization, as well as on the goals of the value streams to which the practice contributes.
3. Value Streams and processes
3.1 Value stream contribution
Like any other ITIL practice, the change enablement practice contributes to multiple value streams. It is important to remember that a value stream is never formed from a single practice. The change enablement practice combines with other practices to provide high-quality services to consumers. The main value chain activities to which the practice contributes are:
- obtain/build
- design and transition
- deliver and support
- improve.
The contribution of the change enablement practice to the service value chain is shown in Figure 3.1.
3.2 Processes
Each practice may include processes and activities that may be necessary to fulfil the purpose of that practice.
Definition: Process
A set of interrelated or interacting activities that transform inputs into outputs. A process takes one or more defined inputs and turns them into defined outputs. Processes define the sequence of actions and their dependencies.
Change enablement activities form two processes:
- change lifecycle management
- change optimization.
3.2.1 Change lifecycle management
This process includes the activities listed in Table 3.1 and transforms the inputs into outputs.
Table 3.1 Inputs, activities, and outputs of the change lifecycle management process
| Key inputs | Activities | Key outputs |
| Change requests Change models and standard change procedures Policies and regulatory requirements Configuration information IT asset information Service catalogue Service level agreements(SLAs) with consumers and suppliers/partners Financial guidelines and constraints Risk information Capacity and performance information Continuity policies and plans Information security policies and plans | Change registration Change assessment Change authorization Change planning Change realization control Change review and closure | Change records Change schedule Change review reports Changed resources and services |
Figure 3.2 shows a workflow diagram of the process.
The process may vary depending on the change model. Table 3.2 provides examples of the activities in two change models.
The change model examples in Table 3.2 are just two of many options illustrating different models. Organizations should embrace the diversity of architectures and approaches to management to ensure flexibility of services and to meet stakeholder expectations.
Table 3.2 Activities of the change lifecycle management process
| Activity | Normal changes; manual management | Standard software changes; highly automated management |
|---|---|---|
| Change registration | A change request is received from a change initiator. Based on the change request, a change record is created by the service owner, resource owner, change manager, or change coordinator. The change initiator is sent a confirmation of the change request receipt. | Change requests are accumulated in the product or service backlog. The product development team decides which requests will be taken into development. |
| Change assessment | The service owner, resource owner, change manager, or change coordinator performsan assessment of the change impact, associated risks, and required resources. If needed, other subject matter experts may be involved.Assessment information is added to the change record. | The product development team decides on the best way to proceed with the change. |
| Change authorization | The change authority who has been assigned in line with the change model reviews the change record and provides authorization. If the change is not authorized, it is sent for review and closure.Add itional assessments may be required, so the change record is returned for assessment together with the rationale for this. | Change authorization is not needed: -because standard changes are likely to be pre-authorized -where it has been agreed for this model that changes are authorized by taking them into development via backlog assessment. |
| Change planning | Authorized changes are planned in line with the change model. According to the model, roles with relevant expertise and authority are involved in the planning. Resulting plans may require additional authorization, depending on the change model. This activity is orchestrated by the change coordinator or change manager. | The planning phase is minimized: smaller work size allows the delegation of planning to the development teams and reduces the time needed for this. |
| Change realization control | Planned changes to the resources are performed by internal and external specialist teams. These may include, among others: -software developers -infrastructure engineers -contract/supplier managers -testers -user support specialists. Manual and automated control actions are performed by the change manager or other agreed role(s). The change manager ensures that deviations are detected and corrected. | Planned changes to the resources are performed by internal and external specialist teams. Change realization control is almost fully automated, including: -validation and testing -configuration control and verification -asset control -version control -back up and restoration. |
| Change review and closure | After the change is complete, or if it fails to be completed in time, an agreed authority reviews the change. Among others, one or more of the following roles may be involved: change manager, service owner, change initiator, resource owner. The change can be formally closed before or after the review, depending on the change model. | Change review is not performed for individual changes unless they are unsuccessful according to the change realization control data. Changes are closed automatically after pre-agreed tests confirm they were successful. |
3.2.2 Change optimization
This process is focused on the continual improvement of the change enablement practice, change models, and standard change procedures. It is triggered by change reviews highlighting inefficiencies and other improvement opportunities or performed regularly depending on the effectiveness of the existing models and procedures.
This process includes the activities listed in Table 3.3 and transforms the inputs into outputs.
Table 3.3 Inputs, activities, and outputs of the change optimization process
| Key inputs | Activities | Key outputs |
|---|---|---|
| Change records Current change models and standard change procedures Policies and regulatory requirements Configuration information IT asset information Service catalogue SLAs with consumers and suppliers/partners Financial guidelines and constraints Risk information Capacity and performance information Continuity policies and plans | Change review analysis Change model improvement initiation Change model update communication | Change review analysis report Improvement initiatives Change requests Updated change models Updated standard change procedures |
Figure 3.3 shows a workflow diagram of the process. Table 3.4 provides examples of the process activities.
Table 3.4 Activities of the change optimization process
| Activity | Example |
|---|---|
| Change review analysis | The change manager, together with service owners and other relevant stakeholders, performs a review of selected (usually unsuccessful) changes over the period. They identify opportunities for change model and standard change procedures optimization, including standardization of new change types. |
| Change model improvement initiation | The change manager or change coordinator registers improvement initiatives to be processed with the involvement of the continual improvement practice or initiates a change request (if change models and procedures are included in the scope of the change enablement practice). |
| Change model update communication | If the change model is successfully updated, it is communicated to the relevant stakeholders. This is usually done by the change manager and/or the service or resource owner. |
Change enablement activities are performed by the service provider, as described in Tables 3.2 and 3.4. They may involve customers, suppliers, and partners. These activities are also supported (and sometimes fully or largely automated) by tools and technologies. All are described in the following sections.
4. Organizations and people
4.1 ROLES, COMPETENCIES, AND RESPONSIBILITIES
The practice guides do not describe the practice management roles such as practice owner, practice lead, or practice coach. They focus instead on the specialist roles that are specific to each practice. The structure and naming of each role may differ from organization to organization, so any roles defined in ITIL should not be treated as mandatory, or even recommended.
Remember, roles are not job titles. One person can take on multiple roles and one role can be assigned to multiple people.
Roles are described in the context of processes and activities. Each role is characterized with a competency profile based on the model shown in Table 4.1.
Table 4.1 Competency codes and profiles
| Competency code | Competency profile (activities and skills) |
|---|---|
| L | Leader Decision-making, delegating, overseeing other activities, providing incentives and motivation, and evaluating outcomes |
| А | Administrator Assigning and prioritizing tasks, record-keeping, ongoing reporting, and initiating basic improvements |
| C | Coordinator/communicator Coordinating multiple parties, maintaining communication between stakeholders, and running awareness campaigns |
| М | Methods and techniques expert Designing and implementing work techniques, documenting procedures, consulting on processes, work analysis, and continual improvement |
| Т | Technical expert Providing technical (IT) expertise and conducting expertise- based assignments |
Three practice-specific roles may be found in organizations: change manager, change coordinator and change authority. These roles are often introduced in organizations where the number of changes processed manually is high.
4.1.1 Change manager and change coordinator roles
The change manager is typically responsible for:
- the initial processing and verification of change requests
- allocating changes to appropriate teams for assessment and authorization, according to the change model
- formally communicating decisions of change authorities to affected parties
- monitoring and reviewing the activities of the teams that build and test changes
- publishing the change schedule and ensuring that it is available as needed
- conducting regular and ad hoc service review analyses; and initiating improvements to the practice, the change models, and the standard change procedures
- developing the organization’s expertise in the processes and methods of the change enablement practice.
In some cases, organizations introduce an additional role of change coordinator that has similar responsibilities but a more limited scope (specific types of changes, or territory, or part of the organization).
The competency profile for these roles is MTCLA, though the importance of each of these competencies varies from activity to activity. Examples of the roles which can be involved in change enablement activities are listed in Table 4.2, together with the associated competency profiles and required skills.
4.1.2 Change authority role
Changes require resources and introduce risks. This sometimes leads to organizations establishing complicated, and often bureaucratic, systems of change authorization, with formal committees that meet regularly to overview and authorize changes accumulated over the period. These are known as change advisory boards (CABs), and they often become bottlenecks for the organization’s value streams. They introduce delays and limit the throughput of the change enablement practice.
It is important to make sure that changes are authorized based on resource, cost, and priority considerations. This does not generally need to be a bureaucratic procedure. Change models should define the requirements and procedures for authorization, delegating the role of change authority to the appropriate level, such as development teams, technical experts, or service and product owners.
The change authority is responsible for the assessment and authorization of a change during its lifecycle (from initiation to completion). Depending on the change model, assessment and authorization may be done manually, automatically, or skipped for specific types of change.
4.1.3 Other roles involved in change enablement activities
Examples of other roles involved in change enablement activities are listed in Table 4.2.
Table 4.2 Examples of roles with responsibility for change enablement activities
| Activity | Responsible Roles | Competency Profile | Specific Skills |
|---|---|---|---|
| Change lifecycle management process | |||
| Change registration | Change coordinator Change manager Product development team Product owner Resource owner Service owner | TA | Understanding of change models and registration procedures |
| Change assessment | Change coordinator Change manager Product development team Product owner Resource owner Risk and compliance expert Service owner Technical expert | TC | Good knowledge of the products, including their architecture and configuration Business impact analysis Risk analysis |
| Change authorization | Change coordinator Change manager Customer representative | Good knowledge of the products, including their architecture and configuration Understanding of change models | |
| Product development team Product owner Resource owner Risk and compliance expert Service owner Technical expert | |||
| Change planning | Change coordinator Change manager Product development team Product owner Resource owner Service owner | TAC | Good knowledge of the products, including their architecture and configuration Understanding of change models |
| Change realization control | Change coordinator Change manager Product development team Product ownerResource owner Service owner | ATC | Good knowledge of the products, including their architecture and configuration Understanding of change models |
| Change review and closure | Change coordinator Change manager Customer representative Product development team Product ownerResource owner Risk and compliance expert Service ownerTechnical expert | TCA | Good knowledge of the products, including their architecture and configuration Understanding of change models Business impact analysis |
| Change planning | Change coordinator Change manager Product development team Product ownerResource owner Service owner | TAC | Good knowledge of the products, including their architecture and configuration Understanding of change models |
| Change realization control | Change coordinator Change manager Product development team Product ownerResource owner Service owner | ATC | Good knowledge of the products, including their architecture and configuration Understanding of change models |
| Change review and closure | Change coordinator Change manager Customer representative Product development team Product ownerResource owner Service owner | TCA | Good knowledge of the products, including their architecture and configuration Business impact analysis |
| Change optimization process | |||
| Change review analysis | Change coordinator Change manager Product development team Product ownerResource ownerRisk and compliance expert Service owner | TC | Good knowledge of the products, including their architecture and configuration Understanding of change models Business impact analysis Risk analysis |
| Change model improvement initiation | Change managerProduct development teamProduct ownerRisk and compliance expertService owner | TMA | Good knowledge of the products, including their architecture and configuration Understanding of change models Business impact analysis Risk analysis |
| Change model update communication | Change manager Product owner Service owner | CT | Understanding of change models Communication skills |
4.2 ORGANIZATIONAL STRUCTURES AND TEAMS
Although the change manager role may be associated with a formal job title, it is unusual to see dedicated organizational structures for the change enablement practice. Such structures are more likely to be found in organizations with a complex bureaucracy and where many changes are processed manually. In product-focused organizations, job titles and job roles are not typically adopted for this practice, because it is integrated with the day-to-day activities of product development teams and is automated wherever possible.
Formal teams for the practice may include a change authority team (such as a CAB) and temporary teams assigned for a specific change, especially if the change is treated as a project (see the project management practice guide for more details on project teams).
5. Information and technology
5.1 INFORMATION EXCHANGE
The effectiveness of the change enablement practice is based on the quality of the information used. This includes, but is not limited to, information about:
- customers and users
- services and their architecture and design
- partners and suppliers, including contract and SLA information on the services they provide
- policies and requirements which regulate service provision
- proposed changes
- expected benefits for the consumers and the organization
- user stories
- estimated time and cost of change realization
- regulations affecting the change
- lessons learned from similar changes in the past
- past and ongoing changes
- stakeholder satisfaction with the practice.
This information may take various forms. The key inputs and outputs of the change enablement practice are listed in section 3.
5.2 AUTOMATION AND TOOLING
In most cases, the work of the change enablement practice can significantly benefit from automation. Where this is possible and effective, it may involve the solutions outlined in Table 5.1.Table 5.1 Automation solutions for change enablement activities
| Process activity | Means of automation | Key functionality | Impact on the effectiveness of the practice |
|---|---|---|---|
| Change lifecycle management process | |||
| Change registration | Ticketing and workflow systems, backlog management tools, and Kanban boards | Enabling and controlling workflow for changes; prioritization of backlog and workflow management; workflow visualization | Very high, especially for large volumes of change |
| Change assessment | Ticketing and workflow systems, collaboration tools, and resource planning tools | Formalization and structuring of the assessment, providing more accurate and solid data for authorization | Medium to high, especially for processing complex changes manually |
| Change authorization | Ticketing and workflow systems and collaboration tools | Quick and traceable remote approval of changes | High, especially for delegated change authority of high velocity changes |
| Change planning | Change schedulers, project management tools, Kanban boards, and orchestration systems | Visualization of the planned and ongoing changes shared for all stakeholders; planning of automated standard changes | Very high, especially when many changes are being realized in parallel |
| Change realization control | Workflow management tools, collaboration and reporting tools, Kanban boards, andorchestration systems | Visualization and reporting for up-to- date views on the ongoing changes | Very high |
| Change review and closure | Collaboration tools, and ticketing and workflow systems | Remote review and discussions; traceable formal closure of changes | Medium to high, especially when regulations require traceable records |
| Change optimization process | |||
| Change review analysis | Collaboration systems, and analytical and reporting systems | Remote collaboration; change data analysis | Medium to high, especially for high volumes of changes |
| Change model improvement initiation | Ticketing and workflow systems, and backlog tools | Formal registration of the initiatives | Low to medium |
| Change model update communication | Communication systems and collaboration systems | Communicating updates to the affected teams | Medium to high, especially when the organization is large and tthe number of updates is high |
6. Partners and suppliers
Very few services are delivered using only an organization’s own resources. Most, if not all, depend on other services. These are often provided by third parties (see section 2.4 of ITIL® Foundation: ITIL 4 Edition for a model of a service relationship). Relationships and dependencies introduced by supporting services are described in the practice guides for service design, architecture management, and supplier management. Information about dependencies on third-party services is used in the change enablement practice at all steps of the change lifecycle management process. The information is also often used in the change optimization process.
Change models should define how third parties are involved in change realization and how the organization ensures the flow of changes. This depends on the architecture and design solutions for products, services, and value streams. The optimization of the change models supporting these solutions, however, involves the change enablement practice. Often, after the correct change model has been selected, further consideration of third- party dependencies is needed during change assessment, planning, authorization, realization control, and review. Where contracts with customers and vendors can impose constraints on changes, it may be useful to include standard changes and, in general, change models, into contracts together with clearly defined costs and approval procedures for any proposed changes.
Where organizations aim to ensure the fast and effective flow of changes, they usually try to agree to close cooperation with their partners and suppliers, removing formal bureaucratic barriers in communication, collaboration, and decision-making. All parties in such relationships should aim for mutual transparency and visibility of the changes that may affect the other parties (see the supplier management practice guide for more information).
7. Important reminder
Most of the content of the practice guides should be taken as a suggestion of areas that an organization might consider when establishing and nurturing their own practices. The practice guides are catalogues of topics that organizations might think about, not a list of answers. When using the practice guides, organizations should always follow the ITIL guiding principles:
- focus on value
- start where you are
- progress iteratively with feedback
- collaborate and promote visibility
- think and work holistically
- keep it simple and practical
- optimize and automate.
More information on the guiding principles and their application can be found in section 4.3 of ITIL Foundation: ITIL 4 Edition.®