Skip to main content

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.

  12. Change request types

  13. Request for change: Change requester initiates process and role players in change identified, Standards and quality criteria established for the raising of changes.
  14. 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.
  15. 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).
  16. Impact and risk assessment: Assessment of impact and risk on technical level, Assessment of impact and risk on business level.
  17. 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.
  18. Installation in testing: Pre-installation Meeting, Performs installation as described in Deployment Plan, Attend and support the installation.
  19. Test installation review: Review installation of testing, Feedback on testing installation, Formal declaration of testing phase.
  20. 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.
  21. Operational acceptance phase: Acceptance testing checklist and operations readiness signoff, Service integrated into existing productive environment, Review test results.
  22. Ready for live: Verify all tests completed, Service desk informed and trained, Business Unit users informed, Formal declaration of live.
  23. Implementation in live: Implementation performed as described in deployment plan, Support and supervision of implementation.
  24. Go Live acceptance: Successful integration in live environment, Decide back-out strategies, Quality assurance, Review implementation.
  25. Live: Services provided to Business Unit user, SLA measured and achieved.
  26. Integration with Service Desk: Integration with incident management, Integration with problem management.

A mindmap of IT change management stakeholders

This article was originally published over on LinkedIn: Checklist for Change Management - the first step to avoid IT causing a titsup



Popular posts from this blog

Why Madge Networks, the token-ring company, went titsup

There I was shooting the breeze with an old mate. The conversation turned to why Madge Networks which I wrote about here went titsup. My analysis is that Madge Networks had a solution and decided to go out and find a problem. They deferred to more incorrect strategic technology choices. The truth of the matter is that when something goes titsup, its not because of one reason only, but a myriad of them all contributing to the negative consequence. There are the immediate or visual ones, which are underpinned by intermediate ones and finally after digging right down, there are the root causes. There is never a singular root cause for anything but I'll present my opinion and encourage everyone else to chip in. All of them together are more likely the reason the company went titsup. As far as technology brainfarts go there is no better example than Kodak . They invented the digital camera that killed them. However, they were so focused on milking people in their leg

Flawed "ITIL aligned"​ Incident Management

Many "ITIL aligned" service desk tools have flawed incident management. The reason is that incidents are logged with a time association and some related fields to type in some gobbledygook. The expanded incident life cycle is not enforced and as a result trending and problem management is not possible. Here is a fictitious log of an incident at PFS, a financial services company, which uses CGTSD, an “ITIL-aligned” service desk tool. Here is the log of an incident record from this system: Monday, 12 August: 09:03am (Bob, the service desk guy): Alice (customer in retail banking) phoned in. Logged an issue. Unable to assist over the phone (there goes our FCR), will escalate to second line. 09:04am (Bob, the service desk guy): Escalate the incident to Charles in second line support. 09:05am (Charles, technical support): Open incident. 09:05am (Charles, technical support): Delayed incident by 1 day. Tuesday, 13 August: 10:11am (Charles, technical support): Phoned Alice.

Updated: Articles by Ron Bartels published on iot for all

  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all .  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all . Improving Data Center Reliability With IoT Reliability and availability are essential to data centers. IoT can enable better issue tracking and data collection, leading to greater stability. Doing the Work Right in Data Centers With Checklists Data centers are complex. Modern economies rely upon their continuous operation. IoT solutions paired with this data center checklist can help! IoT Optimi