itSMF Bulletin July 2022 | Page 5

without losing any control or quality of changes. I could expand on this further, but that is better left for another article.

From the Change Management, and management side, we are looking for all changes to add value to the production services. This can be easier than you think. Open conversation is essential. If the Change Owner cannot explain this, then they may need more time to consider their own change. If they are uncomfortable with going into the detail of their change, then you need to know why. Does their change really fit the ‘value’ criteria? If not, do them, and yourself, a favour and put more thinking into the change and less urgency (rush).

Encourage time spent to improve good changes, and not spend valuable resources on not-so-good changes.

2 DEFINITION

1 PURPOSE

The purpose of Change Management is to maximise the number of valued changes being implemented.  Often this point is forgotten. The focus is on risk reduction and not on change enablement. The result is a complicated process of hoops and hurdles for Change Makers to have to overcome. Instead, focus on maximising the process throughput. Identify valued changes,

removing those that do not ‘stack up’, or are not even changes. A valued change is one that is well thought through, and will add value to the service performance that it is impacting.

Change Management is a Service. Treat it as such. Engage with Change Makers to see what works for them. They must be able to concentrate on their change. Change Management assists with the integration of their change with everything else that is going on – visibility, timing, conflicts.

Make the process fit the customer, not the customer fit the process. I have heard management say, “I am customer focussed” and later insist the customer must follow the process.

Even with Agile, DevOps and CI/CD, if your focus is on assisting changes to be implemented, then there are ways to assist and boost productivity in these new realms. Talk with the people involved to understand their needs, and adjust the Change Management process to accommodate them,

The ITIL definition of a change is a bit ambiguous. I have seen this interpreted in various ways. I have adapted the ITIL definition to hopefully make ‘What is a Change?’ a little clearer.

o Planned; if it is not planned then it is an incident that you didn’t see coming- something out of your control

o Modifying; regardless of the size of the modification, you are moving to a new normal, not repeating what is done

o The way in which a service is being delivered; doing something different for a better result