The purpose of change management

IT Change Management is the process that delivers change into our organisations. It is one of our most familiar ITIL processes and one that many of us are likely to have participated in as a requester, an approver, or (like me) both.

At it's heart, change management is a risk management process, and I believe great quality change management approves as many changes as is appropriate whilst reducing risk of things going wrong in our environment. This keeps our services available and performing in a manner that aligns with the commitment we have made to our organisation or customers whilst maximising potential for service improvement.

The purpose of change approval

It therefore follows that great quality change approval is all about approving the right changes for the right reasons, and rejecting those that don't make the grade.

As an architect, I am a gatekeeper for change management as I approve or reject requests for change in my organisation. I want to be able to approve all requests on the first submission to maximise throughput of work with minimal risk to our environment, but this isn't always possible if a change request isn't in a state that is fit to approve.

So what is the criteria for a great quality change, and how might architects like me support IT practitioners to submit them?

Systems Engineering might have the answers

I assess changes in two dimensions:

Firstly, I make sure we are doing the right work. This is the subject of the change. This means I take a view on the extent to which the proposed change fixes a known problem or delivers a planned improvement. I consider if it is the right action to best fulfil the need, and I make sure the change will not impact upon other systems or integrations.

This dimension is well understood, and as requesting practitioners are often subject matter experts in their own portfolio of applications and infrastructure then I rarely have to reject a change because the work is fundamentally inappropriate.

Secondly, I make sure we are doing the work in the right way. This is the method of the change. This means I take a view on how the work will be done to make sure the method of delivery will proceed with the minimum amount of risk.

This dimension is typically less understood by practitioners and it is not uncommon that I am asked to approve changes that have minimal or no method of implementation proposed. Typically, I will reject these changes as I cannot be sure of the implementation risk given I have no visibility of the method, even if the change is doing the right work.

Looking beyond IT, doing the right work and doing the work in the right way also reflect the aims of Systems Engineering, and I like to borrow some of the principles of the discipline to help with change management.

Applying Systems Engineering principles to Change Management

So, to improve change management, I ensure practitioners are aware of how I use Systems Engineering principles to assess change requests:

The subject of the change must be doing the right work. Practitioners must prove this by writing a short case that describes the problem or required improvement, and why the proposed change is the solution.

The method of the change must show how we will do the work in the right way. Practitioners must prove this by writing a method statement that manages the risk of implementing the change. Typically, I look for a statement that equates to a brief Low Level Design according to the Systems Engineering V Model. If necessary, I remind practitioners that the low level elements will require articulation at the point of delivering the change, so no extra work is required, it is simply moved forward. Enactment of the change is then a case of following the submitted method.

I then use Change Board to perform what amounts to a lightweight Preliminary Design Review of the subject (appropriateness) of the work, and a
Critical Design Review of the method.

Provided both reviews 'pass' then the change is approved.

Improving rejected changes

If either review fails then the change is rejected with the following advice:

If the wrong work has been proposed then the practitioner is advised to reconsider and submit a more appropriate change request, or a better business case.

If the right work has been requested but it lacks an appropriate method, then the practitioner is advised to reconsider and submit an improved method (or often any method) that demonstrates how the change can be delivered with the minimum of risk.

Improving change management in your organisation

I hope the reflections above can help you improve change management in your own organisations. But, if you should require any assistance then I'd be delighted to help out via my consultancy services.