Change Management Roles and Responsibilities: A Complete Guide

Change management is the structured process of guiding people, teams, and organizations from their current way of working to a new one. It focuses on the human side of change, such as reducing resistance, building adoption, and making sure improvements actually stick long after a project goes live. In IT, that process is formalized through defined roles and responsibilities. Knowing who owns what is the difference between a change that is effected cleanly versus one that creates chaos. Our expert in the following has a way of making that clarity concrete...

The ITIL Guru sat at his desk, looking over the latest additions in the Continuous Improvement Register (CIR). As a review board member, he liked what he saw. More and more IT staff contribute improvement ideas, making him feel good about the progress. The phone rang.

"ITIL Guru. How may I assist you today?"

"This is Michael. The CIO requested that I come to her office tomorrow. She wants me to take over the role of Change Manager. Her text does not appear clear about the new Change Enablement practice. Can you help me to make a good impression?"

"Michael, I am always happy to help explain ITIL.

Purpose of the Change Management (Enablement) Practice

"The purpose of the change practice has never deviated. It has always been to maximize the number of successful service and product changes by ensuring a risk assessment, authorizing changes to proceed, and managing the change schedule.¹

"The numbers show why understanding its roles matters. A WTW survey of 720 global organizations found that only one-third of respondents had effectively managed the risks associated with major work changes over the prior three years.

"Moreover, as you recall, in ITIL version 3, the practice (or process) name was Change Management. In January 2019, Axelos released ITIL 4. At this time, Axelos changed the practice name to Change Control. And then, in January 2020, Axelos again changed the name to Change Enablement. I do not see any ambivalence here, and I am happy to adopt Change Enablement as continuous improvement. Change Management never managed changes. That was left to Project Management. However, for the purpose of this explanation, we will continue to include the more common name of Change Management.

"Thank you for clearing up the name change. I want to make sure we follow ITIL's best practices in everything. Is Change Enablement responsible for business changes as well?"

"No. There is another practice for that. ITIL calls that practice Organizational Change Management. 'The purpose of Organizational Change Management is to ensure we implement changes in the organization smoothly and successfully, and that we manage the human aspects of the change.'²

Change Management Roles and Responsibilities Defined

The main roles in Change Management are:

• Change Manager

  Change Manager is the operational heart of the Change Enablement practice. They own the process end-to-end: evaluating and categorizing incoming change requests, chairing CAB meetings, maintaining the change schedule, and running Post-Implementation Reviews. The Change Manager is ultimately accountable for whether changes move through the system efficiently and without disruption to IT services.

  The Change Manager's responsibilities include:

  • Maintaining Change Management/Enablement system, including policies, processes, systems, metrics, and procedures used across the entire IT business and adheres to all regulatory requirements
  • Continuous improvement identifies opportunities for process, measurements, and systems to improve Enablement services' effectiveness and efficiency
  • Works closely and communicate effectively with users and stakeholders of the change process to drive the improvements
  • KPIs and metrics ensure service quality objectives, governance compliance, and responsiveness
  • Attends all CAB meetings
  • Ensures updates to Change Management/Enablement documentation
  • Provide information and reports on change implementations, successful and failed changes
  • Conduct Post Implementation Reviews (PIR) on successful and failed changes as required for continuous improvement

• Change Management Analyst

  Change Management Analyst handles the detailed assessment and documentation work that makes sound change decisions possible. Working closely with the Change Manager, the Analyst evaluates the risk and impact of each incoming change request, keeps records current, and ensures the right information reaches the CAB before every meeting.

  The Change Management Analyst's responsibilities include:

  • Register, categorize and prioritize changes after conducting a thorough analysis
  • Conduct risk analysis before submitting it for CAB approval
  • Maintain a balance between the business need for immediate change and the necessity of ensuring the stability of existing systems
  • Document and publish the CAB - MOM (Minutes of the Meetings)
  • Reroute misdirected changes promptly
  • Identify changes that need special attention or escalation
  • Draft and send out communications to ensure that all relevant stakeholders know procedures

