ITIL

When Should ITSM Change Management Start?

- 812 views
Stuart Rance

6 min read

ITIL says that IT change management should evaluate changes before anyone starts designing or building them, but most organizations don’t start change management until they are ready to deploy the change. I don’t think either of these is right.

When Should ITSM Change Management Start?

Most IT organizations have a process for managing IT changes. This usually involves taking steps to ensure that the change won’t cause things to go horribly wrong. To initiate change management someone logs a request for change (RfC), and the change is then reviewed to ensure that appropriate testing is carried out, that security and other risks are considered, that compliance and other constraints are taken into account, etc. The change management process also schedules changes – to try and prevent conflicts – for example, where one change involves the use of the same resources as another.

One big difference I see between organizations is the timing of the RfC, the point in the change lifecycle when they expect an RfC to be raised.

Most of the IT organizations I see don’t raise an RfC until after they have built and tested the change, and it is at this point that the change management process kicks in to evaluate the change before authorizing deployment to a production environment.

However, according to ITIL (the world’s leading best practice framework for IT service management), organizations should be raising an RfC before anyone designs or builds a change, allowing change management to consider the costs, risks, and benefits before authorizing design activity to proceed.

So which of these is right? What should you do?

You probably won’t be surprised to learn that I think both approaches are wrong. Raising an RfC after the change has been built is far too late to be helpful; and raising it before anyone starts working isn’t going to happen because most organizations have other processes for making investment decisions, they don’t use IT change management for this.

Who Makes Investment Decisions?

Every organization I work with makes investment decisions, but very few of them call this IT change management because investment in IT changes does not take place in a vacuum. They evaluate all investment opportunities, including IT initiatives, to ensure they are aligned with the goals of the organization, and to prioritize them with other possible investments. These investment decisions are taken by different people in the organization, depending on the type of investment:

  • For major investments, decisions are usually taken by senior management.
  • In some organizations, IT investment decisions are managed by a program management office, that prioritizes and evaluates initiatives, and assigns resources.
  • For routine software changes, decisions are often made by software development teams as part of their backlog management.
  • Other investment decisions might be delegated to a manager who holds the budget that will be invested, or who leads the team that will have to do the work.

In other words, it’s simply not practical to ask most organizations to raise an RfC before deciding to invest in IT changes, and it simply isn’t going to happen.

But It Doesn’t Have to Be Either Or

In most organizations IT change management is not engaged until after the build and test is complete and someone wants to deploy the change. This results in a very inefficient process where everything stalls while change management evaluates the work that has been done and decides whether the change is safe to deploy. Change management is then viewed as an obstacle to change and not a change facilitator.

But if change management is not involved before investment decisions have been made, and raising an RfC is done after the design, then build and test is inefficient and leads to friction. So what can we do?

The trick is to stop thinking about it as an either/or issue, and instead to think about raising an RfC as early in the change process as you practically can.

The Benefits of Triggering Change Management Early

The problem that faces any change management process is quite easy to understand. How do we evaluate changes fast enough to avoid unnecessary bureaucratic delay, but thoroughly enough to avoid compromising security and integrity of IT services?

Some of my previous blogs offer ideas for making change management more efficient:

I have written about how the change management process can be made more efficient, by using automation, standard changes, and change models to optimize the flow and reduce contention for change management resources. I have also emphasised that evaluating a change does NOT mean you have to arrange a change advisory board (CAB) meeting with lots of managers sitting round a table to discuss changes they may not even understand. Instead, you identify which changes need authorizing, how they need to be authorized, and who has the authority to authorize them.

But even the most efficient change management process takes time, which is why one of the best ways to reduce friction, and reduce delays, in change management is to submit the RfC very early in the change lifecycle.

Even if you don’t use change management to make the investment decision, and even if you don’t yet know when you’re going to be ready to deploy the change, you can submit an RfC with the information you have as soon as you start on the design and build work.

When you do this, you give the change management team time to:

  • Think about scheduling and resource conflicts without injecting any delay into your deployment.
  • Identify the correct change authority before a decision is needed. (As described in some of my earlier blogs, and mentioned above, that change authority might be a peer programmer, or a software development manager, or an infrastructure manager – it doesn’t always need to be a CAB.)
  • Allow appropriate change authorities to carry out most of their evaluation before you are ready to deploy, considering questions like: Is the test environment appropriate? Are there any regulatory issues that need to be considered? Have the correct security controls been identified?
  • Allow the change authority to provide input to the people building and testing the change in plenty of time for it to be helpful, rather than after the work is finished and people are impatient to deploy the change.

Ideally, regardless of how you initiate changes, and how the resource and funding decisions get made, you should design a complete value chain that takes ideas and transforms them into value for your customers.

Then automate as much of this value chain as you can. This could include automatic submission of an RfC at the appropriate time, with no need for anyone to fill in a form because all the information is already available in the tools that automatically submit the RfC. Most of the RfC evaluation can then be carried out by the tools, and any manual review that is needed can be carried out a long time before anybody is ready to deploy. That way you get the best of all worlds. Every change is evaluated to ensure that it meets your organizational goals for security, risk and compliance, but change management doesn’t delay any deployments.

In Conclusion

What triggers an RfC in your organization?  Does it happen early enough in the change lifecycle? And when it does happen, does it help you to get things right, or is it just a gatekeeper that delays deployment? Have you thought about how you could use tools and automation to reduce delays, and ensure you meet your goals?

As always, please let me know if you try any of the ideas in my blogs.

What did you think of this article?

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

Did you find this interesting?Share it with others:

Did you find this interesting? Share it with others:

About

the Author

Stuart Rance

Stuart is an ITSM and security consultant, trainer, and author who has worked with clients in many countries, helping them create business value for themselves and their customers. He was the author of the 2011 edition of ITIL® Service Transition and lead author of RESILIA™ Cyber Resilience best practice published in June 2015. Now that his children have all left home, he has plenty of time on his hands for contributing to our blog – lucky us!

We respect your privacy. By continuing to use our site, you agree to our privacy policy.

SysAid Reviews
SysAid Reviews