What is VUIT’s Change Process?

It is based on the Information

Technology Infrastructure
Library (ITIL) and adapted to
address VUIT’s specific
requirements such as scope,
types of changes, roles and
responsibilities, and lead
times, just to name a few.
Objectives
The specific objectives of Change Management at VUIT are:
1. Establish a standard process and tool for managing changes

2. Ultimately, provide good, stable service to the users

3. Right-size the approval process based on the level of risk

4. Improve communications regarding changes

5. Provide greater visibility into the Change Calendar

Scope
The Change Management process will begin when the business requests the change.
Requesting a change early promotes better governance, prioritization, and planning of
work while increasing Change Calendar visibility.

The following types of changes are in-scope of the Change Management process:
1. Production: All hardware, operating system and software changes to data center and network
infrastructure. Any shared changes with MCIT will stay in Pegasus and use that Change
Management process.
2. Non-Production: All infrastructure including hardware (excluding applications) in a development,
test or pre-prod environment. This includes anything that is shared by other teams or
workgroups. (There is no non-production network equipment so any network changes will be
considered production)
3. Changes under VUIT control with cloud service providers.
4. All changes to enterprise applications.
5. Informational changes driven by vendors or third parties
The following types of changes are out-of-scope:

• Individual desktop/laptop changes.

• Service requests including access request.
• Lab equipment that does not impact anyone other than those supporting it
• Break/fix situation where you are restoring it back to a normal state. This is
handled within the Incident Management process.
Types of Changes
Type of Change Description
Standard Change Low risk, frequently occurring (formally a PAC)

Normal Change Follows normal process flow; further categorized into high, medium, or low risk. Requires approval
from Change Manager or Change Advisory Board (CAB).
Fast Track change – submitted as a normal change but must be expedited for:
• Financial or legal reasons
• Vanderbilt reputation
• A critical vulnerability
Emergency Change Resolving an outage or a pending outage or to address a regulatory security issue. Must be
approved by the Director either verbally or via email or text. Must be associated with an Incident.
Recorded after the Incident is resolved.
Informational Change Promoted by a vendor or third-party that is being recorded to aid with communication, e.g.
Change Calendar.
Non-Production Performed against development, test, or pre-prod CI infrastructure. All non-production changes
will go in as an Informational Change (with Non-Prod box checked on change form).
Change Management Process
Risk Table
Normal changes are further categorized into high, medium, or low risk. To determine the risk level,
refer to the following Risk Questionnaire.
Score 1 2 4
Question
Number of users impacted Single user, team or Multiple users, teams or All users in the organization
department departments
Criticality of the service to the If an outage occurs, core If an outage occurs, core Business critical, i.e. outage
business business processes can business processes cannot be results in direct loss of
continue. performed. revenue, direct impact on • Low Risk: < 5
brand because business VUIT
uses the IT service, direct • Medium Risk: 5 to 10
exposure to fines due to being • High Risk: > 10
out of compliance, etc.

Number of teams involved Implementation activities are Multiple teams in the same Multiple teams in different
with implementation limited to a single IT team. department within IT need to departments within IT need to
coordinate activities coordinate activities

Can it be tested? Can it be Can be tested and backed out Either cannot be tested or Cannot be tested nor backed
backed out? easily. cannot be backed out easily. out easily.
Lead Time
Type of Change Lead Time - Submission to Approval process
Approval
Standard Change Same day
Normal – Low Risk 1 business day • Change Owner Manager approves online.
• For Low Risk changes only, approval by the Change Owner Manager will allow the Change to move forward to
be built.
• Once built, the Change will go the Change Manager for Deployment approval.

Normal – Medium Risk 1 week (calendar days) • A Technical Review is necessary. The need for an Architectural Review process will be determined and
flagged within the TRB process activity. Approval to move forward is done on-line.
• The Change Owner Manager approves on-line to build the change.
• Once built, the Change Manager provides Deployment approval.
• If scheduled for outside the normal maintenance window, Relationship Managers will seek customer
approval.

Normal – High Risk 2 weeks (calendar days) • Technical Review is tracked online.
• The Change must be discussed at a CAB meeting at least 2 weeks before implementation.
• The Change Owner Manager will approve to build the change.
• Once tested the Change will go to CAB for Deployment approval.
• If scheduled for outside the normal maintenance window, Relationship Managers will seek customer
approval.

