Change Management Process
Change Management is the process of managing most changes that can have an effect on any IT environment, both infrastructure and systems/apps. All changes to a production environment or application need to be documented and communicated.
Each production change requires a ticket (most will already have one) and the Change Control document must be attached to the ticket, along with populating the Scheduled Start Date and Scheduled End Date.
Change Management is the documentation of changes to production IT environments. All of the required information can be found on the Change Control Form which can be found at:
Change Event Management\Change Control.docx
Every change to production must be documented in a Change Control form, except for data changes. Data Changes require a Change Control form if more than 10% of the records in a table are affected.
The Change Control Form requires arrangements be developed for support, preparation to backout, coordination with other changes, coordination with Change Administrators, etc.
Change Control is designed for visibility into all the changes being made to our production environments.
Instructions:
Change Control form required for all changes to production, both infrastructure and system/apps.
Route to [email protected].
Route one day in advance (if possible).
One Change Control form per change to production (multiple changes on one form must implement together.)
Data Changes are not applicable.
Attach the Change Control to the ticket, if applicable.
Store the Change Control at IDocumentation\Change Event Management.
Completing the Change Control form:
Ticket ID (if applicable):
ID number assigned to Incident, Service Request or project
Request Date:
Date the customer requested the service or change.
Scheduled Start (date/time):
Date/Time change is planned to begin implementing. Assumes a system outage will begin.
Scheduled End (date/time):
Date/Time a change is planned to end implementing. Assumes a system outage will end.
Change Administrator:
Person administrating the change to production. May include multiple Change Administrators:
Project Manager
Person managing the project. May the Manager of the programmer or infrastructure personnel for Incidents and smaller projects.
Stakeholder(s)
Person(s) interested in the change implementing.
Type:
Change to Hardware, Software, or Both.
Change Description
Description of the change. Include a reason for the change.
Support Information
List the people supporting the implementation and contact information. (Primary, support, vendors, consultants, etc.).
Area of Impact
List the hardware and apps being affected. If an outage is occurring, list the duration and the departments affected. (Hardware, Applications).
Testing Completed
List the testing completed. Reference test scripts or PQ’s, if appropriate. In the case of infrastructure changes, testing will be completed after implementation. List the testing to be completed.
Installation Plan
List the necessary steps to implement the change. If possible, script the changes. Use the appropriate Change Administrator.
Backout Plan
List the steps necessary to backout the changes if production does not work correctly. All backups and precautions should be part of the Installation Plan.
Change Administrator
The Change Administrator role is important to the overall process. IT is a customer service organization. We provide highly available systems to our customers and ensure their security. Maintaining permission restricted production environments assists by ensuring only authorized changes occur to our systems and they are well thought out, executed, and auditable.
Infrastructure has numerous pieces of equipment and system software. Many of these systems require various permissions to configure. All members of infrastructure have access to the appropriate passwords to perform their responsibilities. The infrastructure administrator is listed as “infrastructure personnel” because any one of the infrastructure staff can make the necessary change. The Infrastructure Manager will assign a person to the project.
The DBA role also fulfills a lot of Application changes.
The Application Administrator is dependent on the type of application being changed. Applications implemented prior to 2014 are the Legacy applications. Applications implemented after 2014 are the Modern applications.
The Change Administrator for Legacy applications is a Programmer Analyst 2 or greater, unless assigned by a manager. The Change Administrator will request elevated permissions by the Infrastructure Department. The change will be implemented and verified. The permissions will be removed shortly have the verification is complete. Infrastructure will be responsible for ensuring permissions are granted and removed appropriately.
The Change Administrator for new applications is designated. They will maintain appropriate permissions at all times.
All Change Administrator roles may be designated to a different person, by management, if the standard person is unavailable for the change.
Coordinating the change with the Change Administrator’s schedule is the responsibility of the person submitting the Change Control form or the Project Manager.
Scheduled Outages
Outages to production should be kept to a minimum, meaning, the duration of the outage should only be as long as required and the number of customers affected should be minimal.
This is the standard for scheduling outages for changes to production.
Changes that affect only one or a few departments and can be implemented in a short amount of time may be implemented during business hours after the notifying and coordinating with the departments.
Changes affecting more than two departments, numerous customers or external customers need to be scheduled outside of business hours, unless approved by the Director of IT.
Emergency Change Control
If an emergency requires a change to production immediately and the change can not wait for the Change Control form to be completed, verbal approval must be provided by the Director of IT. If the Director is unavailable, escalate up the chain of command. After the emergency has passed, the change must be documented on the Change Control form and noted that verbal approval was received prior to implementing.
If a change is required to production, during business hours, and it affects more than two departments, numerous customers, external customers, or an extended outage, approval must be provided by the Director of IT. If the Director is unavailable, escalate up the chain of command.
