Delivering fast, reliable, and risk-mitigated change and release using COBIT 5

If you’ve been following my series of posts on COBIT 5, you already know that I think the new release of the COBIT standard will help IT organizations achieve greater financial transparency, customer satisfaction, operational excellence, and future orientation. Today, we will focus our attention on what COBIT 5 can teach us about optimizing change and release management.

 

COBIT 5 defines change as any changes that are managed in a controlled manner including standard changes and emergency maintenance relating to business processes, applications, and infrastructure. As a result, the change process includes change standards and procedures, impact assessment, prioritization and authorization, emergency changes, tracking, reporting, closure, and documentation.

 

Release, on the other hand, is about formal acceptance and the making of operationally new solutions. Release includes implementation planning, system and data conversion, acceptance testing, communication, release preparation to production of new or changed business processes and IT services, early production support, and post implementation review. Change and release together aim to enable fast and reliable change delivery to the business and to mitigate the risk of negatively impacting the stability or integrity of the changed environment. Key takeaways here are as follows: change and release should be fast, reliable, and mitigate risk.

 

Process goals for change

To improve change and release, IT needs to measure itself by explicit goals. COBIT 5 recommends eight areas for process goals. Let’s explore them along with their specific metrics. 

 

1.                  Authorized changes are made in a timely manner with minimum errors. It should be clear that the goal here is speed and accuracy. Three metrics are recommended to measure its success: Amount of rework caused by failed changes, reduced time and effort required to make changes, and number and age of backlogged change requests. The first gets right after accuracy and should be a small number. The second and third are really about speed and learning—am I processing changes more quickly and thereby reducing the backlog?

2.         Impact assessments reveal the effect of the change on all affected components. Part of having an effective change approval process and a CAB is to not only approve change but also evaluate potential change impacts to minimize business and IT risk. This includes having a backed-out plan that minimizes business risk of change failure. Only one metric is needed to net out performance for this goal area: Percent of unsuccessful changes due to inadequate impact assessment. Unsuccessful changes can take down business services and in many cases, need to be effectively backed out. If the impacts are not adequately considered, this can result in real business consequences like lost sales.

3.         All emergency changes are reviewed and authorized after the change. Emergency changes happen because a system crash or other drastic result has happened and needs to be addressed immediately. As a rule of thumb, emergency changes should be few and far between. Two metrics exist for this goal area: Percent of total changes that are emergency fixes and number of emergency changes not authorized after the change. The second metric says that a change was implemented without pre-consult of a CAB or post CAB approval. This metric says emergency changes introduced had enough issues they did not get approved.

4.         Key stakeholders are kept informed of all aspects of the change. All change involves risk. Part of an effective change process is connecting with key stakeholders in advance of a change to consider the business impacts as well as the timing for changes. One metric exists for this goal area: Stakeholder feedback rating on satisfaction with communications. Simply put, good communication drives good process.

5.         Acceptance testing meets stakeholder approval. The business needs to be involved in not only defining requirements, but also the acceptance test criteria which say whether a project delivered against its goals. This is really the final step of change. Did the change meet user requirements? One metric exists for this goal area: Percent of stakeholders satisfied with the completeness of testing process. This metric tells how well we run the process from the customer’s perspective.

6.         Releases are ready for promotion into production with stakeholder readiness and support. This goal area is all about communication and doing what we say we are going to do. One metric captures this goal area: Number and percent of releases not ready for release on schedule. If this number is low and we do well at communicating, then customers are ready for the promotion into production of a new or updated system or application.

7.         Releases are promoted successfully, are stable and meet requirements. This is kind of the proof of the pudding. Two metrics exist for this goal area: Number or percent of releases that fail to stabilize within an acceptable period and percent of releases causing downtime. Clearly, this goes after our ability to successfully meet our planned schedule.

8.         Lessons learners contribute to future releases. This is fundamentally about our ability to improve the change process over time. One metric exists for this goal area: Number and percent of root cause analyses completed. This says we are discovering our deficiencies and we are eliminating or mitigating them over time.

 

Where to start?

Once again, my suggestion is you start where the most immediate value can be driven. But if it were up to me, I would start with process goals number one and three. We know that change, according to ITIL Version 3, is responsible for 55% of outages. Getting better at repeatability of change with minimum errors, therefore, has real business impact. And reducing emergency changes reduces risk, outages, and the potential for a security issue.

 

Related links:

Blog post: 3 ways IT leaders can strengthen compliance and control

Blog post: Making COBIT 5 part of your IT strategy

Blog post: COBIT 5 guides IT leaders to better manage future orientation in their organizations

Blog post: 7 goals in COBIT 5 that will improve your operational excellence

Blog post: COBIT 5’s scorecard measures IT’s relationship with its customers

Blog post: COBIT 5 scorecard measures the quality of IT’s financial performance

COBIT 5

Solution page:  IT Performance Management

Twitter: @MylesSuer

 

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