Seven Rs of Change Management

Seven Rs of Change Management is a quick check list of what should be covered when raising a request for change. Change Management is a core process of the ITIL version 3 Service Transition volume.

The Seven Rs of Change Management is used as part of the change assessment activity.

Who RAISED the Change?
What is the REASON for the change?
What RETURN will the change deliver?
What RISKS are there is we do or do not carry out the change?
What RESOURCES will be required to perform this change?
Who is RESPONSIBLE for this change being performed?
What RELATIONSHIPS are there between this and other changes?

1. Who raised the change?

Unauthorized change is the scourge of IT. 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. 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?

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.

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.

6. Who is responsible for the “build, test, and implement” portion of the change?

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.

7. What is the relationship between this change and other changes?

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).

---..................................................................................................................................................................... ......................................

..................................................................................................................................................................... .....................................................

..................................................................................................................................................................... .................................................