Article Contents
Purpose
The purpose of Change Enablement is to maximize the number of successful IET changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule. Change Management is about having a plan that is organized, communicated and known with no surprise downtime to impact users within Metropolitan State University.
Process Definition
A Change is defined as the addition, modification, or removal of anything that could have a direct or indirect effect Metro State services. Any type of Configuration Changes made within Production environments should have change records or customer impacting.
Procedures
Service Owners are responsible for coordinating a scheduled change taking place within the upcoming 12 day period.
The Service Owner completes a (RFC) Request for Change ticket as far in advance of the date of the scheduled change for review at the Change Enablement Meeting. Submitted Changes are created and reviewed in an “Awaiting Approval”.
At Metro State, the approval status is updated at the Change Enablement meeting unless there are outstanding questions addressed during the Change Enablement meeting. The ticket will be moved into an Approval Status at the Change Enablement Meeting.
Awaiting Approval Status:
A Change ticket is to be completed in an Awaiting Approval status awaiting final approval at the Change Enablement meeting.
All vetting of the change is to be completed prior to the Change record approval at the Change Enablement meeting. The Service Owner will contact technical teams to advise of the Change and any assistance needed, including the Service Center. If KBA’s need to be created or updated this is completed as soon as the change occurs. Once all items are completed, the Service Owners director is contacted advising of the change.
The IET Leadership Director provides the final approval in preparation for the upcoming Change Enablement meeting.
Change Enablement Meeting:
The Weekly Change Enablement Meeting takes place weekly on Wednesday mornings at 9:00. The Change Enablement Agenda asks that each individual representing a Change is prepared to offer a one-to-two-minute overview as outlined below.
Change Enablement Meeting Agenda:
- Review the proposed changes using the Request for Change Process Dashboard
- Review all Major Incidents which have occurred during the previous 11 days
- System(s) impacted
- Corrective action taken
- Problem ticket number (if applicable)
- Change will be marked as Approved after the overview is provided
Overview of Change for Approval:
- When is the change scheduled to occur?
- What is the change being made?
- What will the impact be?
- Who is making the change? Are other technical teams involved?
- Why is the change needed?
- Are there any risks associated?
- Where is the change scheduled to me made? (St. Paul, Midway, Minneapolis etc.)
- Who will validate after implemented success?
Approval Status:
Once the Change has successfully fulfilled the vetting process,the ticket is moved to Approved at the Change Enablement meeting.
Pre-Approved Changes:
A Change that has been vetted and proved to be successful on a regular basis can have a pre-approved approval. (i.e. Monthly patching is an example). Out of ban patching will require additional vetting (Emergency Change)
For any third-party vendor or Minnesota State System Office related changes, a Change record will be created for awareness. (i.e. D2L, ISRS) in an Approved status.
Status of a Change:
The Status of a Change will follow the same actions as outlined within the Ticket Statuses in TeamDynamix KBA.
Preparing the Change for Closure:
Once a Change Request has been completed, the Service Owner is responsible to choose the outcome of the Change with the implemented success and then the status moved to Closed. If the Change created a Major Incident, we will want to tie the Change to the Major Incident.
Outcome of Change Request:
Implemented Successfully: Change implemented without incidents
Implemented With Problems: Change implemented with known issue(s)
Implemented With Backout: Change implemented with enacting the backout plan
Major Incident Occurred: Change implemented although a Major Incident occurred afterward
Unsuccessful: Change was implemented and unsuccessful
Withdrew Request: The Change was not implemented and request withdrawn prior to implementation
Steps
To create a Change, select the blue button "Request for Change" located on the Change Enablement Process Dashboard or by creating an (RFC) Request for Change in TDNext as outlined below.
- Open TeamDynamix
- Select the METRO IET Services tab
- Select the +New
- Select (RFC) Request for Change - Form
- Complete the form
- Click Save
Change Emergency
If an emergency change need occurs, the following process occurs.
1. Implementer/Requestor completes a Change ticket
2. Implementer/Requestor determines a change needs to occur before the next scheduled Change Enablement meeting or not been communicated yet
3. Implementer/Requestor notifies their IET Director of the need for an Emergency Change Request
4. Implementer/Requestor will schedule a meeting with Change Enablement team (find a time for the majority of the members to meet, not all need to be present)
a. A notification is sent to the Director of the Technology
b. A notification is sent to the Team Leads Channel for communication
c. A notification to the IET-Collaboration Teams to communicate
5. Change Enablement Members assemble to discuss the impact and urgency of the Change Request
a. Implementer/Requestor provides information
Impact
What is the impact of waiting to implement after going through Change Enablement?
What is the impact of not implementing the change?
Urgency
Can the change wait until the next Change Enablement Meeting?
Is Metro State at risk? What is the risk?
b. Change decision by Change Enablement
c. Does theImplementor/Requestor need to send a campus communication?
Roles & Responsibilities
IET Leadership
IET Leadership champions the Change process with their respective teams. The Service Owner once all planning and questions have been answered will notify their IET Leadership Director for any questions they may have. After the Change has been vetted fully with the Service Owner Director, then the Change Record will be discussed at the Change Enablement Meeting. If communication is needed, the Director and Service Owner are responsible to write for publishing.
Service Owner
A Service Owner is responsible for coordinating a scheduled change within two weeks (12 days) of the change occurring. Changes need to be reviewed at two scheduled Change Enablement meetings. The first review is to inform others of the change for someone to reach out to discuss with the Service Owner.
The Service Owner prior to attending the Change Enablement meeting will discuss and plan with other functional teams the Change, including the Service Owner and Leadership Director. Once all questions have been answered, the Service Owner will complete a Change record. The Change Record is completed as far in advance of the date of the scheduled change to be reviewed at the Change Enablement Meeting.
- The Service Owner is often the individual change initiator (making the change) who will complete and document the change
- Prior to attending the Change Enablement Meeting, discuss with assigned IET Director or Leadership of the noted change
- Prior to attending the Change Enablement Meeting determine and plan within the functional area how the change is to be implemented (Are or will other resources needed to implement the change? Have meetings been assembled to discuss the type of work the other resources will need to complete for the change?)
- The Change Initiator will prepare any communication needing to be sent (if applicable)
IET Staff Members
All members within IET are informed and aware of any upcoming scheduled Changes.
Service Desk
Provided an awareness of any scheduled Changes occurring within Metro State and any updated documentation or Knowledge Articles.