• Change Advisory Board (CAB)

  The CAB is a cross-functional group that evaluates, reviews, and advises on Normal Changes. One important distinction worth knowing is that CAB stands for Change Advisory Board, not Change Approval Board. The CAB advises the Change Manager, who holds the final authority to approve or reject a change. CAB membership typically includes IT managers, technical leads, product owners, and business representatives, so the evaluation covers both technical risk and business impact.

  The CAB's responsibilities include:

  • Responsible for making decisions on whether or not the RFC would bring positive results, value to the organization, reduce manual efforts, and reduce costs.
  • Approve or reject changes based on:
    • The risk to IT services and business services
    • The impact of a difference on availability, performance, security, compliance, and SLAs
    • Provision of procedures
    • Test plans defined
    • Test results gathered
  • Discuss previously failed, rolled back, and backed out changes to understand what went wrong
  • Prepare for CAB meetings by circulating RFCs within their group and coordinating feedback
  • Review RFCs and recommend whether they should be authorized
  • Review successful and failed changes
  • Review unauthorized changes (i.e., changes without approved RFC)
  • Review the change schedule and help identify conflicts or resource issues
  • Review the Projected Service Outage (PSO) and provide feedback on the impact of planned outages

• Change Sponsor

  The Change Sponsor is typically a senior executive or department leader who owns the business case for the change. They are the most visible face of the initiative, and the person employees look to for signals about whether leadership is genuinely committed to seeing it through.

  The Change Sponsor's responsibilities include:

  • Defining the vision and business rationale for the change initiative
  • Securing the funding, staffing, and organizational resources needed to execute it
  • Communicating actively with staff and senior stakeholders to build and sustain momentum
  • Removing political or structural barriers that the Change Manager cannot unblock alone
  • Staying visibly involved throughout the transition, not just at the kickoff announcement

• Change Agents

  Change Agents are the day-to-day supporters of the change initiative. They are typically frontline managers, team leads, or department representatives who work directly with the people most affected by a transition. In ITIL terms, Change Agents often overlap with the stakeholder groups represented at CAB meetings. But the Change Agent role goes further than reviewing and approving change requests: they are actively helping people adapt once those changes go live. Think of them as the human network that runs alongside the formal approval process.

  Their responsibilities include:

  • Acting as the bridge between the project team and the employees going through the change
  • Facilitating local adoption by answering questions, addressing concerns, and coaching peers through new processes
  • Feeding real-time feedback back to the Change Manager about team morale, confusion points, and adoption blockers
  • Building enthusiasm and reducing resistance within their immediate teams

• Project Manager

  The Project Manager owns the technical delivery of the initiative: the timeline, milestones, budget, and scope of what is being built and deployed. In ITIL terms, once the CAB authorizes a Normal Change, the Project Management practice takes over execution.

  The key distinction from the Change Manager is that the Project Manager answers "Is the work done on time and within budget?" while the Change Manager answers "Will the people affected actually adopt it?" Both questions have to be answered yes for a Normal Change to succeed.

  The Project Manager's responsibilities in the context of Change Management include:

  • Owning the project timeline, milestones, and budget
  • Defining what is being built and when it gets deployed
  • Working in close coordination with the Change Manager to ensure technical deployment aligns with employee readiness
  • Ensuring the deliverable is handed over in a state that the operations team can support

  Here's a quick comparison:

  	Change Manager	Project Manager
  Primary Focus	People and adoption	Delivery and scope
  Success Metric	Adoption rate and behavior change	On-time, on-budget delivery
  Engaged Through	Post-Implementation Review (PIR)	Project go-live / handoff

• Human Resources (HR)

  HR teams are often overlooked in ITIL-focused change management conversations, but they are essential partners in any change that significantly affects how people do their jobs.

  In ITIL-specific IT change management, HR is less directly involved in the Change Enablement approval process. But they become a critical partner whenever a Normal Change has material impact on staff roles or ways of working. Change Enablement manages the change to the service, while HR manages the change to the people who deliver the service.

  In organizational change management, HR's responsibilities typically include:

  • Updating job descriptions, performance metrics, and compensation structures to reflect new processes or systems
  • Designing and coordinating training and development programs for affected staff
  • Supporting employee wellbeing during disruptive transitions, particularly for changes involving restructuring or significant workflow shifts
  • Ensuring the transition complies with employment agreements and relevant regulatory requirements

