Information Technology Services
Change Notice Policy

(March 31, 1997)

Change Notices

Quick jumps to:
EMERGENCY | MAJOR | SIGNIFICANT | MINOR | TRANSPARENT | FOLLOWUP

Purpose

The purpose of the Service Change Management Policy is to manage changes in a rational and predictable manner so that staff and clients can plan accordingly. Changes require serious forethought, careful monitoring, and followup evaluation to reduce negative impact and increase positive benefits.

Change Notice Responsibility

Each change is coordinated by the "owner" of the change. The owner is the person who has initiated or been assigned to manage the change and issue the Change Notice. Change Notices should convey who, what, when, where, why, and how in as simple a langua ge as possible. The owner is responsible and accountable for handling the change according to the policies set forth. The owner is expected to:

Planning and Scheduling

Proper timing of changes is essential to minimize negative effects on clients and co-workers. As a general rule, scheduling of major service changes and downtime should avoid periods of high use and high visibility (ie. while a semester is in session, during normal business hours, or while a major project is being conducted). Furthermore, changes should be scheduled when the resources necessary for post-change trouble-shooting and backout are available. For example, a software upgrade on Friday afternoon is inappropriate unless arrangements are made to have someone available over the weekend to resolve problems that may arise. Ownership of a change is not relinquished until post-change follow-up and evaluation are complete. It is the responsibility of the change owner to assess the benefits and drawbacks of the change and to adjust accordingly.

Change Classifications

The change owner is responsible for classifying the change into one of following five categories.

Category: EMERGENCY

Change to immediately restore service to clients.
Change to immediately fix an existing problem.

Notification and documentation are given as soon as possible after the change. In cases where ITS service outage is anticipated, immediate notification is required.

(Examples: Hardware or software failures which disable services.)

Category: MAJOR

Change has major impact on services and clients.
Change is highly visible.
First time this or similar change has been done.
Backout from change is difficult or impossible.
Change itself is complex and/or lengthy.

Notification to both external and internal clients required at least one month in advance of change date and periodically after change. Draft of notification must be reviewed by ITS / Services review group and senior management.

(Examples: removal of production hardware or software; the discontinuance of a service; a major network access change; a major service delivery change.)

Category: SIGNIFICANT

Change is significant to clients.
Change is visible to a large group of clients.
Backout from change may require significant effort.
Change itself is difficult, but not necessarily too involved.

Notification to both external and internal clients required at least two weeks in advance of change date and immediately following change. Draft of notification must be reviewed by ITS /Services review group.

(Examples: documentation changes; new versions or major enhancements of software offerings such as pine and SAS.)

Category: MINOR

Change has minor impact on clients.
Change is visible to small group of clients.
Change or similar change has been carried out successfully several times before.
Backout requires moderate effort.
Change itself is easy to enact.

Notification to both external and internal clients required at least one week in advance of change date and immediately following change.

(Examples: temporary hours of operation changes; login script changes.)

Category: TRANSPARENT

Change has negligible impact on clients.
Change is familiar or common to those implementing it.
Change is reliable and known to work.
Change is easy to back out if problems occur.

Notification required at the time of change (either immediately prior to change or immediately after change is made).

(Examples: modem exchanges; making software available for public to download; installing user-supplied but otherwise organizationally unsupported software on central systems.)

Category: FOLLOWUP

Provides additional information concerning an on-going problem or change.

Appendix A -- Change Notice Checklist

Pre-change preparation

Evaluate proposed change and effects of change.
Categorize change according to scale.
Schedule effective date of change.

Notification

If MAJOR change, send draft of notification to review group and senior management. Review suggestions. Send notice to 
"ITS_Changes@unc.edu".

If SIGNIFICANT change, send draft of notification to review group. Review suggestions. Send notice to

"ITS_Changes@unc.edu".

If MINOR, TRANSPARENT, FOLLOWUP or EMERGENCY change, send notice directly to

"ITS_Changes@unc.edu".

Effect the change according to the scheduled date.

Sample Notifications

The following is an example of a MINOR change notification. The one addition to the message would be indication of the category. The owner identification, submission date, effective date, change description, and possible effects are present. 
Date: Wed, 02 Feb 94 14:20 EST
To: ITS_Changes
From: Change Owner ID@NODE.OIT.UNC.EDU
Subject: MINOR: Notice of IBM Systems change on Wednesday Feb 9

Change Category: MINOR

On Wednesday morning 02/09/94, we will be putting into
production a change in the routing for TSO (MVS) mail.  On the
IBM mainframe, all outgoing mail from TSO (MVS) will be routed
via a new software process, SMTP.  This change will allow all
internet and local (UNC) mail to be routed directly instead of
passing it through VM.

The installation will occur during system test time (5:30 a.m.
- 8:00 a.m.) and the system will be available by 8:00 a.m.
 
The routing changes will be tested this week during normal test
time.

This change does not affect user procedures for mail nor does
it change any screen layouts.

Date: Wed, 09 Feb 94 08:16 EST
To: ITS_Changes
From: Change Owner ID@NODE.OIT.UNC.EDU
Subject: MINOR: Follow-up: IBM System Change for mail routing 

Change Category: MINOR

As previously posted, a change in the routing for IBM
mainframe TSO (MVS) mail went into effect this morning. All
outgoing internet mail from MVS is now routed directly through
SMTP on MVS instead of being passed to VM for routing.

Reminder:

This change does not affect user procedures for mail nor
does it change any screen layouts.
Return to Change Notices
Maintained by: Dan_Wingate@unc.edu.
URL: http://itschanges.unc.edu/change-policy.html
Last Updated: Friday, April 27, 2001