We can all agree that ITIL-aligned policies, processes, and procedures have been shown to produce significant day-to-day operational improvements to an organization. IT Change Management, in particular, is a critical and necessary function that requires continual improvement, because failed changes can result in a whole host of issues including increased infrastructure risk, unexpected costs, damaged service desk credibility, and ultimately, loss of customers.
Despite the clear benefits of an effective Change Management process, many organizations that seek to implement it don’t nail it on their first attempt—or even their second attempt, for that matter—because they fail to anticipate and plan for the common hurdles that stand in the way of success. Over my 40+ years in the ITSM industry, I’ve helped many organizations take a step back to look at the bigger picture and, based on their goals, define their optimal approach for implementing IT Change Management. Based on this experience I’d like to share with you some of the most common pitfalls organizations encounter that cause their Change Management initiatives to flounder. Armed with this knowledge, and a little bit of perseverance, you’ll be prepared to tackle Change Management head-on!
Tweet this: IT Change Management is a critical and necessary function that requires continual improvement.
Here are the five most common mistakes organizations make—and you should seek to avoid—when defining and implementing their Change Management process.
1. Confusing IT “Change Management” with “Change Submission”
Some organizations believe they are establishing a “Change Management” process, but in reality, they are simply implementing a “Change Submission” process. The latter represents only the first step in the change process: documenting a change plan prior to implementing it. A true Change Management process, however, involves planning, categorization, building, testing, validation, and authorization. Essentially, the key difference is akin to asking for forgiveness instead of permission. While confusing these concepts is an honest mistake, it can be a detrimental one resulting in late changes, change clashes, change delays—and ultimately, change failure.
2. Poor initial risk assessment
Make sure you take the time to properly define the risk levels associated with any given change. Most organizations use a grid that evaluates the business impact of the risk (should it occur) against severity of the outcomes. You should consider adding a “direct lifeline” that enables you to back out of any change that’s gone awry, re-assess the situation and business impacts, and create a new roll-out plan. It is often helpful to consult with enterprise managers for their own risk assessments to ensure a level of accountability, especially for advanced changes that could lead to greater business risk.
3. Relying on home-grown solutions
While the digital era continues to thrive, there is no excuse for not taking advantage of the abundance of good, affordable technology that’s available to support successful Change Management. While it can be tempting to use a home-grown solution, this approach generally makes it impossible to determine the overall status of the changes progressing through the change cycle, which, in turn, makes it virtually futile to evaluate the potential impact any given change or series of changes may have.
4. Opting out of the change process
All too often IT teams effectively “opt out” of the change process by either working around the process or marking every change as “urgent.” Obviously, the former scenario defeats the whole purpose of Change Management in the first place, while the latter means that more standard (yet still important) changes fail to be addressed with the appropriate amount of attention and rigor. The end result? Important changes fall through the cracks or fail entirely.
5. No proof that change delivered promised results
This may seem an unlikely pitfall, but many changes are proposed and implemented with exaggerated promises of organizational savings or other benefits. While it’s often human nature to overstate the potential benefits in order to get a change authorized, it is a dangerous policy to live by, and it is the Change Manager’s responsibility to demonstrate proof of these benefits after the change has been completed. I recommend evaluating success based on three dimensions: customer satisfaction, resource impact, and cost savings. Specifically, was the change submitter satisfied with the implemented change? Were there any staffing or resource issues that arose? Have the anticipated savings been achieved? Only when these questions have been answered to their fullest should a change be closed.
These challenges are just the tip of the iceberg for many organizations that don’t have a genuine change management culture. The good news is that there are plenty of ITIL consultants, courses and publications designed to help you plan and build an effective change management process. In addition, any reputable Change Management software will have a change process built in—or at least provide the ability to build one.
To learn more about best practices relating to Change Management, check out Cherwell’s Essential Guide to ITIL Change Management.