It’s inevitable that we will encounter change throughout our personal and professional lives. New products are launched by businesses; people move house and football teams get promoted (but sadly not my beloved Derby County this season).
Many organisations will have some sort of Change process, but in my experience, that process is often applied rigidly to police implementations to the production environment; constrained by our ITSM tool; and is mired in bureaucracy leaving people to get bogged down – and sadly – miss its true value.
As IT professionals, we must be able to understand, plan for, adapt to, and deliver our customers’ needs whilst balancing quality, control, and conduct effective operation of our services. This is no mean feat.
What I want to share with you in this article is how you can build on your existing change process or processes and bring them together to help develop an end-to-end solution that works for you.
Meet the people
When I started looking at our existing change process, I quickly became concerned (and bored) reading a lot of documents ranging from lengthy procedural documents to copious meeting minutes. As a Change Manager, if you struggle to make it most of the way through the documentation, you can’t expect everyone to follow and appreciate it.
I quickly realised that the best way to learn about – and gauge opinion on – the subject was to meet the people that carried it out – the IT professionals of the organisation. The easiest way to meet vast majority of people was by arranging informal 1:1 meetings; have impromptu chats over the water cooler and buying the odd coffee or two.
Additionally, be sure to meet your customers to understand their perception of how the IT department delivered their change-related needs.
Very quickly, you can get different pictures and interpretations of how a process works in practice just by talking to people. Equally, I was able to draw some common themes by getting responses along the lines of:
- “We’re good at big projects but not at the smaller stuff”
- “There is little or no documentation or communication”
- “It’s quicker to code a solution than get anything done in our tool”
- “There’s so many obstacles and bits paper to fill in”
- “We only hear about a change when it’s about to go live or after the event”
- “It’s just a box ticking exercise”
Quick Wins – Work with what you have
Against a backdrop of varied opinions, unwieldy documentation and difficulties with the tool, it’s easy to think there’s a mountain to climb!
So I looked at what low hanging fruit we could work on and developed a short term plan focusing on what small improvements I could make with the tools I had. Quick wins included:
- Developing a few “Standard Change Templates” with a couple of teams for changes that were routine, repeatable and had known risk and impact.
- Introducing a series of questions on the change records for people to complete – effectively giving them a script to follow covering the risk, impact and implementation surrounding the change.
- Attending team meetings to demonstrate how to raise a change in the tool.
- Sending out a fortnightly newsletter giving advice on how to complete change tickets, inviting people to make suggestions and so on.
Get Everyone Involved – Revolution by Evolution
As much as the quick wins helped, for the longer term, it was apparent we needed to not only improve on our Change Control Process but push the understanding that change starts a lot earlier than being simply ready to ‘go-live’.
In order to achieve this, I needed resource and senior management support to make it happen. That is when I developed the idea for a “Change Away Day” which included:
- Representatives of all teams within the IT department with a variety of experience in the change process
- A proposal to Senior Management outlining the issues, setting objectives for workshop and providing a timeline of not only the day – but the next 3-6 months.
- A basic introduction to Change Management replacing the jargon with a theme people can relate to. We used the idea of building or moving house:
- “What” (are my requirements) i.e. where do I want to live?
- “How” (am I going to design it) i.e. architects will to design it with me before any trenches are dug by the builders
- “Why” (do I want to live there) i.e. assess and evaluate things that you like and dislike; the local schools; getting a mortgage and so on
- “When” (is it going to happen) and “Who” (is involved in delivering it) i.e. you can’t move overnight and will need some help to do it
- “Quality” (is it fit for purpose) i.e. do we have a safety certificate, are the utilities working and so on?
- “Approval” i.e. those final checks like exchanging contracts, moving van ready and packing your bags
- Guest speakers from department covering other processes and how they interact with Change Management – in this case, Testing and Solution Design Assurance.
- A range of activities that:
- helped with the learning;
- reviewed the current change control process
- developed principles to incorporate Change Management into the earlier lifecycle of development and projects
As away-days can be expensive from a time, resource and cost perspective, a series of follow up meetings – lasting no more than an hour -were held over the next couple of months to review, improve and ratify specific changes to the process.
From Change Control to Change Governance
After the workshops were complete, the main principle was that Change had a start point, a delivery mechanism and an end point. From this, we developed a Framework to incorporate processes that were involved with these principles, namely:
The Start Point
- RFC Review – a mechanism to initially capture customer demand and suggest its feasibility, size and so on
- For large changes requiring effort this could become a formal project following the established Project Management process
- For smaller changes, we would look to group these together as releases.
- It is possible for projects and releases to overlap for delivery – but this is a subject for another time
The End Point
- Before implementation of any change to the live environment, the existing Change Control process had to be followed to obtain final approval.
- We also use the opportunity to realise the following improvements including:A new CAB structure with specifically invited attendees and a new agenda format
- A Risk & Impact Calculator to help score changes in terms of “Technical Risk” and “Service Impact”
- The increased use of Standard Change Templates
Underpinning Strategies & Processes
- A broad summary of the areas that need to be engaged or considered as part of any Change-related delivery.
Sealing (and documenting) the Deal
This is arguably the most important point, without engaging people; the re-launch was never going to get out of the starting blocks. The key points and activities to consider were:
- Presenting back to Senior and Middle Management the key points and what they have gotten for committing time and resource
- It’s important to treat changes to processes like any other change – I took this to CAB for review and approval before implementing and communicating the framework. After all, you cannot expect people to follow processes if you do not lead by example!
- Tailor the communication to your audience – for me, I identified three types and the level of information they needed:
- Partnering and Project Management – a group consisting of Business Relationship people – received a strategic overview of the Framework that incorporated their processes
- Implementers – typically technical staff involved in developing, raising, assessing and implementing changes – received an overview the framework, their responsibilities within the process and the changes to Change Control
- Impacted teams – (teams impacted by change implementation e.g. Service Desk) –received a high level overview of the framework, how/where to find information about upcoming changes and why it matters
- Documentation needs to be succinct and will have varying levels of detail, specifically for us, we produced:
- Change Policy – the overarching document covering the Framework, the processes and the “rules of engagement”
- Processes that were straightforward documents combining the high level process flows with simple procedures for each step required. Areas included:
- RFC Review – an initiation process owned by the IT Business Partners to bring customer’s request for change to receive a quick review or ‘first pass’ by Technology experts in terms of strategy, estimates and being worthwhile.
- Project Management – the formal methodology for delivering projects
- Release Management – for combining and scheduling the build, test and deployment of changes
- Change Control – to implement a change to the production environment.
- Training Guide – short and to the point – these were given as small A5 hand-outs to staff involved at different levels of the process.
- Don’t let Change Management become restricted to ONLY the production environment. It’s important to protect it, but it’s even more important to help plan and facilitate change at the beginning rather than the end.
- There is more than one “CAB” – keep in mind that throughout the lifecycle of a change it will be reviewed, rejected and approved many times at the Business, Project and Technology levels before it is ready for implementation.
- Play the game – as a Change Manager, you will be expecting people to follow the rules for technology, and it’s only fair you do the same for process.
- Make sure you baseline – be pragmatic about what you can achieve and be transparent about what is in scope. For example, we started off with formal Change Control for a couple of years, then brought in the Framework and are now working on linking it to Release Management.
- Get everyone involved – by engaging people at the beginning, it makes the improvement process a lot easier – especially when’s “for them, by them”