The Complete Guide to Maximizing IT Change Management for Continuous Improvement

Introduction to Change Management Process Flow

• Services
• Service components
• Practices
• Any element involved in the efficient and effective management of products/services

The Purpose of Change Management (Enablement)

ITIL Change Types & Definitions

• Practice — "A set of organizational resources designed for performing work or accomplishing an objective"⁴
• Practice Owner — The one person accountable for the Practice.
• Change Manager — One of many managers that lead project teams to make IT changes.
  Most IT departments have a general high-level role of IT Change Manager responsible for chairing the Change Advisory Board (CAB), they could be in this role permanently or on a rotating basis (it is very stressful).
  In a best practice matrix organization, every IT department (i.e., applications, infrastructure, desktop, etc.) would assign a member of their team the role of department Change Manager. In this role, they would be responsible to:
  • Ensure the department's compliance to the Practice standards set by the Change Management Practice Owner.
  • Coordinate with Change Managers in other departments.
  • Contribute feedback to the Practice Owner in support of Continuous Improvement.
  • Ensure proper documentation of change models and make sure everyone on the team follows these procedures. Change Models are documented work instructions on how to conduct a specific type of change with quality and efficiency. For example, how to on-board a new employee, how to install a patch or how to ready a new laptop, etc.
  • Encourage the development of Standard Changes (more on types of change later).
  • Motivate the department to reduce the frequency of Emergency Changes.
• Practitioner — The person doing the work. A single person usually takes on many roles. For example, they could resolve an incident, or work on Problem Management to find the root cause of an incident and then put on their Change cap to install the change that fixes the problem and the related incident(s).

Simplicity Is the Secret for a Strategic Change Management Practice

1. If using a Configuration Management System (CMS), it is only effective if it is 100% always correct all the time:
   • Most troubleshooting will look here to see if anything has changed.
   • Change Management uses the CMS to determine risks associated with a particular change.
   • The CMS is used by all other Practices during the design phase of Change Management.
   • Network monitoring tools use the CMS as their baseline. If there are unauthorized changes, alarms will sound.
2. Change Management governance keeps a Change Schedule for normal changes to ensure that there are no conflicts, and all changes accounted for.

Figure 1: Example of a Change Schedule

Change Management Process Flow Fundamentals: What To Change, What To Change To, and What Workflow To Cause the Change

Effective Change Management Starts With a Request for Change (RFC)

• Easy to create in a digital tracking system:
  • An incident Practitioner links an incident that requires a change to a system to resolve the incident to an RFC
  • A problem Practitioner links a problem/known error that needs a change to resolve the root cause of the problem to an RFC
  • A service request Practitioner links the service request to an RFC such as:
    • Request for a new laptop
    • Onboarding a new employee
    • Access to a service (e.g., cloud-based project management system or an accounting system)
  • A business executive board request for a modification to the company website starts this with an RFC
• Easy to link to a "reason" digital record
• Linked to the service associated with the change (e.g., purchasing application, digital hospital records, etc.):
  • The service name from your Service Catalog
  • This is all about service delivery, and there should be a service owner for every service. The service owner must know what their service incidents, requests, problems, known errors and changes are if they are to properly manage the service.
• Linked to the Configuration Item (CI) in your Configuration Management System (CMS)

Figure 2: Example of an RFC

The Three RFC Change Types Which Product Maximum Efficiency

1. Standard
2. Emergency
3. Normal

1. Low risk (i.e., do not create incidents)
2. Pre-authorized (by the IT Change Manager)
3. Well understood (trained people and procedures are in place to continually improve it)
4. Fully documented (product/service, work instructions documented and stored with knowledge management)
5. Ones that never causes incidents (if an incident occurs, you lose the Standard Change privilege and you must reapply to the Change Manager)

1. No waiting for the change approval by the Change Advisory Board (CAB)
2. Because of detailed documentation (e.g., work instructions) and trained staff, they do not create any incidents, thus reducing the workload
3. Increased customer satisfaction because of efficiency and professionalism
4. Reduced costs
5. To reduce clutter, Standard changes are not entered in the Change Schedule

