Change Manager

Change manager is a role within IT service management responsible for coordinating and overseeing the day-to-day operation of the service-change process. The change manager helps ensure that proposed changes are classified, assessed, routed to the appropriate decision-makers, scheduled, communicated, documented, and reviewed in accordance with the organization's change enablement arrangements. The role connects technical teams, service owners, business stakeholders, and approving authorities so that changes can proceed with proportionate control and clear accountability.

In practical terms, a change manager is the person who keeps the organization's service-change controls working across many individual requests. The role checks that relevant evidence and reviews are available, coordinates competing changes, identifies unresolved dependencies, facilitates decisions, and follows up when implementation outcomes require attention. Its purpose is to make changes manageable, traceable, and timely, without imposing identical approval procedures on work with very different risks.

Managing the process does not automatically confer authority to approve every change. An organization may delegate specific approval rights to its change manager, or it may assign those rights to service owners, technical authorities, a Change Advisory Board (CAB), or other designated change authorities. Some published procedures combine coordination and authorization in one position; others deliberately separate them. The applicable authority is determined by the organization's governance model, not by the job title alone.

This entry addresses the ITSM change manager. A manager responsible for helping employees adopt organizational restructuring, new work practices, or transformation initiatives performs a related but distinct role within organizational change management.

Purpose and position in service management

The change manager provides operational coordination for change enablement, whose purpose is to support successful service and product changes through appropriate risk assessment, authorization, and scheduling. The role is especially relevant where one change may affect systems owned by several teams, conflict with another maintenance window, or expose a critical business service to disruption.

The position can be a dedicated full-time role in a large organization or an assigned responsibility in a smaller service-management team. It may be called IT change manager, change management manager, or another local title. A job description, a workflow-assignment field, and a formal delegation of authority are separate things: holding one does not necessarily establish the other.

A change manager typically operates within policies set by a change process owner or service-management governance body. The manager applies the agreed process, monitors exceptions and performance, and recommends changes to procedures when evidence shows that current arrangements cause avoidable delays or inadequate risk control. The process owner ordinarily has broader accountability for the design, resourcing, and strategic improvement of the practice.

Principal responsibilities

The precise combination of responsibilities varies by organization and operating model. Published university, government, and ITSM platform guidance describe a recurring set of duties: change intake and quality control, coordination of risk and scheduling, facilitation of authorization, oversight of progress, and review of outcomes.

Review and classification

For changes that require individual review, the manager checks whether the change request identifies the intended work, affected services, business purpose, risk, dependencies, test evidence, proposed timing, and recovery arrangements. Incomplete requests can be returned for clarification before they consume an approver's attention. Classification helps place a change on the appropriate standard, normal, or emergency pathway; the manager may confirm or challenge the classification when authorized to do so.

Technical experts and service owners remain responsible for producing accurate specialist assessments. The change manager's review is an assurance and coordination activity; it is not a substitute for detailed engineering, cybersecurity, or business-risk analysis.

Authorization coordination

The manager identifies the correct approving authority under the organization's risk and delegation rules, gathers recommendations, and tracks whether the required decision has been recorded. For changes referred to the CAB, the manager may organize the agenda, arrange relevant participation, facilitate discussion, communicate the decision, and track conditions attached to approval. An approval should identify who authorized what, when, and under which limits. Where the manager has delegated decision rights, those rights should be documented separately from the responsibility to coordinate the review.

Scheduling and communication

Changes that look acceptable in isolation can create material risk when scheduled together. The change manager therefore reviews the change schedule for collisions, restricted periods, shared dependencies, resource constraints, and business events. The manager also ensures that affected operational teams and stakeholders receive appropriate notice, including what may be unavailable, when the work will occur, and whom to contact if it does not proceed as expected.

Progress, exceptions, and closure

During implementation, the manager follows significant deviations, escalations, cancellations, and unresolved dependencies. Implementation work normally remains with the assigned technical team. After implementation, the manager helps ensure that outcomes are verified, the change record is complete, and a post-implementation review takes place where risk, failure, or policy requires it. Recurring problems in change quality, authorization, or scheduling become inputs to improvement of the service-change process.

Authority and accountability

The authority assigned to a change manager is one of the most important local design choices. Coordination duties may be broad while the power to accept service risk is narrowly delegated. Conversely, in some organizations the same individual chairs the CAB and formally authorizes a category of changes. Stanford University's published role model gives change managers authorization responsibilities, while Virginia Tech explicitly ties certain higher-risk approvals to the change manager representing CAB consensus. The IRS describes a separate change authority and change approver alongside the change manager.

