In-Depth
The Seven R’s of Change Management
Seven simple questions can help you assess change-related risk and gauge the effectiveness of your change-management process.
by Brian Johnson and Peter Waterhouse
Many practitioners of IT service management and ITIL eagerly anticipate the pending release of “Business Perspective Volume II,” the long-awaited companion to “Business Perspective: The IS View on Delivering Services to the Business.” They are anxious to understand the value it can deliver, with the hope that it won’t simply revisit the well-trodden ground of service support and service delivery.
They won’t be disappointed.
While the books about service support and service delivery remain the definitive core of ITIL, “Business Perspectives Volume II”—with its insights into critical business issues—is a compelling read, especially for senior executives seeking guidance on such complex issues as IT governance, organizational alignment, and strategic sourcing.
In particular, it contains an impressive checklist in the chapter on business continuity that outlines a checklist steps in determining change risk change and gauging the effectiveness of the change management process. This checklist comprises seven simple questions. Any organization that doesn’t ask these questions (or can’t answer them) faces a significantly elevated risk of change adversely affecting IT and business services.
This risk can be considerable in today’s IT environment, which is constantly being asked to respond to new business requirements. If you don’t develop an effective process for managing change, you’re likely to experience more frequent service outages—which end-users simply will not tolerate. That’s why the new insights provided in Business Perspectives Volume II can be so helpful in your efforts to deliver reliable, cost-justifiable IT services.
Here are the questions the authors encourage all IT organizations to ask:
1. Who raised the change?
Unauthorized change is the scourge of IT. With so many entry points, stakeholders, and “siloed” sources of change, it’s no wonder that this phenomenon creates such a problem. One way to address authorization is to develop a system for centrally recording all changes. Such a system must incorporate appropriate controls to address change handoffs across functional areas. This single “system of record” is especially useful during audits.
2. What is the reason for the change?
Answer this question so you can avoid changes that introduce risk without offering any corresponding business benefits. In fact, without a process for validating the answer to this question, strategic innovation can easily take a back seat to an incessant deluge of tactical change—especially since as much as 75 percent of IT budgets is dedicated to maintaining legacy infrastructure. Regardless of the type of change, every major change should be assessed against an agreed-upon portfolio analysis criteria. This assessment will ensure appropriate prioritization of change and expose gross potential misalignments before they sap IT resources.
3. What return is required from the change?
Understand the return generated by change—especially the financial payback—to determine the priority of strategic and project-driven change. While ITIL recognizes two key inputs into the change management process (problems and innovation), guidance about how innovation should be regulated is sparse. “ITIL Financial Management for IT Services” can provide useful cost-related information but needs to be supplemented with value-based metrics to objectively measure the true financial impact of change.
4. What are the risks involved in the change?
All change involves risk. The question is how much risk. Some risks can be avoided or mitigated and some have to be accepted. You must make every effort to assess the likely impact of change on your infrastructure. Identify a regression strategy should the worst happen. Make sure that you also consider the risk of not making a change. The ITIL concept of “severity” can be applied to potential risks as well as to actual problems. What are the best- and worst-case scenarios if things go wrong? No one has a crystal ball, but it is certainly reasonable to expect a degree of forethought before making changes.
5. What resources are required to deliver the change?
Both people and IT assets are needed. From a people perspective, mechanisms need to be in place to determine what skills are needed to make the change, as well as whether those skills are actually available. Assets require a similar analysis: what infrastructure assets are required to implement this change, and are they currently available? The impact to other projects must be considered: if people and assets are re-allocated to address this change, what is the delay (in time and cost) to other projects currently in progress?.
6. Who is responsible for the “build, test, and implement” portion of the change?
Anyone managing application development should be able to answer this question. Responsibilities for each of these three functions must be appropriately segregated, especially in light of compliance and auditing requirements. Segregation of responsibilities, however, should not be restricted to application development. It should be traceable, enforceable, and actionable across the entire change and release management process, from change request to deployment.
7. What is the relationship between this change and other changes?
With so many changes occurring concurrently in complex IT environments, this can be difficult to answer. Change relationships need to be determined from within and across functional boundaries. Failing to do so will result in longer periods of planned downtime due, for example, to incorrect or sub-optimal change sequencing. Shared scheduling of planned changes can help here, as can change impact analysis and relationship mapping from an integrated configuration management database (CMDB).
The Benefits These Answers Bring
Answering these seven questions provides several benefits. First, doing so enables organizations to input a set of metrics that provide a more objective means of measuring change risk, which goes a long way towards making services more reliable and available to customers. Second, these questions offer a great way to assess how well your change-management process complies with current mandates, and also helps to pinpoint gaps that can be bridged through process automation and new techniques.
Implementation of, and consistent conformance with, an auditable change-management process is essential because of the significant dependence of business on IT services and new regulatory requirements. By asking these seven simple—but often challenging—questions, IT organizations can readily achieve this level of change discipline.
Brian Johnson is the worldwide ITIL practice manager for CA and was part of the British government team that developed the ITIL framework. Peter Waterhouse is CA’s director of enterprise IT management, solutions marketing. Peter has 15 years experience in enterprise systems management, with specialization in IT service management, IT governance, and best practices. You can contact the authors about this article at brian.johnson@ca.com