CHANGE MANAGEMENT POLICY & PROCEDURES GUIDE
1. PURPOSE: Ensuring effective change management within the University’s production technology environment
is extremely important in ensuring quality delivery of Information Services. The intent of this Policy and
Procedures Guide is to ensure the effective management of change while reducing risk.
2. SCOPE: This policy applies to all production systems and the Information Services staff who manage them
including but not limited to all production data bases, servers, and application layers.
3. POLICY: Key components to the University’s Change Management program include:
a. Accurate Documentation: Identify the information relevant to a specific change that needs to be
collected throughout the change management process.
b. Continuous Oversight: Change Advisory Board (CAB) The CAB is tasked with balancing the need for
change with the need to minimize risks.
c. Formal, Defined Approval Process: All changes will follow the established multiple level approval process
to ensure routine changes are completed with minimum restrictions while complex, high impact changes
receive the oversight necessary to guarantee success.
d. Scope: Establish the specific areas that this policy will cover. Examples include Payroll and HR
Applications, Event management Applications, Accounting and Business Applications. Also included are all
changes associated with hardware and software changes (network, client server, SAN and Banner).
4. PROCESS: IS Change Management is the process of requesting, analyzing, approving, developing,
implementing, and reviewing a planned or unplanned change within the IS infrastructure. The Change
Management Process begins with the creation of a Change Request within the University’s selected
technology platform. It ends with the satisfactory implementation of the change and the communication of
the result of that change to all interested parties
The primary goal of the IS change management organization is to accomplish IS changes in the most efficient
manner while minimizing the business impact, costs, and risks. All IS changes within the University will be
documented in ServiceNow. To achieve this, the change management process includes the following primary
steps (note that all information collected in the steps below is documented in a Change Record created in
ServiceNow):
a. Formally Request a Change: All requests for change will be documented within ServiceNow by creating a
new request for change (RFC). The completion of a new RFC will be completed by the Change
Coordinator.
b. Categorize and Prioritize the Change: The Change Coordinator will assess the urgency and the impact of
the change on the infrastructure, end user productivity, and budget.
c. Analyze and Justify the Change: The Change Coordinator works with the change requester and the
change initiator to develop specific justification for the change and to identify how the change may
impact the infrastructure, business operations, and budget. The Change Coordinators use this information
to further research and develop a risk and impact analysis. When completing the analysis of the change,
the Change Coordinator must ensure they consider the business as well as the technical impacts and risks.
d. Testing and Roll-Back plans: The Change Coordinator works with the change requester and the
change initiator to develop a Roll-Back plan if the change is not successful, as well as a post
implementation testing plan.
e. Approve and Schedule the Change: The Change Coordinator uses ServiceNow to route the Request
for Change (RFC) to the Change Advisory Board (CAB) for approval or rejection of the change.
Emergency changes can be routed and approved by a Director level and above, thus bypassing the
CAB.
f. Plan and Complete the Implementation of the Change: This process includes developing the
technical requirements, reviewing the specific implementation steps and then completing the change
in a manner that will minimize impact on the infrastructure and end users.
g. Post-Implementation Review: A post-implementation review is conducted to ensure whether the
change has achieved the desired goals. Post-implementation actions include deciding to accept,
modify or back-out the change; contacting the end user to validate success; and finalizing the change
documentation within the company’s selected technology platform.
5. PROCESS SCOPE:
Because the Change Management Process deals with the management of changes in
the production
environment, it is imperative that both customers and the University’s change
organization understand the events that are considered within the scope of the process. In this section,
the scope is described and
includes areas which are both within and outside of the change management
process scope.
a.
In Scope:
The intended scope of the Change Management Process is to cover all the University’s
computing
systems and platforms. The primary functional components covered in the Change
Management process
include:
•
SDLC
– Changes handled through the formal software development life cycle will be included
within the company’s change management program.
•
Hardware
– Installation, modification, removal or relocation of computing equipment.
•
Software – Installation, Patches to non-redundant systems, Service Packs, upgrade
or removal of software products including operating
systems, access methods, commercial off-
the-shelf (COTS) packages, internally developed
packages and utilities.
•
Database – Changes to databases or files such as additions, reorganizations and major
maintenance.
•
Application –
Application changes being promoted to production as well as the integration of
new application systems and the removal of obsolete elements.
•
Moves, Adds, Changes and Deletes – Changes to system configuration.
•
Telephony –
Installation, modification, de-installation, or relocation of VoIP equipment and
services.
•
Networking –
Installation, modification, de-installation, or relocation of major network services
including Firewall and Router changes.
b. Out of Scope: There are many IS tasks performed at the University, either by the IS department or by
the end users that
do not fall under the policies and procedures of Change Management. Tasks that
require an operational
process, but are outside the initial scope of the universities Change Management
policy include:
• Contingency/Disaster Recovery
•
Changes to non-production elements or resources
•
Certain changes to redundant systems including moves, adds, deletes.
•
Changes made within the daily administrative process. Examples of daily administrative tasks are:
o Password resets
o User adds/deletes
o User modifications
o
Adding, deleting or revising security groups
o
Rebooting machines when there is no change to the configuration of the system
o File permission changes
o Security Patches
o Switch and Wi-Fi hardware swaps
NOTE: The Change Advisory Board (CAB) may modify the scope periodically to include items in the scope
of the University’s overall Change Management policy.
6. PROCEDURES:
a. Assigning the Change Priority:
The Change Management system has been designed to default to a
routine priority for the end user
community. The Change Coordinator will have authority to adjust the
priority level as required to meet
the business needs. There are four levels of Change priorities which
include:
•
Emergency
– A change that, if not implemented immediately, will leave the organization open to
significant risk (for example, applying a security patch, or a system down).
•
High
– A change that is important for the organization and must be implemented soon to prevent
a significant negative impact to the ability to conduct business.
•
Routine
– A change that will be implemented to gain benefit from the changed service.
• Low – A change that is not pressing but would be advantageous.
NOTE: Emergency changes must be kept to an absolute minimum due to the increased risk involved in
implementing them.
b.
Lead Time Guidelines:
It is essential that requests for change are submitted and approved in a timely
manner. This will allow completion of accurate documentation, change processing and obtaining the
approvals in sufficient time
prior to the requested implementation date, and provide for conflict
resolution for scheduling of
changes.
Lead times are the number of days an action (Initiation or Approval) must be completed prior to the
requested implementation date. The number of days may vary depending on the priority and the risk
level. Preferably, high risk and/or large change requests should have several weeks
(or even months)
notice prior to the requested implementation date. Lead Times for each change will vary depending on
the type of change. Change Initiators should plan lead times to allow sufficient time
for planning,
review, and approval. In some cases, lead times would also need to be planned to allow for
standard
implementation times that have been set for certain processes.
Determine need for
Production change
Is change SOP? Complete taskYES
Follow Deployment
Request process and
submit to CAB
NO
CAB Approves?NO
Communicate
Change
Deploy changes
Post implementation
review with CAB
YES
Need for follow-
up change?
Close ticket
NO
Is change an
Emergency?
YESNO
Follow Deployment
Request process and
submit to Director or
CIO
Mgmt.
Approves?
NOYES
Change Management Overview
10-18-2012
Joey Houck
Test and Validate
changes
Communicate Status
of Change to End
Users and Update
RFC in Zendesk
Pass
Collect Additional
Information as
Required
Collect Additional
Information as
Required
Change
Successful?
YES
NO
Perform Backout
Plan
Fail
Yes
Cancel Change
YES
Failed Change
c. Developing the Roll-Back Plan:
Development of the Roll-Back plan is essential to ensuring effective
recovery in the event of a failed
change. The Roll-Back plan is primarily based on the technical impact
analysis and the implementation
plan. A Roll-Back plan should be developed prior to submitting the
RFC.
d.
Developing the Testing Plan:
All change categories will undergo some level of testing depending on the
complexity of the change.
Once the change is built, configured and integrated in the development
environment, the change is
moved to the Test/QA environment. This phase focuses on conducting
testing and quality assurance to
ensure reliability and performance of all components of the
University’s technology infrastructure. The
Change Coordinator will oversee the testing function,
develop the test plan and report its findings back
to the CAB for voting on whether to advance the
change to production.
e. IS Business Unit Manager Review and Approval:
Following the submission of the new RFC, it will be
screened by the IS business unit manager who
determines whether to authorize or deny the change
based on the information in the RFC.
This screening process includes a reality check to ensure that the
RFC is appropriate, and to ensure the
request is complete. The manager can elect to approve, deny or
request additional information from the
change initiator. The Change Initiator is notified of the
progress of their request at all stages.
f.
Scheduling and Notifications:
The Change Coordinator establishes the appropriate schedule for the
implementation of the change. The
schedule is based on several factors including the change priority,
other changes being implemented, and
system availability. Once the schedule has been established the
Change Coordinator ensures the change
is noted on the consolidated change schedule and notifies all
interested parties of the pending change.
g.
Change Implementation:
The Change Implementer implements the change in accordance with the
implementation plan and during the scheduled time. This is generally a technical implementation.
Failure of an implementation at this
level will normally require the Change Implementer to follow the
Roll-Back plan to ensure normal system
operations. Significant changes within the environment that
require a major program development effort
will follow the guidelines established in the SDLC
document and established Customer Project
Management procedures. In general, these include the
following requirements which all change
implementations must follow:
•
Developing an implementation project plan
• Verify testing was successful
•
Applying the change to production
•
Validating the change in production
• Resolving problems caused by the change
•
Writing a summary of the results
•
Updating ServiceNow with results of the implementation
h. Testing, Validation, and Acceptance:
Once a change has been implemented, the IS Business unit
responsible for the change and end users who
will be using the change will conduct testing following
the test plan developed during the change
development phase. Accurate documentation and analysis
of any abnormalities is documented in the change record.
The Change Coordinator or the CAB designee will rate the change with one of the following ratings.
•
Acceptance
⎯
with no comments
•
Acceptance
⎯
with minor exceptions (note that these exceptions will either be fixed under the
current change or may require the creation of another new change)
•
Rejection
⎯
normally used only if the implemented change does not meet the required business
needs.
This results in a failed change determination and must be thoroughly reviewed to identify
the root
cause of the failure. This will normally result in the creation of a new change request.
i. Change Review and Acceptance:
Following a successful change implementation, a change review must
be conducted to determine if the
change resulted in the desired outcome. In most cases, this review
process might be very brief. For a
routine change, where the effect has been small and the results
relatively predictable, the review process
will be limited to checking that the change has provided the
user with the desired functionality.
j. Monitor Change in Production Environment:
To determine whether the deployed change has been
effective, it is necessary to monitor the
changes in the production environment. For a small change, this
may consist of checking on the desired
functionality. For larger changes, it might require the
monitoring of network and server information,
performance data, event logs, or response times.
k. Hold Post-Implementation Review:
The Change Coordinator is responsible for ensuring that a post-
implementation review is completed and
presented to the CAB. The findings of the post
implementation review are documented within ServiceNow. After sufficient information has been
gathered from
monitoring to determine the effectiveness of the change, a post-implementation
review is held during the next schedule CAB meeting.
In addition to making a success or failure decision on the change implementation, the review will also
consider how the change was deployed, and whether it was implemented on time. This
exercise will
result in the documentation of lessons learned from the change. Review feedback is then
distributed to
all parties involved in the change to encourage and enable future process improvements.
l. Change Advisory Board: The Change Advisory Board (CAB) is the change management decision-making
authority for the IS
organization. The primary responsibilities of the CAB are to:
• Establish and manage overall change management policies and provide guidance
•
Review and approve all pending requests for high-risk and high-impact changes
• Review completed changes and make recommendations for approval
•
Appoint people to key roles within the Change Management program
m. CAB Membership: The CAB is made up of individuals with stakeholder interest in the IS production
environment. Since RFCs
can impact any part of IS and any organizational group, the makeup of the CAB
reflects the focus of the particular RFC being reviewed. In general, the CAB is composed of individuals
who have a wide range of
expertise and are familiar with business requirements, the user community,
and IS system technology.
It is important to note that additional CAB members may be required according to the RFCs being
considered and if necessary, may include input from security, services, vendors and customer user
groups. The CAB Chairperson will make these decisions and notify resources if they need to attend the
regularly
scheduled CAB or an emergency session.
n. CAB Meetings:
The CAB is scheduled to hold an extensive meeting monthly with update meetings held
on a weekly basis
or as required. The monthly and weekly meetings will provide an overall review of the
technical and
business impact, prioritization, approval, and scheduling of pending RFCs. The monthly
meetings will also include review of the key change management reports, discussion on the change
management
program, and a review of any failed changes or changes requiring modifications during
the
implementation phase to ensure a successful change. A few days before each CAB meeting, the CAB
Chairperson will send out a meeting notification and agenda e-mail to all CAB members. The contents of
this e-mail include:
•
Date, time, and location (if relevant) of the meeting.
•
Format of the meeting. As an alternative to holding face-to-face meetings, CAB meetings may be
held using a conferencing software or by telephone conference calls.
• The reviewing order for RFCs (agenda). CAB members may be interested in only a small number
of
the proposed changes and might join the meeting only when necessary.
•
A link to all the RFCs being reviewed at the meeting and a forward schedule of the change
calendar
for discussion.
o. Voting Rules:
This section establishes the voting rules for RFCs requiring approval of the CAB. The
standard change
categories developed and included in the company’s selected technology platform
include a
recommended approval process. If the specific change being completed does not have
established
approval requirements, the CAB Manager will assign a minimum of two CAB members as the
approval
authorities for that change. These approval authorities are then added to the RFC
documentation in the change record.
7. ROLES AND RESPONSIBILITIES: Roles associated with the Change Management process are defined in the
context of the management
function and are not intended to correspond with organizational job titles.
Specific roles have been defined according to industry best practices. In some cases, many persons might
share a single role; and
in other cases, a single person may assume many roles. The significant roles defined
for the change management process are: Change Manager,
Change Initiator, Change Coordinator, Change
Task Assignee or Change Implementer.
Committees are also defined in terms of the roles they play and the responsibilities they have in the context
of the change management function. At a minimum, there are normally at least two committees
established: The Change Advisory Board (CAB) and the Change Advisory Board Emergency Committee,
which
typically have management responsibilities for the change management process.
a. Change Manager:
The Change Manager is responsible for managing the activities of the change
management process for
the IS organization. This individual focuses on the process more than on any
individual change.
However, the Change Manager is involved in every step of the process – from receipt
of an RFC to the
implementation of the change in the IS environment. The Change Manager is
ultimately responsible for
the successful implementation of any change to the IS environment. The
Change Manager’s responsibilities
include:
• Receiving RFCs and ensuring that they are properly recorded in ServiceNow.
• Selecting CAB members and facilitating CAB meetings.
•
Preparing CAB meeting agendas and providing all necessary review information to the CAB
members prior to the meetings.
• If necessary, assigning teams to conduct RFC impact analyses and risk assessments.
• Analyzing and prioritizing RFCs.
•
Categorizing, assigning change Coordinators, and scheduling RFCs, subject to approval by the
CAB.
•
Approving requests for minor changes or assigning approval authority to others.
•
Providing change notification to the Change Initiator and other affected parties.
•
Monitoring the successful completion of all RFCs, including the change development project
phases
and ensuring that these processes follow the change schedule.
• Reviewing and evaluating the change process.
b. Change Initiator: The Change Initiator (normally someone within the IS Business Unit) originates changes
by submitting a
Request for Change (RFC) to ServiceNow
. Everyone is authorized to initiate an RFC. The
Change Initiator is responsible for providing sufficient information on the change that the Change
Coordinator can complete the new change form. This person is notified whether the change was
approved and is kept up to date on the status of the RFC throughout the change process. The Change
Initiator assists the Change Manager and CAB in determining the RFC priority and, at the conclusion of
the change, participates in the post-implementation review.
c. Change Coordinator:
The Change Manager assigns (with the CAB’s approval) an individual to be the
Change Coordinator for a
change. Change Coordinators will be assigned to each IS business unit. The
Change
Coordinator is responsible for planning and coordinating all phases of the change from
initiation
through acceptance and documentation. The Change Coordinator will document all relevant
information in ServiceNow.
The Change Coordinator will routinely provide project status feedback to the Change Manager and
identify any problems as they arise. The Change Coordinator presents all formal updates and proposals
to the CAB after the CAB approves the RFC for passage through the various change implementation,
review and closure phases.
The Change Coordinator must work with the Change Initiator to ensure that the change meets the
Change Initiator’s requirements and that it successfully corrects any problems or provides the correct
system enhancements intended by the RFC. After implementing the change, the Change Coordinator
assists the Change Manager in evaluating the change process as it applies to the change. The
Change
Coordinator also coordinates and presents the post-implementation review analysis to the CAB.
d. Change Task Assignee or Change Implementer:
Change Task Assignees are responsible for executing
individual tasks within a change and ensuring they
are completed according to the implementation plan.
For example, the technician who performs the actual upgrade of the operating system would complete
the tasks associated with completing the
upgrade.
The Change Coordinator when developing the planning and implementation tasks will assign the
appropriate Change Task Assignee to perform the tasks required to plan and implement the change.