Activity	Typical change manager role	Decision-right boundary
Check a request for completeness	Review the submitted evidence and return it for clarification when necessary	Completeness review does not itself approve implementation
Assess business or technical risk	Ensure qualified assessors contribute and significant concerns are recorded	The risk owner, service owner, or delegated specialist must accept risks within their remit
Convene a CAB	Arrange review, clarify questions, document recommendations, and follow up on conditions	A CAB approves only where formally authorized; advice is otherwise separate from approval
Authorize a proposed change	Act as the decision-maker only for classes and risk levels explicitly assigned to the role	Higher-risk or out-of-scope decisions go to the designated change authority
Execute the change	Coordinate timing, readiness, escalation, and follow-up	Implementers perform and verify assigned work
Close the record	Ensure required results, incidents, exceptions, and reviews are captured	Closure does not erase failed controls or outstanding corrective actions

The distinction matters for auditability and separation of duties. A person who prepares a change can also have a coordination role, especially in a small team, but the organization should address whether independent scrutiny is required for material risk. Automated authorizations should be traceable to an approved policy or delegated authority rather than treated as an unaccountable system decision.

Relationship to adjacent roles

A change manager is part of a wider operating arrangement. These roles can overlap in one person, but their accountabilities are not interchangeable.

Related role or body	Primary contribution	Difference from a change manager
Change process owner	Establishes and maintains the overall practice, policy direction, resourcing, and improvement accountability	Owns process design and institutional accountability rather than only day-to-day execution
Change Authority	Authorizes or rejects a change within expressly assigned limits	Has a decision right that the change manager may or may not also possess
Change Advisory Board	Provides cross-functional advice or an authorized collective decision on consequential changes	Is a group or review forum rather than the role that coordinates the process
Emergency Change Advisory Board	Provides urgent review or authorization for qualifying emergency changes	Is convened for time-sensitive decisions, not routine change-process operation
Change Coordinator	Coordinates the progression or implementation of particular changes across teams	Usually has a narrower delivery or individual-change focus, although titles can overlap
Change Owner	Is accountable for the intended outcome or a specific change affecting an owned service or system	Owns the particular change or system, not necessarily the organization-wide change process
Service Owner	Represents the lifecycle, quality, and business consequences of an IT service	Supplies service-specific impact and risk judgment
Technical implementer	Builds, tests, deploys, and verifies the authorized modification	Performs the technical work rather than managing the overall change-control process

EDUCAUSE distinguishes change managers, coordinators, implementers, requesters, and authorities as roles that may be allocated differently in faster-moving DevOps environments. These are operating responsibilities, not a mandatory set of separate job titles.

How the role operates across a change

A normal change affecting several services shows the manager's coordinating function most clearly. A requester proposes a change and records the reason, timing, affected services, and expected result. Qualified teams assess the consequences for operations, security, dependencies, customers, and recovery. The change manager checks that the evidence is complete enough for the assigned authority to make an informed decision and brings together reviewers when collective judgment is needed.

Following authorization, the manager reconciles the implementation date with other planned work and confirms communications and handoffs. The technical team implements the approved change and captures what occurred. The manager then checks for incomplete records, implementation deviations, and any required outcome review. This sequence describes the role's interfaces; the detailed sequence and approvals are governed by the organization's change models and process definitions rather than a single universal workflow.

For a change that is already pre-authorized under an approved standard procedure, the manager's work can be much lighter. The relevant controls may be reviewed periodically instead of convening a committee for each repetition. For high-impact changes, the manager may have to coordinate multiple specialized reviewers, business representatives, and a restricted implementation window. The intensity of oversight should follow the risk and service consequences, not the status of the requester.

Responsibilities for different change types

Change type	Typical change manager involvement	Important limit
Standard Change	Oversees the integrity of pre-authorized procedures, eligibility criteria, exceptions, and periodic review	The manager need not separately approve every compliant instance of a genuinely pre-authorized change
Normal Change	Ensures complete assessment, proportionate authorization, conflict checks, communication, and closure evidence	The approval level depends on delegated authority and actual risk
Emergency Change	Facilitates rapid evidence gathering, contact with emergency approvers, expedited records, and follow-up review	Urgency does not automatically give the change manager unlimited authority to approve risky work

Published operating models differ. An emergency may be authorized by a designated emergency authority, an ECAB, or an individual official; the manager's job is to make the permitted route work quickly and visibly. An unplanned change should not be labeled an emergency simply because the requester missed an ordinary deadline.

Illustrative example

