System Change Management Policy
Purpose
The intent of this Policy is to ensure that changes to Uncanny Software system components are coordinated and logged to prevent service disruption, duplication of effort or conflict.
Scope
This policy applies to all Uncanny Software engineering, customer success and product team members. 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.
Database – Changes to databases or files such as additions, reorganizations and major maintenance.
Policy
Formally Request a Change
All requests for change must be documented within the company’s selected technology platform by creating a new change record. The completion of a new request for change will be completed by the Change Coordinator with input from the Change Requester.
Categorize and Prioritize the Change
The Change Coordinator must assess the urgency and the impact of the change on the infrastructure, end user productivity, and budget.
Analyze and Justify the Change
The Change Coordinator works with the Change Requester and the Change Initiator to perform an impact assessment including areas of performance, capacity, and security.
Approve and Schedule the Change
The Change Coordinator uses the company’s selected technology platform to record an efficient process for routing the request to the Change Coordinator, technical approvers, business approvers and, in the event of a major or significant change, to the Architect Team for approval or rejection of the change on the architecture and the Release Team approves of the changes.
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.
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.
Workflow
The following diagram provides a high level overview of the workflow for the change management tasks.
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 on the Release Team are defined for the change management process are:
Release Manager
Engineering
Site Reliability Engineering
Quality Assurance
Release Manager
The Release Manager is responsible for managing the activities of the change management process for the system engineering organization. This individual focuses on the process as a whole more than on any individual change. The Release Manager is ultimately responsible for the successful implementation of any change to the Uncanny Software system components. The Release Manager’s responsibilities include:
Receiving change requests and ensuring that they are properly recorded in the change management system technology platform.
Scheduling and coordinating who will be on the release team.
If necessary, assigning teams to conduct ticket impact analyses and risk assessments.
Analyzing and prioritizing tickets.
Approving requests for minor changes or assigning approval authority to others.
Providing change notification to stakeholders.
Monitoring the successful completion of all run books, including the change development project phases and ensuring that these processes follow the change schedule.
Reviewing and evaluating the change process.
Engineering
The Engineering team member originates changes by submitting an release candidate branch (RC) for the code to be deployed and verifies each to deploy to the appropriate environments. They update the runbook with the status of each code deploy. Everyone is authorized to follow/review the runbook. Engineering is responsible for providing sufficient information on the change that the Release Manager can complete the new change form within the company’s selected technology platform. This person is notified whether the change was approved and is kept up-to-date on the status of the run book throughout the change process.
Site Reliability Engineering
Site Reliability Engineers are present in the event our cloud infrastructure needs to be accessed to order to facilitate the deploy. They also monitor system logs to identify any anomalies to the rest of the release team.
Quality Assurance
Quality Assurance is responsible for executing individual tests for each environment and signing off to proceed with the next phase.
Violations
Since following the Change Management Policy is important for the welfare of the organization, employees that purposely violate this policy may be subject to disciplinary action up to and including denial of access, legal penalties, and/or dismissal. Any employee aware of any violation of this policy is required to report it to their supervisor or other authorized representative.
Definitions
Release Team – The Release Team is a cross-functional group set up to evaluate change requests for business need, priority, cost/benefit, and potential impacts to other systems or processes. Typically, the team will make recommendations for implementation, further analysis, deferment, or cancellation.
Change – Any new IT component deliberately introduced to the IT environment that may affect an IT service level or otherwise affect the functioning of the environment or one of its components.
Engineering – The role that is responsible for planning and implementing a change in the IT environment. The Engineer role is assigned to an individual for a particular release and assumes responsibilities upon receiving the go ahead to deploy for the Release manager. The Engineer is required to follow the approved runbook.
QA – A person who initiates a testing of the product throughout the release process. Release Manager – The role that has the overall management responsibility for the Change Management process in the IT organization.
References
ISO/IEC 27002:2013 - 14. System acquisition, development and maintenance ISO/IEC 27002:2013 - 12.1 Operational procedures and responsibilities
Related Documents
No documents listed
Revision History
Last updated
