Change Request Types

Edit

Share

Add

Tools

Added by Simons, Thelma, last edited by Umscheid, Sherry on Jan 24, 2013

Types of Change Requests

Last updated October 2, 2012
Different types of change requests have been defined, based mainly on the impact the change will have. Will the change cause no outage,
will it disrupt a service for a few minutes during a low use time, or will it cause a critical service to be unavailable for several hours? The
answer to that question helps to determine what type of change is needed. The different types of changes, how they are determined, what
approvals are needed and how they should be communicated are detailed below.
Local Changes - no outage
Scheduled Recurring Changes - changes that happen on a regular basis (like backups, weekly reboots)
Scheduled Changes - may cause an outage within predefined maintenance window, request reviewed at weekly Change Review
Board (CRB) meeting
Extended Scheduled Changes - an attribute that can be applied to Scheduled Changes that extend beyond the predefined
maintenance window, request reviewed at weekly CRB meeting
Urgent Changes - service degraded, used when a change needs to be made before the next CRB review
Emergency Changes - service unavailable, fix now and file request later

Change Types
Local Changes
Scheduled Recurring Changes
Scheduled Changes
Extended Scheduled Changes
Urgent Change Requests
Emergency Changes

Local Changes
Local changes are changes that:
Have no projected downtime for any productional service.
Occur on test or dev systems
Are approved by the unit manager; and
Have minimal risk in causing a negative impact on users; and
Are properly documented and logged according to unit guidelines.
Examples:
Implementation of new web site for a department
Updates to web application written by Web Services
Changes to a view or field for financial office
PeopleSoft online and batch migrations
If a Local change results in a service or system outages, that change will be reviewed by the appropriate unit manager(s), Service Manager
and Change Manager to determine if similar changes need to be be filed as a different type in the future.
View Local Change Request flow chart.

Scheduled Recurring Changes

Scheduled Recurring and/or ongoing change requests are changes to live systems or services that
Are regularly (daily, weekly, monthly) scheduled events due to system/service maintenance, backup, or other external event
Have initial approval from the Change Review Board (CRB)
In order to qualify for a preapproved (ongoing) change, unit/service managers must
Submit a change request to the CRB that identifies the repetitive function and reason for the exemption request;
Identify the time period in which the change will regularly occur;

List back out or recovery steps that will be followed to prevent loss of service, and;
Identify any existing redundancy within the system or services affected.
Routine maintenance changes should be the exception and not the rule and any exceptions to the preapproved change request need to be
logged and communicated to the CRB. In other words, if a backup is not going to occur then it must be logged and communicated to the
CRB.
Scheduled Recurring (ongoing) changes must :
Have initial approval from the CRB;
Have all changes logged in a manner appropriate to unit guidelines;
Have a standard procedure to be followed and a standard execution time;
Describe any redundancy that occurs within the system or service approved for ongoing changes.
Examples:
Backups
Batch imports that occur on a scheduled basis
Daily, weekly or monthly therapeutic server reboots
Updates to router tables
View Scheduled Recurring Change Request flow chart.

Scheduled Changes
Scheduled changes are changes to production systems or services that
Fall within a predefined maintenance window (determined based on particular systems or services)
Will result in any interruption of service; or
Requires prior notification or communications to appropriate constituencies;
Examples:
Software/database upgrades
Applying non-critical system patches
New service implementations
Applying bundles and/or fixes to PS or other service
Implement PS module
New channels within the portal
Some system configuration changes
Building router/switch upgrades
The greatest number of changes requested should be Scheduled changes.
View Scheduled Change Request flow chart.

Extended Scheduled Changes

Extended Scheduled Change is not a separate type of Change Request. It is an attribute that can be applied to a Scheduled Change.
Extended Scheduled Changes are changes to production systems or identified test systems or services that:
Will result in any interruption of service;
Need be scheduled or extended outside of the normal maintenance window; or
Requires prior notification or communications to appropriate constituencies;
Extended Scheduled Change Requests must:
Be presented as part of the normal change management process with a request for an extended timeframe/implementation;
Be submitted to the CRB;

Urgent Change Requests

An Urgent Change Request should be filed only if:
Action is required before the normal CRB process would allow, and
Staff need to respond in a timely manner to resolve the problem because the lack of change will result in: degradation of services,

poor data integrity, or a security issue.

An Urgent request:
Must be approved by the unit manager, Service Owner, Service Manager and the Change Manager;
Should fall within a normal maintenance window if possible;
Urgent change communications should include:
Communications with appropriate staff or forums indicating that the problem is being addressed;
Communications with appropriate staff or forums concerning problem resolution and restoration of service; and
Communication status updates to the appropriate staff or forums if the outage is taking longer than expected.
When submitting Urgent Changes in Service Now an email will be sent to the Change Manager. If you want to talk with the Change
Manager, check the
Change Managers page to see who is currently serving in that role.
If during the Urgent Change Request the system fails to recover normally or requires additional changes to restore the service, contact the
NOC. NOC staff will notify the Service Owner, Service Manager, and others.
Examples:
Oracle connections are not releasing and system performance is degrading.
Applying a critical service pack
A server needs a reboot (but not immediately) to resolve identified problems.
View Urgent Change Request flow chart.

Emergency Changes
Emergency Changes are changes that
Require immediate action due to system or service failure
Will result in the interruption of any service as a part of the change process
Are implemented based on the professional judgment of staff managing production systems.
Emergency Changes:
Are approved by the unit manager prior to implementation if possible;
Are documented by the person implementing the change as a completed change request and submitted to the Change Review
Board for later review;
Are documented according to normal unit guidelines on what was done and how to back out the changes or restore the environment
to its original configuration by someone other than the person making the change;
Require that the Network Operations Center (NOC) be contacted. They will work with the Service Owner/Manager to determine if a
post-event notification about the service interruption needs to be sent to other IT groups, support groups, or clients about the service
interruption.
Emergency change requests are the exception and not the rule.
Examples:
A system is not responding and needs to be rebooted
A service is no longer accessible
View Emergency Change Request flow chart.
Like

Be the first to like this

chgmgt