The Win(d)s of Change Management – Part 2

Change Management
Share on facebook
Share on twitter
Share on linkedin

In my previous article – “The Win(d)s of Change Management – Part 1” – I covered the purpose of change management, ITIL 4 and change management/enablement, change management for Agile development, and Agile for change management. Now, in part two of this three-part change management series of articles, I’m offering more advice on how to adopt a practical and pragmatic approach to change management in the new business and IT worlds.

In the second part of this series, Gary Percival provides advice on how to adopt a practical and pragmatic approach to change management in the new business and IT worlds. #ITSM #ITIL Click To Tweet

Keep change management simple and practical

Look at the change management practice you have now. Where can it be made leaner? Where can it benefit from more automation, and fewer human interventions? Design, implement, and work the process. Start where you are and refine things to remove steps and approvals that do not add value.

You can start with the 7Rs (or 8Rs) of change management, the bare basics, as an MVS (minimum viable service).  For example, as a minimum (and possibly maximum), a change request should contain the following:

  1. Who RAISED the change?
  2. What is the REASON for the change?
  3. What is the RETURN required from the change?
  4. What are the RISKS involved in the change?
  5. What RESOURCES are required to deliver the change?
  6. Who is RESPONSIBLE for the build, test, and implementation?
  7. What is the RELATIONSHIP between this change and others?
  8. What is the service RECOVERY plan should something go wrong?

Cut your existing change request and process down to requiring only these fields. Really, what more do you need?

So, begin with a simple change management process and work with your customers (service developers) to enhance the process for them. Apply Agile disciplines to arrive at a process that works for them.

'Changes are activities that alter how a service is delivered. They're NOT for activities required to deliver the service.' #ITSM Click To Tweet

DevOps flow automation is so much easier with a simple change process. Considerations of the bigger environment, in which this change will reside, are so much easier to conceive and address too. And security becomes a component built into every change from the start.

Destress the change management practice for everyone.

Define what is a change (and what is NOT a change)

“A change or not a change, that is the question.” The scope of change management needs to be clear. In my opinion, the very definition of a change, “The addition, modification, or removal of anything that could have a direct or indirect effect on services,” has been misinterpreted to mean any significant action.

Understand that the intention was to manage any NON-OPERATIONAL modification to the service. Operational tasks, required to continue to deliver the service, are not to be covered by change management. Changes are activities that alter how a service is delivered. They’re NOT for activities required to deliver the service.

Services need to be defined (in the service catalog) in a way that includes the service requests available to an end user. These requests are provided to the end user, to select from, via an online service request catalog. Be sure not to confuse the two different catalogs. When an end user selects a request, and the request is processed, this is part of the way the service is being delivered. It’s not a change to the service, and hence NOT a change to be managed through the change management practice.

In other words, a change is applied to alter a service from one state to another, without the intention of returning to the original state as part of the change. Change management is there to assist change-makers in accomplishing the new state, with minimum resources and risk.

Examples of changes:

  • Implementing new code for an application
  • Modifying infrastructure
  • Altering the way the customer experiences the service (including supporting documentation).

Examples of non-changes:

  • Rebooting a server to recover from an incident
  • Initiating a batch process that is required for housekeeping
  • Password resets.

Having a clear, simple, and agreed definition of what is a change removes the effort of processing activities that do not need the discipline of change management. I’ve seen organizations complicate the change management practice so as to process non-changes. It doesn’t work.

Define what a change is and save yourself the cost and angst of an ill-fitting Change practice.

Define what a change is and save yourself the cost and angst of an ill-fitting change practice, says Gary Percival. Read more here. #ITSM Click To Tweet

Every change is a small project – consider its true scope

A complete change must consider all the same aspects of a complex project. Neglecting any component will reduce the likelihood of the change being successful. Just as with every major project, every change should always consider possible impacts on external factors as well.

Does this change impact:

  • Logistics?
  • Staff/operations?
  • Occupational health and safety (OH&S)?
  • Ethics?
  • Reputation?
  • On-going costs?
  • Environment?
  • Customer perception?
  • Regulations?

Simply put, consider the ITIL 4 external factors for each change. Most of the time, such considerations will be brief and obvious, but at least some time should be given to it. DON’T create a form that asks these questions, with mandatory responses. This just adds to needless paperwork.

Changes have a lifecycle, just like their bigger brother, projects. Part of this lifecycle is the communication plan that details which stakeholders need to be engaged, at what time, and in what way.

Plus, the delivery plan. How will the change be resourced? Who will be required to do what and when? In what task order will this change be performed (WBS)? How will it be implemented with minimal impact to production services and the environment?

'The same considerations for any major project must be given to changes so as to be sure the full scope and impact of the change are understood.' #ITSM Click To Tweet

The same considerations for any major project must be given to changes so as to be sure the full scope and impact of the change are understood.

Treat changes as small projects and you’re less likely to miss things.

So, that’s Part 2 of this three-part series of change management articles. What would you add in terms of the topics I’ve covered in the above? Please let me know in the comments.

Consultant at SM4ALL Services

An ITIL Master (v2) and Expert (V3), with PMI based project delivery, Gary is now providing his experience and knowledge through Service Management consulting for SM4ALL Services (Service Management for ALL Services).

Gary has worked in IT Service Management for twenty years, primarily in Change Management. He has delivered Change Management services for a variety of industries including finance, government, logistics, training, insurance and more. He now looks to pass on the lessons learnt.

He can be contacted via email at [email protected]

Want ITSM best practice and advice delivered directly to your inbox? Why not sign up for our newsletter? This way you won't miss any of the latest ITSM tips and tricks.

nl subscribe strip imgage

More Topics to Explore

Leave a Reply

Your email address will not be published. Required fields are marked *