Sei sulla pagina 1di 4

The Seven Rs of Change Management

Seven simple questions can help you assess changerelated risk and gauge the effectiveness of your changemanagement process.
by Brian Johnson and Peter Waterhouse

1. Who raised the change? Unauthorized change is the scourge of IT. With so many entry points, stakeholders, and siloed sources of change, its 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 changeespecially 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 changeespecially the financial paybackto 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 simplebut often challenging questions, IT organizations can readily achieve this level of change discipline.

Potrebbero piacerti anche