Technique 1.91 Seven Rs

Introduction

"...Seven simple questions to help you assess change-related risk and gauge the effectiveness of change-management process..."
Brian Johnston et al, 2007

Even though this was specifically developed for the IT industry, it is applicable to many industries.

Some of the benefits of answering the 7 questions are

i) provides a set of metrics that will objectively measure change risk

ii) assesses the relationship of the proposed change to other organisational activities (including gaps)

Questions

1. Who raises the change?

There is a need for a singular, centrally-controlled system of recording any introduced, authorised change. This system will incorporate appropriate controls and information flows across functional areas. Also, it will help in auditing.

2. What is the reason for the change?

Need to be able to evaluate benefits and risks of a change. It will encourage strategic innovation rather than tactical change, ie most change in IT is dedicated to maintaining legacy infrastructure. Using the appropriate portfolio analysis criteria to assess the type of change planned will help with privatisation of changes.

3. What return is required from the change?

Need to understand the return, especially financial (cost-benefit analysis, etc), generated by change. This will help prioritise projects.

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..."
Brian Johnston et al, 2007

Need to identify and prioritise the possible risks (including worst case scenario)

This can include the risk of not changing!!

5. What resources are required to deliver the change?

Assessment of the resources (including skills, assets, time, capital, people, etc) that are needed for successfully implementing the change (including availability of the resources both within, and outside, the organisation).

The impact of the change on other parts of the organisation (including other projects) needs to be considered.

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 responsibilities, however, should not be restricted to application development. It should be traceable, enforceable, and actionable across the entire change..."
Brian Johnston et al, 2007

This should be part of an action plan, ie what has to be done, who has to do it, when it has to be done, what resources are allocated, etc

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

With change occurring everywhere, change relationships need to be determined from within and across functional boundaries. Failure to do this will result in confusion and poor performance.

 

Search For Answers

designed by: bluetinweb

We use cookies to provide you with a better service.
By continuing to use our site, you are agreeing to the use of cookies as set in our policy. I understand