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.
Blog post: Making COBIT 5 part of your IT strategy
Solution page: IT Performance Management