This three-part series of IT service management (ITSM) articles is about the new thinking in change management. I know Axelos changed the name of the ITIL 4 practice to “change enablement,” but I still like to call it “change management” for consistency.
In this and the next two articles, I’ll offer a practical and pragmatic approach to change management in the new business and IT worlds. Starting with the new thinking in change management.
This is the first in a three-part series of #ITSM articles about the new thinking in change management that offers a practical and pragmatic approach to managing change in the new business and IT worlds. Take a look. Share on XThe Purpose of Change Management
I LOVE CHANGE MANAGEMENT!
I love it because it helps people to smoothly implement their IT changes into production, to better serve their customers. I love it because it allows people to easily ensure they’ve considered all aspects of a change, without having to reinvent the whole change plan each time. I love it because it removes the need for people to have to know what else is happening within the enterprise at the same time as their change.
Yet I often hear that change management is:
- Too bureaucratic
- Very inflexible
- Has long lead-times
- Takes up too much time
- Designed to prevent changes.
When I hear this, I know that the change management practice in question has been designed and implemented with the wrong purpose in mind. The new thinking in change management helps with this.
ITIL 4 and Change Enablement
ITIL 4 has reemphasized the mantra of ITIL v2 change management:
“Maximize the number of changes being implemented, while reducing the risk to the production (service) environment.”
For some organizations, the focus has been on reducing the risk and not maximizing the number of changes. The result is that change management becomes cumbersome, bureaucratic, and much-maligned (as called out above). Instead, the effort involved in processing a change should be proportional to the size and complexity of the change, and a small element of the overall effort of the change.
Keep in mind that the main objective of change management is to provide a platform and service that helps developers to maximize their throughput of changes. If developers don’t see your change management practice as a beneficial service to them, then your change management practice has been implemented incorrectly. They’ll thus be tempted to circumvent the process.
If developers don’t see your change management practice as a beneficial service to them, then your change management practice has been implemented incorrectly #ITSM #ITIL Share on XTo make it work, there are some guiding principles for a good change management practice that echo the guiding principles of ITIL 4:
- Keep it simple and practical
- Define what is a change (and what is NOT a change)
- Focus on getting beneficial changes implemented, not on prevention (focus on value)
- Have the right stakeholders involved at the right time (collaborate and promote visibility)
- Share the knowledge about what is happening (think and work holistically)
- Be Agile, be responsive to change users (progress iteratively with feedback).
Design your change management practice with the change maker (customer) in mind. Keep it simple with as little human intervention as practical.
Yes, these are remarkably similar to the ITIL 4 guiding principles for all practices!
This new thinking in change management should not be a surprise.
You need to design your change management practice with the change maker (customer) in mind. Keep it simple with as little human intervention as practical. #ITSM Share on XChange Management for Agile Development
The scope/content of a change might vary through its development. This is OK. Changes must be adaptable to the customer and environment. Some changes best suit a waterfall approach and others an Agile development approach.
Change management is about managing the impacts of change implementation in a controlled manner. So long as the external impacts of the release are managed, limiting the possible negatives to areas outside of the change, then the change is under control.
Allow the content of a change (release) to vary, adding and removing user stories, and focus only on the envelope in which the change is implemented. For example, does the modification of stories within the change require a change in:
- Resources required to implement?
- Security considerations?
- Timing of the implementation?
- Other external factors?
If not, then the Agile development team should have the freedom they need to adapt to flexible customer demands. Let the DevOps flows – with automated testing, review, distribution, deployment, and rollback – handle the impacts within the scope of the change.
Use a standard change (or standard request) integrated into DevOps deployment automation to manage each Agile release. Look to have minimum human involvement in each change, yet all the tracking and testing required to deliver a reliable product.
Normal changes – requiring planning, communication, design, unique testing, change advisory board (CAB) attention, etc. – should be applied only when the method of delivery is to be modified. Consider the means of automated deployment to be a service in itself.
Changes are only used when the way the service is being provided is to be modified. Repeated use of the deployment, as intended, should not be a change requiring significant management.
This new thinking in change management provides the required flexibility without losing any control.
Take a look at your current change management practice. Is it providing a smooth mechanism for the rapid and consistent implementation of changes? #ITSM Share on XAgile for Change
Take a look at your current change management practice. Is it providing a smooth mechanism for the rapid and consistent implementation of changes?
What is the Epic? The picture of change management working perfectly. Build a backlog of improvements to take you from where you are now, to where you need to be. Apply the Agile principles to your change management practice to move it in the right direction.
Don’t rigidly define what the endgame will be for your change management practice. Start the journey, involve the customers (in regular showcases), and let the practice evolve. You may be pleasantly surprised as to the direction it takes.
Don’t rigidly define what the endgame will be for your change management practice. Start the journey, involve the customers (in regular showcases), and let the practice evolve. #ITSM Share on XThe new change management practice is likely to take fewer resources than are currently engaged, as well as less time. What evolves is likely to be a Lean process with as much automation, and as least human intervention, as practical.
Start with the 7Rs (or 8Rs) of change management, the bare basics, as an MVS (minimum viable service). Begin with a simple change management process, and work with your customers (the change makers) to enhance the process for them. Have Showcases where you listen to their suggestions, and apply these enhancements in frequent, small releases to the process. Work with them to determine which suggestions will be released in which Sprint delivery.
In IT terms, these change-makers can be application developers, infrastructure managers, operations, networks, security, business, even customers of the business services. The change management process grows and matures in line with their needs. Remember the purpose of ITIL was to align IT services with business needs. Think to align the change management service with the needs of the users (service developers).
This new thinking in change management will avoid the trap of a bureaucratic practice that does not deliver on value.
That’s it for new thinking in change management. Please look out for the second article in this three-part change management series on ITSM.tools. In it, I’ll be covering some of the guiding principles I mentioned above in more detail. In the meantime, please express your opinions or ask any questions in the comments section below.
Gary Percival
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]
