7 goals for taking business and IT risk out of your change management process

In a recent post, I discussed the importance of service agreements. This post looks at a major factor in whether services are in fact delivered as expected: how well changes and releases are managed. Change and release matter to the business and IT because “30-50% of the incidents in an organization are as a result of a change” (ITIL Version 3.0 Service Transition Book Draft, Page 25).  For this reason COBIT 5.0 says the management of change and release is about ensuring these functions are done in a “controlled manner.” Creating better control is built upon establishing standards, procedures, prioritization, and authorization.

 

Good change management means the business gets fast and reliable change while risk is mitigated. Good release management delivers solutions in line with all of their agreed-on expectations and outcomes.

 

Goals for change and release management

To improve and reduce risk, COBIT 5 suggests IT organizations measure themselves against seven process improvement goals. Let’s explore each along with their recommended metrics to get a better idea of the impact of the change process as a whole. 

 

1.                  Authorized changes are made in a timely manner and with minimal errors. The aim here is over time improve the ability to manage all forms of change. Three metrics are used to measure success against this: amount of rework caused by failed changes, reduced time and effort to make changes, and number and age of backlogged change requests. These three together measure the effectiveness (is failure reduced and responsiveness improved?) and efficiency (the time and effort needed to make changes) of the change process as a whole.

2.                  Impact assessments reveal the effect of changes on all affected components. An effective change process starts with impact analysis within the Change Advisory Board. In fact HP Software has a product focused on helping to manage this whole process from end to end. For this goal, one metric is recommended: percent of unsuccessful changes due to inadequate impact assessment. This is the perfect metric for this topic. It tells you whether your impact assessment process is in fact effective.

3.                  All emergency changes are reviewed and authorized after the change. Let’s face it, emergency changes are a problem. They are changes done outside of the change review process because of some form of emergency. They should be rare. In fact, an HP internal customer survey said that they should represent 2.5% or less of the changes implemented. Two metrics are recommended to manage this process goal: percent of total changes that are emergency fixes and number of emergency changes not authorized after the change. The second one is particularly interesting. It says that all changes should be approved and more importantly, emergency changes should have a high post fact approval rate.

4.                  Key stakeholders are kept informed of all aspects of the change, implementation, and conversion plans. Part of the reason to have a Change Advisory Board is to make sure that stakeholders are informed. Successful project management in fact requires the same thing regarding the end to end implementation or conversion process. Two metrics are recommended to manage this process goal: stakeholder feedback ratings on satisfaction with communications, and percent of stakeholders satisfied with the completeness of testing process.

5.                  Releases are ready for promotion into production with stakeholder readiness and support. Software clearly is not an end in itself. It is about enabling business processes—therefore, readiness and support matters. One metric is recommended to manage this process goal: number and percent of releases not ready for release on schedule. Users depend upon software to function as planned, so this is a natural metric to measure.

6.                  Releases are promoted successfully, are stable, and meet expectations. The quality of releases matters to IT and especially to its business customers—in many ways, this is the ultimate measure of the end-to-end project and quality process. Two metrics are recommended to manage this process goal: number or percent of releases that fail to stabilize within an acceptable period and percent of releases causing downtime. These are kiss-of-death metrics and clearly, they should be very low in a controlled process. Imagine a cut over to a new piece of software having either of these events happening.

7.                  Lessons learned contribute to future releases. This is all about asking whether learning in the release process improves future releases and thereby, the whole change process. One metric is recommended to manage this process goal: number and percent of root cause analyses completed. If you’re doing root cause analysis, you’re going to learn what you can do to improve.

 

So where should you start?

As always, my suggestion is that you start where the most immediate value can be driven. But if it were up to just me, I would start with goal area #3: emergency changes. We need to make them a rare event to take out business and IT risk.  What do you think? What would be first on your list? I would love to hear back from you.

 

Related links:

Blog post: Making COBIT 5 part of your IT strategy

Solution page:  IT Performance Management

Twitter: @MylesSuer

Comments
chuck_darst | ‎01-07-2013 10:30 AM

Myles,

 

Good post. I agree with everything you've noted, but I have something to add.

 

A very basic one to start with, appropriate CI's need to be under an adequet change management process. Lots of major disruptions occur when the change management process is bypassed for whatever reason. The Amazon Christmas Eve outage is another example of a change gone bad that didn't go through a change management process - http://www.informationweek.com/cloud-computing/infrastructure/amazons-dec-24th-outage-a-closer-look/....

 

I then like #2 on impact assessments for larger and more complex environments. We continue to see major disruptions occuring when change impact crosses organizational or logical boundaries and the impact not sufficiently understood.

 

Chuck Darst

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
Mr. Suer is a senior manager for IT Performance Management. Prior to this role, Mr. Suer headed IT Performance Management Analytics Product ...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation