Change Management

The Change Approval Process (8 Steps)

Step 1

Submit Request Form

Complete the formal change control request with all required information. Standardizes input to the CCB.

↓

Step 2

Define Purpose

Document WHY the change is needed. What problem does it solve? What risk does it address?

↓

Step 3

Identify Scope

How many systems? Which departments? Single server or enterprise-wide? Defines the boundaries of the change.

↓

Step 4

Schedule Date & Time

Select a maintenance window that minimizes production impact. Consider shift schedules, seasonal freezes, dependencies.

↓

Step 5

Determine Affected Systems

Which systems, services, and integrations will be impacted? Include upstream and downstream dependencies.

↓

Step 6

Analyze Risk

Rate risk: High / Medium / Low. Document risks OF changing AND risks of NOT changing. Include backout plan.

↓

Step 7

CCB Approval

Change Control Board reviews and approves or denies. Must have all information above to make an informed decision.

↓

Step 8

End-User Acceptance

After the change, the owner verifies functionality. Users confirm systems work correctly before the window closes.

Ownership Model

Role	Who	Responsibilities	Does Technical Work?
Owner	Department needing the change (e.g., Shipping & Receiving)	Initiates request, manages process, receives updates, performs acceptance testing	No
Implementer	IT department / technical staff	Performs the actual installation, configuration, or modification	Yes
CCB	Change Control Board	Reviews, evaluates risk, approves or denies, records decisions	No
Stakeholders	Anyone affected by the change	Provide input, are notified of changes, may need to test their own systems	No

The Stakeholder Ripple Effect

A change that appears isolated almost never is. Example: upgrading shipping label software.

📦

Shipping & Receiving

Direct user of the software. Obvious stakeholder.

🧾

Accounting

Pulls shipping data for reports. Affected by data format changes.

🚚

Logistics

Uses delivery timeframes from shipment records.

💬

Customer Service

Uses tracking data that originates from label printing.

👔

CEO / Executive

Revenue recognition depends on confirmed shipments. Has visibility into fulfillment chain.

Sandbox vs. Production

Property	Sandbox	Production
Network connection	Isolated — no connection to real systems	Live — serves real users
Purpose	Safe testing of changes	Business operations
Risk of mistakes	None — mistakes are learning opportunities	High — mistakes affect users and revenue
Use for backout testing	Yes — validate rollback procedure here	Only if sandbox test confirmed it works
Data	Copy of production data (anonymized)	Real data

Maintenance Window Considerations

⛔

During Business Hours

Worst choice. Potential downtime affects maximum users and production. Avoid unless emergency.

🌙

Overnight

Best choice for most organizations. Low usage. IT staff can work without disrupting users.

📅

Weekends/Holidays

Good option — but verify 24/7 operations won't be impacted. Retail: avoid holiday season.

🔒

Change Freeze

Some periods allow NO changes. Retail: Thanksgiving–New Year. Critical infrastructure: during peak events.

Change Management: Visual Maps