How to Use the RACI Matrix Model for Effective Change Management Roles and Responsibilities

"The RACI acronym stands for Responsible, Accountable, Consulted, and Informed. Use these to understand the various roles and responsibilities in effective Change Management/Enablement:"

RACI: A = Accountable, R = Responsible, C = Consulted, I = Informed

The Starting Point: The Change Manager Role in Change Management

The Change Manager's roles are:

1. To assign the correct Change Authority to each type of change
2. Enable the change to happen, and
3. Manage the change schedule."

"What you must know is there are three Change Types and three Change Authorities."

Three Change Types are the Key to Change Management Efficiency

"There are only three types of changes. That is all you need!"

1. Standard Change

   Characteristics:

   • Low risk
   • Pre-authorized
   • Well-understood
   • Fully documented (i.e. work instructions)
   • Implemented without needing additional authorization
   • Proven history of never causing an incident (optional)³

   "A Standard Change is my favorite. The change authority for Standard Changes is the Change Manager. The Change Manager determines what criteria they require to make a change a Standard Change. A best practice is to set an IT goal of eighty percent of all changes are standard changes. When meeting the CIO, ask her to make this the IT goal and make it 80% for every IT functional team."

   Why are Standard Changes the key to successful Change Management?

   The advantages of Standard Changes:

   1. With the majority of Changes Standard, it means less overhead for the Change Management/Enablement Practice allowing the Change Advisory Board (CAB) to concentrate on high-risk changes (Normal Changes)
   2. For the functional teams, no delays waiting for approval
   3. Increased speed of changes as proven and documented changes is more efficient
   4. Customer satisfaction improves when IT implements changes faster with no errors
   5. IT can execute service requests that change the live environment faster by linking a Request for (Standard) Change document to the service request
   6. Standard Changes are NOT on the change schedule since they do not impact the environment

   Examples of a Standard Change:

   • Life cycle replacement of devices
   • Replacement of a failing device with an identical model and configuration
   • Patching (when tested beforehand)
   • Application monthly/quarterly releases
   • Firewall changes (i.e., to block an IP to address security incident
   • New DNS entries
   • Restarting/rebooting in a high-availability environment
   • New hire onboarding

2. Emergency Change: Cange enablement's answer to a SWOT team

   "Emergency Changes are changes implemented as soon as possible.⁴"

   Characteristics of Emergency Changes:

   • Emergency changes are NOT on the change schedule
   • Expedited assessment and authorization assigned to the Emergency Change Advisory Board (ECAB) ensure speed
   • As far as possible, Emergency Changes should be subject to the same testing, assessment, and authorization as Normal Changes
   • There may be a separate change authority for Emergency Changes, typically including a small number of senior managers who understand the business risks involved⁵
   • A best practice is for the ECAB to identify the root cause of the Emergency Change. The objective is to reduce and eliminate Emergency Changes caused by not following procedures (i.e., skipped preventative maintenance)
   • A high-priority incident often requires an Emergency Change to restore normal operations as quickly as possible

   "The IT goal for Emergency Changes should be to a reduction in the frequency over time. With the direction of the CIO, each IT functional team should set a plan to reduce Emergency Changes."

3. Normal Change: Change Management/Enablement Approved for Execution by the Project Management Practice

   "With Standard Changes automated through Change Enablement because they are pre-approved, and Emergency Changes fast-tracked past the detailed scrutiny, Change Enablement can concentrate on Normal Changes.

   "The Change Advisory Board (CAB) is the change authority for all Normal Changes. The degree of scrutiny depends on the scope, risk, and priority. The Change Manager often chairs the CAB. 

   "Once authorized and scheduled, the Project Management practice executes all Normal Changes."

"As you can see, Michael, Change Management/Enablement efficiency is critical to keeping IT in alignment with business demands and opportunities. ITIL's term for this is Governance. Change is how the company continues to make continuous improvement happen. The more efficiently change occurs, the faster the organization improves.

I wish you well with the new position. I am sure you will have more questions. I am always here for you."