A university schedules a database platform upgrade that supports student registration, payroll, and a reporting application. The database team owns the technical work and proposes a normal change with a test plan, expected downtime, and recovery steps. Three service owners identify different business restrictions: registration has a peak enrollment period, payroll has a processing deadline, and reporting depends on the database's replication feed.

The change manager checks that those dependencies appear in the change record, coordinates the assessors, brings the conflicting schedules to the relevant review forum, and ensures the approving authority receives the revised plan. After an authorized maintenance window is agreed, the manager confirms communications and service-desk preparedness. The database team executes the change, performs technical verification, and records the result; service owners confirm that their critical functions are usable. The manager ensures that any failed check or deviation is captured for review.

The manager does not thereby become the database engineer, payroll owner, or sole authority to accept enterprise risk. The role's practical value lies in connecting those responsibilities and ensuring the governance decisions are made on a coherent set of facts.

Records and evidence

A change manager works with records produced by several participants rather than creating every item personally. Typical evidence includes the approved request for change, assigned owner, risk and dependency assessments, authorization outcome, deployment and recovery arrangements, schedule, implementation logs, outcome verification, and any post-implementation review. The change record may collect these in one electronic case or maintain links to evidence retained in delivery tools.

A strong record allows a reviewer to reconstruct the approved scope, relevant decision-maker, execution conditions, actual result, and exceptions. Recording approval after implementation without a valid emergency procedure is materially different from capturing an authorized expedited decision. Likewise, a closed ticket without a verified outcome may show administrative completion but not service-change success.

Change managers in automated delivery environments

Modern delivery pipelines can automate routine evidence collection, tests, policy checks, release scheduling, and authorization within prescribed conditions. This shifts the manager's attention toward exceptions, policy clarity, high-consequence dependencies, and evidence that automated controls remain effective. A manager need not be the manual gateway for every low-risk software deployment. What matters is that the change pathway has a legitimate authority, reliable controls, and usable records.

Enterprise ITSM products may grant a user called change manager extensive configuration and approval permissions. For example, ServiceNow's documented simplified change-management configuration permits that software role to manage CAB activity and approve changes. Platform access rights, however, are a vendor-specific implementation detail: they should be aligned with the organization's approved delegation and separation-of-duties design rather than mistaken for a universal professional mandate.

Effectiveness and common failure patterns

Change-management performance should be judged using a combination of service outcomes, throughput, evidence quality, and review effectiveness. A single target, such as the percentage of requests approved, can reward the wrong behavior when viewed in isolation.

Indicator	What it can reveal	Interpretation caution
Time spent waiting for authorization	Unnecessary queues or unclear delegated decision paths	Separate standard, normal, and emergency pathways and account for risk
Changes associated with service incidents	Possible gaps in assessment, testing, coordination, or implementation	Establish credible attribution and service criticality before drawing conclusions
Completeness of authorization and outcome records	Whether decisions and execution can be reconstructed	A complete record does not prove that a decision was technically sound
Schedule conflicts and late rescheduling	Weak cross-team visibility or insufficient dependency analysis	Some conflicts are unavoidable responses to urgent business events
Emergency change frequency and justification	Genuine urgent demand or misuse of the emergency route	Compare reasons, change volume, and risk; a rising rate is not automatically a failure
Findings from post-implementation reviews	Whether failures produce practical improvements to controls and procedures	Count completed corrective actions, not merely meetings held

Common weaknesses include treating CAB attendance as the primary measure of control, routing every change through the same approval queue, accepting risk without a documented mandate, and closing changes before their outcomes are checked. The opposite problem is equally serious: devolving all changes to engineering teams without clear authorization conditions or shared-service dependency checks. Effective management makes the decision path proportionate, transparent, and capable of learning from outcomes.

Distinction from organizational change management

In organizational transformation, change manager commonly means a specialist who prepares employees and stakeholders for new processes, systems, roles, or behaviors. The work may include sponsorship, communication, training, readiness assessment, and adoption support. By contrast, the ITSM change manager focuses on service-change governance: readiness for technical change, authority, timing, risk, recordkeeping, and operational outcomes. The same initiative can require both roles, especially when a new platform changes how employees work.

The distinction concerns what is being managed. Managing a production change to an identity platform requires authorization, system safeguards, and service verification. Helping employees adopt a new sign-in method requires communication and learning support. A single person may coordinate both streams, but the evidence of technical control and the evidence of user adoption should remain distinct.

See also

• Change Enablement
• Change Authority
• Change Advisory Board
• Emergency Change Advisory Board
• Change Management Process Owner
• Change Coordinator
• Change Owner
• Change Record
• Change Model
• Organizational Change Management