1. A user makes a request to the Service Desk, either directly or via a Service Catalog site.
2. The Service Desk creates a predefined Standard Change request, which is pre-authorized, and fulfillment can start right away.
3. The work instructions are followed, and the request is completed.
4. The customer gets what they want and are happy.
5. The Service Desk documents the service request.
6. The Service Desk completes the Post Implementation Review (PIR), which is its contribution to Continuous Improvement.
7. The Service Desk closes the service request, which automatically closes the Standard Change and updates the Configuration Management System (CMS).

1. Emergency Changes could be initiated by:
   • Monitoring and event management tools
   • A user reporting an outage, fire, break-in, etc.
   • A vendor reporting a breach or eminent failure
   • The national Emergency Alert System (EMS)
2. Assessment and authorization are expedited by the Emergency Change Advisory Board (ECAB). The ECAB is a subset of the CAB.
3. IT and business key people start on remediation as quickly as possible. The response should be well documented and practiced.
4. An Emergency Change situation could involve other Practices for their emergency response ability:
   • Service Continuity Management
   • Problem Management
   • Service Configuration Management
   • Availability Management
   • Capacity and Performance Management
   • Security Management
5. Emergency Changes never go into the Change Schedule (i.e., because they are not scheduled. It is all hands-on deck immediately.)
6. When resolved, the PIR for Continuous Improvement should fully document the root cause, specifically, to find ways to prevent the Emergency Change in the first place (e.g., we did not follow the recommended maintenance schedule, we bought a product prone to failing or we use an unreliable provider, etc.).

Figure 3: Axelos (ITIL) Service Value Chain

1. Plan: To ensure a shared understanding of the vision. Everything begins and ends with the vision; do not start without it!
2. Improve: To ensure Continuous Improvement of products, services and Practices. Improvement suggestions come from everywhere. The Continuous Improvement Register (CIR) stores most improvement ideas. At the end of every project, the project manager conducts a Post Implementation Review (PIR) to gather improvement ideas.
3. Engage: To supply a good understanding of stakeholder needs, we ask for all stakeholders to contribute to the best solution.
4. Design & transition: To ensure products and services continually meet stakeholder expectations for quality, costs and time to market.
5. Obtain / build: To ensure that service components are available when and where they are needed.
6. Deliver & support: To ensure that services are delivered and supported according to agreed specifications and stakeholder expectations.

1. Assessment of Normal changes:
2. The Change Advisory Board (CAB) authorizes the change by following standard procedures.
   • Evaluating risks primarily using the Configuration Management System (CMS)
   • Considering inputs from all other Practices (e.g., Risk Management, Service Financial Management, Portfolio Management, Service Level Management, Business Change Management, etc.; see the Practice Dependency Table at the end of this whitepaper to see how dependent every Practice is on Change Management).
   • Group knowledge supplied by the different IT departments.
3. The CAB schedules and blocks time in the Change Schedule to avoid conflicts.
4. The Project Management Practice drives the project by following best practices such at Lean, DevOps and/or Agile.

• Project Management with inputs from all other ITIL Practices proactively gathers and evaluates business opportunities and demands and turns them into Value (products and services) using the Service Value Chain.
• Best practice says that this is done through one or more of the Project Management proven approaches such as Lean, DevOps or Agile.

• Customer (Service Consumer): Defines the requirements for a service and takes responsibility for the [business] outcomes of consumption. (e.g., Business department heads).
• User: The person that uses the service. They want the service to be fit-for-purpose (i.e., it lets them get their job done to meet their manager's expectations).
• Sponsor: This is the person(s) that authorize the budget for service consumption.
• Service Provider: Funding from the consumer; business development (i.e., for our purpose, IT).
• Service Owner: A role that is accountable for the delivery of a service. Best practice says that the service owner should be closest to the service. That means that in most cases, service owners exist within the business, and they have the greatest interest in service delivery and excellence.

Practice Dependency Table

Conclusion