The 2011 version of ITIL introduced the lesser known change evaluation process. It’s a great addition, and I haven’t seen a lot written about it.
The first thing to know is not every change requires a formal change evaluation. It’s intended to be used primarily for major changes, where the complexity and scope of the change warrants careful and formalized evaluation.
Change evaluation comes with its own Seven R’s – a handy same-letter list that’s easy to remember, and can help make sure we’ve explored the most common sources of issues with proposed changes.
Here’s the seven R’s:
The list is not intended to be a set of required fields on the RFC form; modern IT systems are far too complex. It’s intended to be used in the evaluation process to trigger deeper thinking about a proposed change and uncover potentially hidden sources of risk and unintended consequences.
The R’s are a great start, but we really need to do a little more serious detective work. Remember, change evaluation is reserved for major changes, where there’s often a great deal of complexity and high visibility.
Let’s put on our detective hats, and take a closer look.
Who raised the RFC is a good place to start. It goes well beyond who’s filling out the form or taking administrative responsibility for the RFC. Change evaluation needs to know the role and business function of the requestor.
If it’s IT, what functional unit? Why was it raised by this particular person or group?
If customer, does the requestor represent all user groups of the service? Has the requestor worked with relationship management and/or the service owner? Was it raised by a person who was directly impacted by a recent incident?
Understanding more about the role and context of the requestor helps change evaluation understand the bigger picture.
Again, these are supposed to get you thinking deeper about the proposed change.
An analogous question would be “What are you hoping to accomplish with this change?” This one can be tricky because you need to get to the question behind the question. Sometimes RFCs come on the heels of a significant incident. Some changes are proactive changes to avoid a potential incident or problem (such as keeping technology current).
Other changes are raised to address very specific business needs. Some reasons are urgent and pressing and others are related to longer term releases or system upgrades.
The question of what you hope to accomplish helps identify what specific outcomes are anticipated, so change evaluation can help determine if the RFC is likely to deliver them. This question should be answered in plain, unambiguous language that makes very clear the purpose of the proposed change.
In my experience, this question can unearth significant issues. In the evaluation process, it may be discovered that there are differences in understanding the reason behind a change. If the request isn’t clear, it’s harder for the change to be successful in meeting the desired outcome(s).
This one tends to get forgotten because it’s hard to answer. ”Return” here is talking about business value. It too should be answered in plain language. An example would be: “RFC will deliver new order processing functionality that will reduce order processing time by 20%”.
The “return” should be specific and measurable, and from the perspective of the business. If it’s an infrastructure RFC, what risk or impact is it seeking to mitigate, and what’s the value of the avoided risk?
Identifying risks associated with change requests is critical for an effective change program. The risks here are not limited to technical and infrastructure risks – things like adding firewall rules may block application-required traffic.
When identifying risks, keep a business-impact focus in mind:
There are a number of formal risk management methodologies, such as ISO 31000 and Risk IT. If your company uses a formal methodology, that would be a good place to start.
Otherwise, a simple and common approach is to create a risk matrix, where risks are identified and each rated on the probability of its occurrence, and impact, if it does.
With this simple matrix, it’s pretty easy to see that you should focus most of your attention on the critical and high risks, some on the minimum, and little on the low risks.
One thing to keep in mind is that all changes have some level of risk. It’s not helpful to either under or over state risks. Both can have disastrous impact.
This is where you identify all resources required for a successful change implementation. This includes everyone needed to build, test, implement, communicate, support, or roll back the change.
Similar to resources, the “responsible” question seeks to ensure there are clearly established and understood roles and responsibilities. A RACI chart may be helpful (see What’s a RACI chart and how do I use it?). This is a critical step that helps eliminate assumptions and avoid misunderstandings.
This is where we seek to understand how the change in question may impact or be impacted by other recent or planned changes. How do the service components fit together?
Beyond the scope of this article, good configuration management and change modeling can be really helpful in understanding complex relationships.
Out in the real world, we all know some changes are more risky than others. It’s up to you to determine how deeply you need to go in evaluating a proposed change. If a change is large or complex or significant risk may be present, change evaluation is warranted. Changes that involve critical business functions or significant business process changes are excellent candidates for formal evaluation.
It’s been my experience that just when you think a change is benign, you get hit with something you didn’t think about, but maybe should have.
So, let me suggest a few additions of my own – reality, respect, results, and repeat:
This is where we take a quick reality-check. Yes, 12 Ninjas might drop from the ceiling and cause a large impact. But, in reality, how likely is it to happen? Have changes similar to the one under review been successfully implemented? Reality can be an important data point to help strike the right balance.
Data is a great reality check. Historic change information can be really helpful to help determine where additional evaluation is warranted and where it would be unnecessary. In reality, some change types, and components are just less problematic. Likewise, some that should be harmless no-brainers can cause big problems. Use reality as a guide.
The Change Advisory Board (CAB) is comprised of your best subject matter experts – those who have deep knowledge and are respected for their expertise and track record. Respect their experience and knowledge. When it comes down to it, change evaluation depends on people who are good at what they do.
Remember to use the R’s as a reminder to explore all aspects of a change. Effective change evaluation is core to successful service delivery and business value. Use the seven R’s of change evaluation to make sure you’re covering all the bases. Also, take a look at the extra ones I’ve suggested.
How about you? What additions would you make? Do you have any that you’ve found helpful?
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.
