4 Common Questions About Implementing Change Management
There are very few people who work in ICT who can argue with the value of having a change management process in place; in fact, for many it's a regulatory requirement. But, a question is frequently asked: ''Can I afford the overhead with managing the change process?'' The real question is can you afford NOT TO have a change management process, especially when you consider that 70/80% of unscheduled down time is attributed to poorly implemented changes! (Gartner Study by Ronni J. Colville and George Spafford - 'Top Seven Considerations for Configuration Management for Virtual and Cloud Infrastructures').
In fact, an efficient change management process can add value by ensuring that you maximise what can be achieved during scheduled down time by consolidating all proposed changes and prioritising those changes that have the most significant and positive impact to the business.
And indeed, getting the right balance on successful change management can be very challenging. If the process is over-bureaucratic, it impedes the organisation from progressing, yet if the controls are too light the organisation may be at risk from badly planned changes.
There are a number of factors to consider when implementing a change management process:
What level of rigour do you need to enforce?
Prior to commencing your change management policy you need to consider what level and depth of changes you intend to manage. Normally the change management process covers all changes to ICT systems that support the business, however if your change management process encompasses everything, then your team shall rapidly come to a grinding halt, bogged down in a quagmire of processes and procedures.
Sit back and think of the changes that you want to manage, and identify those that may be processed via standard requests, i.e. low risk, frequently occurring changes that follow a standard process every time; these are technically changes but you would not run them via the CAB (Change Advisory Board) every time you want to process one!
Once you have whitelisted the standard requests you can then assume that all other changes to the environment need to be processed via the change management process.
How many layers of approval are required in the change management process?
The goal of the CAB is to: Coordinate and control all changes to IT services to minimise adverse impacts of those changes to business operations and the users of IT services.
And, as such, the CAB normally consists of individuals who have the ability and authority to perform an impact assessment and authorise changes to the infrastructure – senior individuals. So, you would hope that all changes have been through some form of sanity check before getting to them but without a structure in place to ensure this, it may not happen.
To ensure that you reduce the cost of running a CAB, try and ensure that all proposed changes have some level of validation and checking prior to being presented to the CAB for review; ensure that there is a peer review, where a CAB spans multiple functional departments, ensure that the changes have been assessed at a functional level (maybe have a functional CAB) and, above all, where possible ensure that the workflow is automated and via e-mail.
By the time the CAB convenes to review the list of changes, all questions should have been asked and answered in advance.
What information needs to be included in a change request?
Again, a tricky question. Too much information requirements and you can overload the process in documentation; too little and you lack sufficient information to make a decision. It is important to remember, the purpose of a change request is to provide information, so the management can make a decision on whether to authorise a change or reject a change. There may be regulatory requirements for a lot of organisations to have a formal auditable change process, but first and foremost it's providing information to make a decision. Hence at a minimum the change request should include (not including the authorisation levels)
- Change number : Should be unique
- Change category
- Risk level associated with the change
- Service asset impacted (or application, system etc.)
- Business units impacted (if known)
- Estimated downtime associated with change
- Proposed implementation date
- Implementation steps / plan
- Rollback plan (if it goes wrong)
- Business impact of change (how it aligns to business drivers)
- Critical success factors (test plan to validate success of change)
How do I know if I have a successful change management process?
I suppose the most obvious one is reduced unscheduled downtime. However, there are a lot of efficiency factors involved as well.
- You meet regulatory requirements; you have an auditable change management process with a proved approval cycle.
- The workflow associated with the change management process supports progress outside the CAB; by the time the CAB convenes, all questions relating to a change (from a technical, risk and cost perspective) should have been queried and, in turn, answered. The CAB should be there in a summary fashion vs having to go into detail on each individual change. (If it even does need to convene; if you have an effective process this may all take place via email).
- You can easily produce reports and updates and have the information you need when you need it.
And most importantly it's efficient and it flows; it is easily incorporated into individuals' work routines and processes and it is an enabler of progress vs an impeder.
We would be delighted to share our experience with you and discuss your change management challenges, our FlowForma change management solution can be configured to align with your organisation straight out of the box, or we can work with you on customisations.
To find out more about FlowForma please visit www.flowforma.com