Normal – Fast Track Less than required lead time • Technical Review as required above for Medium or High risk changes.
based on risk • Have a High or Urgent Priority, and have the Fast Track box checked.
• Must go to eCAB for Deployment approval.
Emergency Change N/A • Verbal/email/text approval by a Director.
• The Director will consult / inform other stakeholders as they deem necessary.
• The Change record is created after the fact.
Change Prioritization and Fast Track Changes
The Priority of the change is determined by the
following matrix:

Impact
University-wide Small Group / Individual
VIP
Urgency Work is blocked Urgent Urgent High
Work is degraded or High High Normal
potentially degraded
Work is unaffected Normal Low Low

Fast Track (expedited) changes are Urgent or High

priority and the lead time requirement for the change
does not apply. Fast Track box MUST be checked for this
process and must meet justification requirements.
Process Flow
In the next several slides, the process flows for the following types of changes are
illustrated:
• Normal Changes – which are further categorized into Low, Medium and High Risk as
well as Fast Track
• Emergency Changes
The process flows use “swim-lane diagrams” to illustrate which role is responsible for the
activity.
 Process Flow – Normal Change
Normal Change – Page 1

Architecture Review
Change Requester Change Owner Change Owner Manager Technical Reviewers Change Manager Relationship Manager
Board

Start

No No

Start Change Finalize Change

Proposal Proposal Assess and Approve Assess and Approve
Yes
Online Online
No

Yes

Risk Level?
ARB Review
Yes Assess and Approve
Necessary?
Medium/High

Low

Yes
No

Schedule
Change

No

Outside
Does Customer
Maintenance Med/High=Yes
Approve?
Window?
Low or Med/High=No
Yes
Page 2
Process Flow – Normal Change
Normal Change – Page 2

Change Manager Change Owner Manager Change Owner CAB/eCAB

Page 1

Approved to
Low/Medium Schedule Approved High
Build/Test?

Approved to
Build/Test? Move to New
(rework) or No
Cancelled

Yes
Yes

No Build Change
No

Approved to Approved to
Low/Medium High
Implement? Implement?

Yes Yes
Deploy Change &
Update Change
Record

Change
Working?

Yes No

Back-out
Change? No

Yes

Execute Back-out
Plan. Communicate
appropriately.

Post
Implementation
Review (PIR)

Close Record
 Process Flow – Emergency Change
Emergency Change

Change Requester Director Change Owner Change Manager

Start

Resolving an
Yes Approved? Yes Build and Deploy
Incident?

No

Change
Follow Normal
Working?
Change Process Yes
No

Back-out
Change?

Yes

Execute Back-out
Plan. Communicate
appropriately.

Submit Change
Request

Post
Inform CAB at next
Implementation
CAB Meeting
Review (PIR)

Close Record
 Roles and Responsibilities
Change Requester
The Change Requester is usually an IT staff member. Their responsibilities include:
1. Starts the Change Record by entering the Change Type, Title, Description and Priority and then assigns to the Change Owner or Change
Owner Team
2. Communicates status of the change back to the business
Change Owner
The Change Owner’s responsibilities include:
1. Complete the information in the Change Record
2. Keep the Change Requester informed about the progress of the Change
3. If there is more than one team involved with the implementation, coordinate the efforts across the teams
4. Build the change; document the Implementation Plan, Verification Plan and Back-out Plan
5. Deploy the change during the time scheduled, indicating in the change record when the work started and finished in actual time so
notifications can automatically be sent
6. Execute the Back out Plan if required
7. Conduct the Post Implementation Review (PIR), if required by the PIR policy
8. Represent their changes (or send a designate) at CAB/eCAB
Change Owner Manager
The responsibilities of the Change Owner Manager are:
1. Review and approve change requests submitted by their subordinates in a timely manner, acting as the technical review for Normal – Low
Risk changes
2. Responsible for Build Approvals on Low and Medium Risk changes in a timely manner
3. Propose improvements to the Change Management process to the Change Manager
 Roles and Responsibilities

