Virginia Tech® home

Operational Change Management Practical Guide

1. Overview

This guide explains the intent of the Operational Change Management Standard in practical terms. It is designed to help IT professionals apply the standard effectively while maintaining system stability and reducing risk.

At a high level, the standard aims to:

  • Ensure every change is tracked

  • Match process rigor to risk level

  • Promote coordination and communication where needed

  • Maintain a reliable system of record for all changes

A useful mental model:

The higher the risk or impact of a change, the more structure and coordination it should require.

2. Change Categories

2.1. Routine Changes — Pre-approved, Repeatable Work

Intent

Routine Changes are meant to enable fast execution of low-risk, well-understood activities without repeated approvals.

When to Use

Use Routine Change when:

  • The change follows a repeatable, standardized procedure

  • Risk is low to moderate

  • Impact to users and systems is minimal

  • The procedure is already documented and approved

Examples include:

  • Scheduled patching

  • Service restarts

  • Routine maintenance scripts

How to Apply Effectively

Focus on building strong procedures:

  • Create clear, step-by-step documentation

  • Define who is authorized to execute the procedure

  • Include validation steps (health checks, logs, monitoring)

  • Test and validate the procedure before approval

Treat procedure approval as pre-approval for execution.

Best Practices

  • Automate procedures where possible

  • Include built-in validation steps

  • Periodically review and update procedures

Common Pitfalls

  • Using Routine Change for one-off or unique work

  • Skipping proper risk assessment of the procedure

  • Allowing procedures to become outdated

2.2. Normal Changes — Planned and Assessed Work

Intent

Normal Changes provide a structured process for managing changes that involve risk, planning, and coordination.

When to Use

Use Normal Change when:

  • The change is not urgent

  • It requires planning or coordination

  • There is meaningful risk or impact

Examples include:

  • Application deployments

  • Infrastructure updates

  • Database schema changes

How to Apply Effectively

  • Perform a Meaningful Risk Assessment

  • Scale Process to Risk

  • Plan for Failure

  • Use the Change Advisory Board (CAB)

  • Conduct Post-Implementation Review

The following sections provide guidance on each of these aspects of Normal Change planning.

Perform a Meaningful Risk Assessment

Evaluate:

  • User impact

  • Business impact if the change fails

  • Number of teams involved

  • Ability to test the change

  • Ability to back out the change

  • Timing, scheduling

The highest-risk factor determines overall risk.

Scale Process to Risk
Risk Level Guidance

Low

Lightweight planning and approval

Moderate

Clear documentation, defined ownership, stronger review

High

Full rigor including Change Advisory Board (CAB) involvement
Plan for Failure

A strong change plan includes:

  • Testing results or justification if testing is not possible

  • A documented back-out plan

  • Defined success criteria

  • Awareness of dependencies

Use the Change Advisory Board (CAB)

CAB exists to:

  • Coordinate changes

  • Avoid conflicts

  • Ensure proper communication

Bring changes to CAB when:

  • Multiple teams are involved

  • Impact is broad

  • Timing and coordination matter

Conduct Post-Implementation Review

After the change:

  • Document results

  • Identify unexpected outcomes

  • Perform root cause analysis if needed

  • Capture lessons learned

Common Pitfalls

  • Treating risk assessment as a formality

  • Not planning rollback

  • Failing to involve stakeholders early

  • Sending low-impact changes unnecessarily to CAB

2.3. Emergency Changes — Immediate Response

Intent

Emergency Changes allow rapid response to critical incidents or vulnerabilities while maintaining accountability.

When to Use

Use Emergency Change when:

  • There is a critical outage or service disruption

  • A security vulnerability must be addressed immediately

During the Emergency

  • Limit scope strictly to what is needed to resolve the issue

  • Focus on restoring service quickly

  • Involve key stakeholders if feasible without delaying action

  • Communicate when possible without slowing resolution

  • Use established incident communication channels

After the Emergency

  • Create a change record to document:

    • What happened

    • What was changed

    • Why it was necessary

  • Obtain posthoc approval or acknowledgment

Follow-Up Work

Use the Normal Change process for:

  • Cleanup work

  • Permanent fixes

  • Improvements

Common Pitfalls

  • Expanding scope beyond the immediate need

  • Failing to document the change afterward

  • Not transitioning to proper follow-up processes

3. Risk Assessment Guidance

Risk is determined by the highest-risk factor, not an average.

Key considerations:

  • User impact

  • Business impact if unsuccessful

  • Number of teams involved

  • Ability to test and validate

  • Ability to back out

  • Timing of the change

Practical insight:

If a change is difficult to test and difficult to roll back, it should be treated as high risk.

4. Change Records

Every change should be documented in a Change Management System.

4.1. What Good Records Include

  • Clear description of the change

  • Identified requestor and owner

  • Risk classification (for Normal Changes)

  • Supporting documentation:

    • Test results

    • Procedures

    • Back-out plans

    • Review notes

Think of the change record as both:

  • An audit trail

  • A knowledge base for future work

5. Change Advisory Board (CAB)

5.1. Purpose

CAB ensures changes are:

  • Coordinated across teams

  • Properly scheduled

  • Communicated to stakeholders

5.2. What CAB Does

  • Identifies conflicts between changes

  • Ensures visibility across IT units

  • Supports scheduling decisions

5.3. How to Use CAB Effectively

  • Submit high-impact or cross-team changes

  • Provide concise summaries

  • Clearly describe:

    • Risks

    • Dependencies

    • Timing

6. Role-Based Guidance

6.1. Engineers

  • Classify changes honestly based on risk

  • Develop reusable routine procedures

  • Always consider rollback strategy

6.2. Change Owners

  • Ensure risk assessments are meaningful

  • Align approvals with actual risk

  • Maintain clear documentation

6.3. System Owners / Managers

  • Define approved routine procedures

  • Establish who can execute them

  • Periodically review:

    • Procedures

    • Change outcomes

    • Failure patterns

7. Key Takeaway

This standard is designed to balance speed and control:

  • Enable fast execution for low-risk changes

  • Provide structure for higher-risk changes

  • Ensure visibility for impactful work

  • Maintain traceability for accountability

When applied effectively, the process should feel like:

Just enough structure to prevent surprises, without slowing down progress.