Change Risk Assessment

[mtbchangelady]

We implemented our new (ITIL compliant) Change Management system earlier this year and it seems to be well received. Although we're now finding that a larger than anticipated percentage of Changes is falling into the "low risk" range, and consequently do not require CAB review. In light of this, we are reassessing our Change Assessment questions to help the Change user obtain an appropriately risked Change.

We currently have 4 criteria that determine if the Change is low, medium or high risk. They are:

1. Application/Component being impacted
2. Duration of downtime
3. Answer to question: What is the planned impact of the Change?
4. Answer to question: What is the complexity of the Change?

The change user is asked to take into consideration the following questions when determining What is the planned impact of the Change?:

What is the impact to the staff?
Will a large amount of people/customers be impacted if the change fails?
Could there be a negative financial impact if the change fails?

The change user is asked to take into consideration the following questions when determining, What is the complexity of the Change?:

How many departments are dependent on supporting this Change?
How well has this been tested?
Is this a change to support a large project?
Will it be implemented in phases?
How long will it take to verify success of the implementation?

My struggle is to come up with better questions that can be answered individually and a better scoring system behind the scenes to (hopefully) accurately depict a High, Medium or Low risk Change.

[llondra]

I'm struggling through the same thing right now - developing a change risk assessment. I used an example from the IEC site provided by Ameren of their questionnaire and worked with our IT managers to adapt it for our use.

Our questionnaire asks 7 questions and each question has various answers with an associated risk factor. After answering all questions and selecting a risk factor for each, all of the the risk factors are added for a total sum. The total sum of risk factors correlates to a final "Risk Rating" (Minimal, Low, Standard, Significant, Major).

We did some testing on implemented changes and using the ol' "yeah, that feels like a xxxx risk" method compared that to our results from the worksheet. The resulting risk rating seemed to hold up.

It's very basic, but it's supposed to be. We've never done any kind of formalized risk assessment, so I wanted very much something that was quick and easy. We've had it in a "pilot program" that is due to end next week - we'll see how it goes. I'm hopeful....

Here is our list of questions:

1. How many services rely on the device(s) that will be impacted by this change?
2. What is the criticality of the above service(s)?
3. How many production users could be affected?
4. How will implementing this change affect production availability?
5. How important is the impacted device to production users during the planned implementation time?
6. Is coordination or testing required among other groups (e.g. IT team, developer, end user, etc.) to implement the change?
7. What is the estimated time to back out the change?

[mtbchangelady]

Thanks londra,

The questions you've listed are pretty much the same ones we're going with, but we've broken them into categories:

Planned Impact of Change
Potential Impact of Change
Complexity of Change

Thanks for your feedback, I'll let you know how it goes!

[JoePearson]

It sounds like you are concerned that these (larger than anticipated percentage) low risk changes are not all really low risk - the change users are being too optimistic. Is that right?

Developing more levels of questions around risk and impact can help honest and alert users get more realistic assessments. But you may (I won't say will!) have some who want to hide the risk or simply aren't aware enough to assess them properly.

One way around this is to certify or accredit the change users - someone with a good track record would be entitled to put through low-risk changes, others would have extra checks (possibly even requiring a CAB review) imposed until they became reliable. Attendance on an internal training session could be one prereq (and less sensitive than "we don't trust you yet").

I don't think I've seen an organisation apply this across all users, but I do know some that flag some change requesters/owners as being unreliable.

[mtbchangelady]

Joe,

You're right, I am concerned about number of changes that are rated low risk in the eyes of the Owner, but CAB and I think otherwise.

"Flagging" the repeat offenders (or maybe "flogging" would be more appropriate!) and rewarding or "fast-tracking" the more conscientious Change Owners is a really interesting concept; one I probably already do subconsciously.

Thanks for the tip.

[Skinnera]

For my organisation we have defined the following;

Risk; the likelihood of a Change being unsuccessful and causing a service outage.
A number of different factors will need to be considered when assessing the RISK of a Change to determine its category. These include the complexity, scope, testing, recovery and timing associated with the Change, but general guidelines are as follows;

Low

Recovery / Back Out plan known and tested
Non-complex Change (e.g. server reboot, data purge)
Change that replicates normal user activity
Change tested successfully in an environment that fully replicates the live environment
Significant history of successful implementation
Successful implementation of Pilot & subsequent Phase 2 rollout (e.g. 10+) nodes

Medium

Recovery/Back Out plan untested
Change to a component that has a history of risk
Change to a non-critical component
Change tested successfully but where environment does not fully replicate live (e.g. reduced size etc)
Successful implementation of Pilot & subsequent Phase 1 rollout (e.g. 0-10) nodes

High

Recovery / Back Out plan not available
Change validation dependant on client usage (i.e. cannot be checked until user load applied)
Change across multiple sites, platforms, services or networks
A single Change delivering multiple fixes/builds/updates
Change involves input from multiple support areas.
Change to a critical component (i.e. a component that the service will not work without)
Change not tested (at all, or to the maximum level of testing available)
Pilot or first time of application in live network

[Skinnera]