Changes

A change record identifies the service affected by planned work. Its summary explains the intended action, risk helps reviewers prioritize scrutiny, and the scheduled start and end define the work window. The rollback plan gives the team a prepared response if installation creates trouble. These are the details the Change Manager and Service Owner need before approving work.

Draft work moves to Review when it is ready for a decision. The Change Manager reviews the window and rollback plan with the Service Owner, then records Approved or Rejected. Approved work can move to Implementing. After the attempt outcome is known, the reviewer can record Verified or rolled back for the change. The change state describes the service change decision; the attempt state describes what happened on an individual asset.

• Risk. The reviewer sees the declared change risk with the affected service.
• Window. Scheduled start and end make the planned timing explicit.
• Recovery. The rollback plan provides the operator with a prepared response.

Agree who may submit a change for review and who can approve it. Decide how service criticality affects the choice of window and who confirms that an asset belongs to the named service. Set a practical rule for writing rollback plans: a person reading the record during a disruption should understand the intended recovery action. Review access and approval boundaries before the first operating cycle.

Consider a patch with a high severity label for an asset supporting a critical service. The catalog severity tells the team about the release. The service criticality explains the business impact. The Change Manager examines both with the Service Owner and chooses a scheduled window. The Patch Operator then records asset-specific work in the attempt record. That sequence keeps the approval decision separate from installation evidence.

Prepare a draft change with a service, risk, start, end and rollback plan. Move it into Review and have the Change Manager make an explicit decision. For an approved case, open the Change schedule beside the patch attempt and compare planned and actual timing. For a rejected case, confirm the work stays out of the approved schedule. Run a rollback example and check that both the change and attempt outcomes tell a consistent story.

When a service interruption happens, the Incident Responder records the affected service and asset. The Change Manager can use that record in the after-action review, but the incident and the change remain distinct records. A change reaching Verified should reflect a reviewed result, not just the passage of the scheduled end date.

• Changes awaiting review — Read risk, schedule and rollback plan before the decision.
• Change schedule — Compare approved and implementing work by planned window.
• Change workboard — Follow the decision and implementation states for each service change.

Review a change and track the patch outcome.