About the Knowledge Base
Search all the Knowledge Base
Testimonial: I have found that the new HDAA Knowledge Base reduces the time it takes me to research industry stats & reliable information for the ITSM sector. It’s easy to use search functionality encompassing KCS principles, helps to filter & tailor my searches more accurately & there are numerous new services now available through the website. Every time I return to the site there is new information published. Very impressive.
Chris Powderly, Support & Services Manager, Allens
supportworld , service management , change management , ITSM
No Result Found
Change management is a critical component of keeping systems and applications stable in the face of continual business change and ensuring people are aware of changes being deployed. However, many organizations struggle to find the “sweet spot” between the pace of today’s business and the need to manage risk associated with fast-paced change.
The answer lies in having a strong process base combined with using today’s service management applications to their fullest capabilities. This is truly a situation in which success lies in combining people, process, and products to create an overarching process that relies on automation to ensure that approval comes from the right-sized group of people, based on potential risk.
It’s worth laying a little groundwork before diving in. The ITIL® Service Transition book defines the CAB in terms of its role in reviewing, authorizing, and prioritizing changes to be made and even talks about the fact that the board could be virtual. Regardless, many organizations choose to leverage the CAB as less of a strategic body, advising on what work should/should not be performed and more tactically, just before deployment of a change to the production environment.
The approach described in this blog will not work for everyone, as several tool pre-requisites are needed before tools can be used to automate some of the required decision-making needed for this approach to succeed:
This approach is based on change risk and well suited to environments where DevOps is practiced: the main concept is that when you lower risk of making a change, you also lower the required approvals and due diligence needed. In this environment, all that’s really needed is the business approval to push. In fact, in a fully automated deployment environment, where approval from the business kicks off the deployment, change management should be satisfied by having the deployment tool open a change record, check for conflicts against approved scheduled changes, and start the deployment as soon as no conflicts exist. Automation can push any CI changes to the CMDB and update and close the change at the successful completion of the deployment. If a conflict is found, the change can begin as soon as the conflicting change is complete (assuming the conflict is one that would prevent successful deployment, such as network or server maintenance).
Moving beyond this will take an understanding of the current state of quality checks and planning, along with the level of communication that occurs within the organization as changes are being planned, built, and made ready for deployment as well as the amount of coordination that teams employ when performing daily work. Good communication and coordination in the culture make it easy to move towards streamlining the final approvals to deploy a change. Ideally, if teams work well together from conception until deployment, approval to deploy should be no more than a scheduling exercise.
To engage in the program of streamlining, the organization needs to review change approvals first, establishing appropriate levels of deployment authorization based on risk from very low to very high. Security review/approval may also be needed for certain types of changes and this should be able to be derived by the affected configuration items and their compliance needs or by a combination of these factors and the change category/type.
Conceptually, the next step is to build the approvals needed into the automated approval capabilities of the tool and begin to make subtle changes to the process and culture:
With these changes to the approval process, there are several adoption fall-outs that should be considered in planning the adoption and cultural shift needed to support the concepts on which modernization is approached:
With these steps in place, the new change review/approval process can be adopted and the need for weekly meetings significantly reduced. The new approval rule is simple:
The aspect of this blog that’s most important is killing the weekly CAB concept and returning to the concept of the CAB as a strategic board that reviews changes before work begins, ensuring alignment with business initiatives. The issue of the pre-deployment CAB is not the CAB structure, but rather the lack of agility it causes when everyone needs to wait for the meeting, and where missing deadlines causes changes to be deferred. With a daily CAB, the concept of expedited and emergency changes starts to disappear as well: the only reason for an emergency change is to restore service or for a repair that cannot wait until the next morning’s CAB cycle. Expedited changes are no longer required because changes can be approved online or daily.
So do we still need a CAB before deployment? It would be great if the answer became no, that it is eliminated as a result of great teamwork and communication. To get there, a culture of advance planning and discussion amongst deployment team members is needed. Until this happens, moving towards a short daily meeting achieves the benefits stated above: no need for expedited changes due to the ability to get a change approved online (yes, the change owner may need to talk to approvers and gain approval quickly but they no longer need a CAB meeting or expedited approval process) and, even more important, the ability to move quickly when business needs demand it.
The business benefits of this approach are tremendous, beginning with the ability to move quickly and respond to fast-changing business needs. It also starts to remove many peoples’ objections to the change process, which in many organizations lands like unnecessary bureaucracy. Additionally, it offers support benefits by requiring earlier planning and transition, along with improved communication.
Will organizations adopt this method? YES! I know of several who operate in processes that are very close to this, with the idea of taking it further. Additionally, as I propose it to clients, they understand it, and if not ready as they are deploying their new service management tool, they see it as a great step in their maturity.
Is this method controversial? YES! My last blog that asked why we need a CAB generated some great discussion via comments (many of them questioning my sanity). So, if you have thoughts, reach out to me, @msitsm on Twitter!
This has been a continuing area for heavy discussion with the DevOps and Agile community touting their methods as improved over ITIL because they are less bureaucratic. But at the end of the day, it’s not the frameworks that cause the process to become more bureaucratic, rather it’s the people managing them. The most important takeaway from this blog might be to remember why change management is performed: to support the outcomes needed by the business and to minimize risk while doing so. Automating code release along with early communication and planning go further to lower risk than the hoops many organizations make people jump through to deploy a change.
Phyllis Drucker is an ITIL® certified consultant and information leader at Linium, a Ness Digital Engineering Company. Phyllis has more than 20 years of experience in the disciplines and frameworks of IT service management, as both a practitioner and consultant. She has served HDI since 1997 and itSMF USA since 2004 in a variety of capacities including speaker, writer, local group leader, board member, and operations director. Since 1997, Phyllis has helped to advance the profession of ITSM leaders and practitioners worldwide by providing her experience and insight on a wide variety of ITSM topics through presentations, whitepapers, and articles and now her new book on the service request catalog, Online Service Management: Creating a Successful Service Request Catalogue (International Best Practice). Follow Phyllis on Twitter @msitsm.
No Result Found
- Contact Us
- IT Membership
- Support Centre Association
- Comparison Guide
- Price Guide
- Membership Conditions
Training & Workshops
- Training Courses
- Recent Workshops
- Cancellation & Transfer Policy
- ITIL Training
- ITIL Foundations
- Support Centre Consulting
- Service Desk Consulting
- Help Desk Consulting
- Media Kit
- Update your details
- New account
© Copyright HDAA. All rights reserved.
HDAA - Energising the Service & Support Profession
Help Desk Association Australasia Pty Ltd trading as HDAA
T: 1300 130 447 T: +61 (0) 2 9986 1988 F: +61 (0) 2 9986 1330
E: firstname.lastname@example.org W: www.hdaa.com.au A: PO Box 303, Turramurra NSW 2074 Australia
ABN: 20 088 292 755
Our Services: ITIL | ITIL Training | ITIL Foundations | IT Membership | Service Desk Association | Support Centre Association | Support Centre Training | Service Desk Training | Help Desk Training | Support Centre Consulting | Service Desk Consulting | Help Desk Consulting
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
DevOps Foundation®, is a registered mark of the DevOps Institute.
HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.
KCSSM is a Service Mark of the Consortium for Service Innovation™.
Apollo 13 Insignia image by 'NASA Johnson' (copyright-free) June 2017 via https://www.hq.nasa.gov/alsj/a13/images13.html
WEB DEVELOPMENT PARTNER