ITSM Change Management: Establishing a Regular Cadence for Change

Details

Published: Tuesday, November 08, 2022 07:21

By Jon Bergman and Lonnie Sanders III, CIOPS Associates

You may not have realized it, but we are just weeks away from the annual celebration known as the “Festival of Enormous Changes at the Last Minute”! While you are contemplating how you plan to mark this exhilarating occasion, we’d like to point out something that should be obvious. When it comes to the Change Management aspect of IT Service Management (ITSM), your end users are never going to see “enormous changes at the last minute” as a cause for celebration. 

Although change is never easy, if you want to make IT changes easier for your end users, the best approach is to establish a regular cadence for change. Here are some of the things that we have seen are most helpful in this area…

Prioritize high-impact business functions 

Focus on what is most important to the business, and be wary of prioritizing work for senior leadership or for the “squeaky wheel” user. For example, for retail businesses the most important user communities are store operations and distribution/fulfillment centers. For a service company, the most important user communities are front line users such as customer service representatives. 

Clearly communicating to business users where they are in terms of business priority will help set user expectations.

Have regularly-scheduled deployment days

When you’re working on changes that primarily impact a given department or business function, a consistent change cadence can really help the change management process. When non-emergency changes that impact your bricks-and-mortar stores are only made every other Wednesday at 8:00 pm, your store managers and teams know what to expect. 

Consistency in scheduling is also helpful for your deployment teams and user testing and validation teams. 

Bundle your changes

Bundling changes is a common strategy for releasing packaged software products, and it can be leveraged for other organizations as well. When bundling changes, use consistent and clear nomenclature that distinguishes between point releases (e.g., going from version 1.1 to version 1.2) and major releases (e.g., going from 1.1 to 2.0).

Although waiting periods for bundled changes can be longer than a single release, by bundling changes that are sufficiently regression and QA tested, you will ensure that high quality software is moving into production. Be sure that your documentation indicates what is in a change bundle and what benefits the users will realize.

Establish “freeze days” or “freeze windows” 

Does your business have key business events, such as busy seasons or month-end or year-end financial closings, during which the impact of a change or a poor deployment would have a significant impact on the business? How about times of the year, such as holiday periods, when you are unlikely to have sufficient staff in IT to support a change, or sufficient business users to conduct quality assurance activities to help validate the change? If so, these would be good candidates for “freeze days” or “freeze windows” during which everyone agrees that no changes will be made. 

Establish preventative maintenance windows

As you know, your systems must all be adequately maintained. Patching and completing regular updates to production software or hardware are both normal parts of business, and need to be regularly planned for. While these are typically “IT-centric” changes that benefit your IT organization more than your end users, they are still essential for supporting business operations.

In most cases, you can establish preventative maintenance windows that are outside of key business activity hours. Then, ensure that when you are measuring system availability, you extract preventative maintenance windows from those measurements.

Create a backlog of changes

Often, changes cannot occur at the speed of business. Because this is not unusual, this is one of the reasons why setting expectations with users is so important.

Good product teams have a well-defined and prioritized backlog of changes or enhancements that they want to make. If users request something and you let them know that it is being put in the product backlog (which you can refer to as a “to-do list”), at least they will feel that they are being heard. What if a decision is made that IT will not be implementing a suggestion or request, for whatever reason? That needs to be communicated as well.

Keep emergency changes to a minimum

In spite of your best laid plans, there will always be situations where emergency changes must be completed very quickly. Security issues, significant product defects or bugs and other problems that require near immediate action simply cannot wait until the next regularly-scheduled deployment. When these occur, be sure that they are communicated clearly and quickly to business users.

You should also track the type of emergency changes being made. If a particular organization or product team is conducting an inordinate number of emergency changes, this may reflect a larger, more systemic issue. Emergencies happen, but they should not be a frequent occurrence.

Conclusion

A key aspect of change management is the recognition that change must be managed. Establishing a regular cadence for change makes things easier for everyone involved—and ensures that you will not be making the type of enormous changes at the last minute that are not likely to go well. Plus, of course, you also need to communicate these changes in a way that avoids confusion and conflict, which was the subject of our last post.

Need help with any aspect of the ITSM process? Give us a call. This is one of our areas of expertise.

Contact CIO Professional Services

About Jon Bergman – CIOPS Associate Consultant

Jon is a business-driven executive focused on near-term results and positive outcomes for his clients and customers. Jon has over 40 years of diverse experience as a CIO, management consultant and business owner. 

About Lonnie Sanders III – CIOPS Associate Consultant

Lonnie Sanders is a program/project leader with exceptional leadership skills and technical knowledge. Clients appreciate his extensive experience leading cross-functional and multi-site teams to produce successful project results in diverse industries and domains.

About CIO Professional Services

Based in the San Francisco Bay area, CIO Professional Services LLC (CIOPS) is a top-rated Information Technology (IT) consulting firm focused on integrating Business and Information Technology. Our consultants are all hands-on executives who are veteran CIOs and Partners of Big 4 consulting firms. Companies come to us seeking assistance with their information technology strategy as well as for interim or fractional CIO / CTOs, and negotiation and program management/project rescue assistance.