Documenting Changes
Effective management of change provides a structured, consistent, and measurable change environment to be utilized across an organization and is a critical component in the success of its daily business. Its goal is to increase awareness and understanding of proposed changes across the organization and ensure that all changes are made in a thoughtful way that minimize negative impact to services and customers. An organization should have a document that defines the implementation of Change Management procedure. The computing systems, networks, peripherals, and associated facilities are subject to continuous changes driven by new technology, evolving business requirements, changing contractual requirements, and growing regulatory policies. Effective change management applies to both systems and supporting infrastructure, and is a necessary component for the continuous success and growth of the organization.
Effective Change Management - Documenting Changes
In the previous blog we discussed the roles and responsibilities in the change management process, which need to be clearly defined to establish accountability. Today, we are discussing how to document changes in the change management process. The key steps of change management process are: planing, evaluation, documentation, review, approval, communication, implementation, and post implementation review. Documenting changes do not only happen during the documentation step. Changes need to be documented and updated throughout the change management process. Nowadays, most organizations use change management softwares to manage change requests (CR), review, and approval workflows. Smaller organizations with resource constrains may still use simple Change Request Forms (CRF) to mannually manage the CRs, review, and approval processes. Important information must be captured for each CR regardless the change management tool (sophisticated software or CRF). The mandated information is required for adequate review by others (approvers and change control review board) for approving the requested change.
Change Types
We have discussed the change definition and categories in a previous blog. The most two common change types are Normal and Emergency changes. (Some organizations may organize change type in a more detailed level, say, by business applications and infrastructure.) When the CR is created, the requestor needs to have a clear understanding of the difference between the types and knows what type of change request he/she is about to create because the normal changes and emergency changes use different review and approval workflow.
Change Categories and Their Definitions
Some organizations use change type and change categories interchangeably. Each change management process is unique to serve its own organization, and terms and its meanings may be slightly different. Here, change categories and definitions are related to the severity and impact of the change. The change requestor needs to provide the information with regard to change impact (How many business users will be impacted?) and change complexity (How long is the install time and/or are there be difficult or lengthy backout procedures?) and criticality (Is the changing system deemed as highly critical for the business?) Sophisticated change management software can calculate and determine the change category after receiving mandate information. These information will further help approvers and change control review board to assess the risks and approve/deny the CR.
Description and Justification
The description and jusitification of the change should be detailed. For example, “patch Windows server XYZ” is not a good description nor justification. A good example for this RC should be: “Applying Microsoft MS15-106, Cumulative Security Update for Internet Explorer (3096441), to XYZ server. This security update resolves vulnerabilities in Internet Explorer. The most severe of the vulnerabilities could allow remote code execution if a user views a specially crafted webpage using Internet Explorer. An attacker who successfully exploited these vulnerabilities could gain the same user rights as the current user.” Some members of the change control review board are business representatives and may not be technical. Detailed description and justification help all parties involved in the change management process to get a clear and better understanding of the change.
Change Window
The change requestor should to submit a proposed implementation date and time. This information is needed to properly schedule changes and avoid conflicts. For example, the application support team wants to perform an ungrade on an accounting software on the last Saturday of the month. The Accounting department may not approve the CR because they will be closing the books during the month end and cannot afford system downtime. The change window is push back two weekends. The approved implementation date and time is the actual change window. The change window needs to be close to the actual time needed for the change and the time to perform the planned backout procedure.
Implementation Plan
The implementation plan is a detailed, step-by-step procedure for the change. The change requestor may need help from the change developer, if they are not the same person, to provide the details. Because of segregation of duites requirements, most likely that the change implementor is not the change requestor and change developer. The change implementor needs detailed instructions to perform the change.
Testing Plan and Testing Results
The testing plan documents the testing of the chanage in detail. Testing should be performed in a development or testing environment. The change should be tested by the change developer first, and then tested again by an end user or users. The testing results should be captured to demonstrate that the change meets acceptance criteria . This also provides audit evidence that testing procedures are properly followed.
Backout/Rollback Plan
Some organizations call it Backout plan and some call it Rollback plan. Regardkess, it is a contingency plan in case the change fails in the production environment. Some backout plans are as simple as revert the parameter value back to the original state. Some backout plans are more lengthy and complex, such as perform a backup procedure before the change. Should the change fail, a totally system restore is required.
Review and Approval
The review and approval process differs in organizations. Some companies institute change through their control board, and it is the authoritive body to review and approve all CRs. Some samller companies may not have the change control board, but require IT and business approvals for CRS. Whatever the process is, the review and final approval should to be documented in the change management process. Whether the approval is received within a change management system or manually saved on a shared network drive, the record must exist. They are an important part of change management process.
Closing
After implementing the change in the production successfully, the CR status should be changed to “Closed”. If the change was unsuccessful, the CR status still needs to be changed to “Failed or change rolled back”. Some organizations require user’s confirmation that the change was successful before closing the CR. It is a good practice, but it may take longer time to close the CR. A post implementation review should be performed on failed changes to learn the cause of the failuer and document lessons learned.
In summary, changes need to be documented and updated throughout the change management process. . Important information must be captured for each CR regardless of change management tool (sophisticated software or CRF). The mandated information is required for adequate review by others (approvers and/or change control review board) before approving the requested change. In the next change management discussion, we will look into change communication and sapost post-implementation of change management process. Stay tuned!
To get a FREE copy of our quick start "Change Management - Change Request Form (CR).pdf", simply click this button.