Change Manager
The Change Manager’s responsibilities include:
1. Validate the type and risk of the Change
2. Escalate approval delay issues
3. Chair the CAB and eCAB meetings
4. Provide Deployment approval for Low and Medium Risk Changes
5. Ensure Post-Implementation Reviews (PIRs) are conducted per the policy
6. If an unauthorized change is discovered, escalate to IT Senior Management
7. Report on Change Management activities
8. Educate IT staff on the Change Management process
9. Propose and implement improvements to the Change Management process
 Roles and Responsibilities
CAB/ECAB Member
The CAB is the Change Advisory Board. eCAB is the Change Advisory Board for expedited (Fast Track) changes. Please refer to
“CAB/eCAB Members and CAB/eCAB Meetings” section for a list of mandatory members that should make up the CABs. The
CAB/eCAB Member’s responsibilities include:
1. Responsible for Build Approval and Deployment Approval on High Risk changes
2. Represent their team at CAB meetings
3. Review changes prior to the meeting
4. Communicate when a change will impact their area. If they do not approve a change, explain why.
5. Attend or send a knowledgeable representative to CAB meetings
6. Communicate back to their team
Technical Reviewers and Architectural Reviewers
The Technical Reviewer and Architectural Reviewer should have a deep understanding of the technology and analyze the
technical feasibility and impact.
1. Provide online approvals for Technical Review in a timely manner.
2. Identify other Technical Reviewers that need to be consulted, and determine if the Architecture Review Board
should be engaged.
Relationship Manager
The responsibilities of the Relationship Manager
1. Secure business approval for Normal – Medium Risk and Normal – High Risk changes that will occur outside of
normal change windows.
Change Management Policies
1. All Changes, that are defined as in-scope, must follow the Change Management process and must
be recorded in Cherwell.
2. The Change Manager will maintain the change freeze periods on the Change Calendar. If a change
must occur within the freeze period, it must be approved by a Director.

3. Emergency changes can only be used for incidents that have caused or could cause an outage or significant degradation, or for regulatory
compliance issues. The Emergency Change must be linked to the Incident.
4. Fast Track changes can only be done if the change has a priority of Urgent or High. Fast track changes do not need to conform to the
outlined lead time for approvals (e.g. a normal change that is fast-tracked).
5. Post Implementation Reviews are conducted for:
• Any change that was less than successful
• Changes that resulted in a Priority 1 (Urgent) or Priority 2 (High) incidents
• Or at the discretion of the Change Manager
The results of the review must be documented and attached to the Change Record.
Change Management Policies
6. Incidents caused by a Change must be linked to the appropriate Change Record.
7. All Technical Reviewers must approve the Change in order for a Change to be approved.
8. All CAB members must approve the Change in order for a Change to be approved.
9. All changes, except Informational Changes, must be associated with at least one Configuration Item (CI).
10. Standard changes are added to the Standard Change Catalog by getting approval using the normal Change Management process.
Technical and Architectural Reviewers
The Technical and Architectural Reviewers consist of the following representatives:
• Network
• Security
• Hosting
• Data center
The Change Owner, Technical Reviewers or Architectural Reviewers can add additional reviews as
necessary.
 CAB/eCAB Membership and Meetings
CAB/eCAB Membership
The Change Advisory Board (CAB/eCAB) is used for assessing Medium and High Risk changes.
1. Change Manager
2. Directors from each area (or their delegate)

CAB/eCAB Meetings
It is expected that the Change Manager will conduct one (1) CAB meeting a week. The actual frequency may vary depending on the
volume of changes. eCAB meetings will take place daily as required.

A general outline for a CAB meeting is:

1. Check if there are any questions or concerns about any recently implemented changes
2. Review any new High Risk changes that were submitted
3. Review changes to be implemented in the next period
4. Check if there are any questions or concerns arising from any recently completed post implementation reviews
5. Review any nominated standard changes (once a month)
Key Performance Indicators
VUIT will focus on a few select Key Performance Indicators (KPIs) to measure the success and
efficiency of the Change Management process. As the Change Management process matures, the
KPIs may change to focus on different areas that need improvement.
1. Number of changes implemented by type, team, etc.
2. Reduction in the number and percentage of emergency changes
3. Reduction in the number and percentage of Fast Track (expedited) changes
4. Reduction in the number of failed changes / increase change success rate
5. Reduction in the number of Unauthorized changes