Checklist for Change Management - the first step to avoid IT causing a titsup

The following is a checklist for change management. This checklist is not for a pilot flying a plane but for use in IT, but is named as such because pilot's were the first to use this methodology.

The checklist is a form used to standardise a processes. A checklist includes a list of items to check, steps to take, or information to mine. Pilots use checklists to do a pre flight check. Checklists are useful to make sure no items are missed which may happen if a person just does what they remember. Checklists can also aid in providing documentation to aid in trouble shooting.

Here is the checklist:

1. Clarify what Change Management will accomplish in the enterprise. Change Management focuses on the oversight and approval aspects of the process, ensuring that only authorized changes are being worked on. It is more related to business impact than to IT operations. The ITIL definition of Change Management is that it is a process of controlling changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved changes with minimum disruption.
2. Define what a Change is. All Installs, Moves, Adds and Changes (IMAC’s) to the infrastructure, and any software changes should fall under the control of Change Management. Even the most seemingly innocuous changes can cause major disruptions and outages if they are done under the radar. This is often the case when implementing Change Management in an immature, silo-structured enterprise.
3. Make all levels of the enterprise aware of the benefits of Change Management . Stakeholders need to understand the benefits on an individual and team level. Clearly defining and presenting to each stakeholder what those benefits will be, and conversely, establishing and enforcing policies that address the penalties and repercussions for bypassing the process is essential.
4. Establish clear roles and responsibilities for the Change Advisory Board (CAB) and Change Manager. An effective and successful Change Manager is one who proactively ensures that the right resources, both technical and business, attend the CAB and present viable, justifiable changes. The Change Manager can be the final arbiter in resolving disputes over classifications and prioritisations. In extremes, this can be escalated to executive level. Attendees at the CAB who are representing changes should be well-informed and can speak to their items when challenged. Their role is to present the business case, the impact analysis, the resource plan and execution plan for each change.
5. The CAB should not be the exclusive domain of IT. A successful CAB will have a wide rotating mix of attendees from the IT, operations and the business.
6. Establish and stabilize the Change Management process before introducing tools. Ask not what what you can do for the tool, but what the tool can do for you?
7. Define Key Performance Indicators (KPI) and Critical Success Factors (CSF). KPI's: Reduction of unauthorized changes. Reduction in change related outages. Reduction in emergency changes. Actual cost of a change vs. budgeted cost. CSF's: A repeatable process that can make changes quickly and accurately. Protecting the integrity of the service when making those changes. Delivering process efficiency and effectiveness.
8. Ensure back-out plans are documented and realistic.
9. Highlight the positive by building on successes and leveraging lessons learned. Distribute success stories and integrate lessons learned into plans for future roll-outs.
10. Use the Change Management initiative to promote other ITIL processes. When Release and Configuration Management processes are absent, consider combining all three into a centralized function. The three processes have many close links to each other and together can stabilize an enterprise’s production environment.
11. Create standardized processes and time frames to support Change Management. Have senior members of CAB sign off on the criteria to reduce the noise level. Define the boundaries around priorities and have them implemented. Standard change processes will result in fewer circumventions of the system and greater efficiency and effectiveness.

Change request types

1. Request for change: Change requester initiates process and role players in change identified, Standards and quality criteria established for the raising of changes.
2. Change evaluation and assessment process: All upgrades or growth procedures should be fully validated in the lab environment prior to first application in the field, Collect all data necessary for further evaluation of RFC, Develop deployment plan, Deployment manager initiates process for testing change.
3. Configuration management database: Extend CMDB by new Configuration Items (CI) & relations that are inherent to the new change, Defines relevant CIs and their relation to other CIs (logical and physical interdependencies).
4. Impact and risk assessment: Assessment of impact and risk on technical level, Assessment of impact and risk on business level.
5. Change Advisory Board (CAB): Functions & purpose of change management has been communicated within the enterprise, Approval of change, Conduct final assessment of requested change and issue approval/denial.
6. Installation in testing: Pre-installation Meeting, Performs installation as described in Deployment Plan, Attend and support the installation.
7. Test installation review: Review installation of testing, Feedback on testing installation, Formal declaration of testing phase.
8. Testing in progress: Conduct a pre-defined set of basic integration tests (as defined by the Deployment Management), Conduct functional test, Conduct user acceptance, Prevention of interference with existing live systems.
9. Operational acceptance phase: Acceptance testing checklist and operations readiness signoff, Service integrated into existing productive environment, Review test results.
10. Ready for live: Verify all tests completed, Service desk informed and trained, Business Unit users informed, Formal declaration of live.
11. Implementation in live: Implementation performed as described in deployment plan, Support and supervision of implementation.
12. Go Live acceptance: Successful integration in live environment, Decide back-out strategies, Quality assurance, Review implementation.
13. Live: Services provided to Business Unit user, SLA measured and achieved.
14. Integration with Service Desk: Integration with incident management, Integration with problem management.

A mindmap of IT change management stakeholder

Ronald Bartels provides SDWAN solutions via Fusion Broadband where he helps businesses connect things to the Internet. 

* Originally published on LinkedIn by Ronald Bartels.