Infrastructure management is undergoing a transformation. ITIL can help manage conflicting demands like – “low cost but high service quality”, “ubiquitous access but enhanced security”?

« Does SaaS compliment ITSM, towards achieving Operational Effciency? | Main | The Next Big ITSM Evolution (pt.2) - An “Environments Service” or just a pile of under-utilized hardware and software adding to the cost base? »

Does the next version of ITIL needs more than 7 Rs of Change Management? YES!

Posted by Aswin Kumar

It may be a funny debate if I start scoping out the extra number of R’s required in Change Management. Anyway, I’m not a potential author of the next version of Service Transition book yet Smile

Of course, I always wonder why all the R’s were fitted under the magic number ‘Seven’? Was someone inspired by the ‘McKinsey 7-S Model’ or the ‘7 principles of Supply Change Management’?

Hey, Shirley and Ivor, Are you reading?

On a slightly ITILized note, have we really analyzed and implemented the 7R’s of Change Management? Recently, we came across the need for a similar philosophy where we planned to use the tenets of the 7R framework. Yes, this is for a hard-core Change Management model design assignment.

Let me first put forward my interpretation of each of the question under 7R (keywords after each question below):

  1. Who ‘Raised’ the Change?  - “Who”
  2. What is the ‘Reason’ for the Change?  - “Why”
  3. What is the ‘Return’ required from the Change? –  “ROI”
  4. What is the ‘Risks’ involved in the Change? – “Risks”
  5. What ‘Resources’ are required to deliver the Change? – “Resources”
  6. Who is ‘Responsible’ for the build/ test and implementation? – “Roles & Responsibilities”
  7. What ‘Relationships’ are there between this and other Change? – “Impact Analysis”

Now what needs inclusion here? Any guesses? I would give 3 keyword hints for the 3 new questions: “Requirements”, “Value” & “End-Users”. Let’s go for it in the following lines.

The existing question on the ‘Reason’ for the Change focuses more on the ‘Why’ factor. The Service requirements fulfillment perspective from a change needs to be explicitly addressed.  

 “What are the Service ‘Requirements’ fulfilled from this change?” This should cover the specific requirements for the services that are enhanced due to the change implementation. For instance, if a database change ultimately modifies the Email Service component and is deployed to fulfill the Sarbanes Oxley guidelines then all the functional and legal requirements need to be documented.

Secondly, the value realization tracking seems to be completely missing. We need a question that assures the value tracking mechanism right from the inception of the change to the steady state.

 “Is the Change value ‘Realization’ plan available”? This will put an onus on the business stakeholders to define the value realization requirements and work with the enablers such as Information Technology (IT) to validate the actual value derived during the post-steady state reviews of the change. I am sure that this will generate a list of lessons learned for future changes.

Thirdly, the human side can be better addressed systematically in the 7R questions, especially when the change is of a global scale. I feel more for the end-users of the change where there is a need for a thorough and consistent diagnostics that can assess the organizational readiness to accept the Change and also be able to successfully operate it. These diagnostics need to specifically address the human behaviors, perceptions, language capabilities and build sufficient infrastructure and programs needed to drive the change globally. For instance, if a change is deployed out of the US and needs a training material creation in Spanish or Japanese for the regional offices then there needs to a dedicated planning and execution effort to close on this.

I suggest that validating this aspect is crucial for the business approvers of the change. This can also enable the business (end-users)/IT alignment.

These were my thoughts on one of my favorite topics: Change Management, what are Yours?

TrackBack

TrackBack URL for this entry:
http://www.infosysblogs.com/ITSM-service-matters-mt/mt-tb.fcgi/111

Comments

Hi Aswin,
Like you, Change Management is one of my favorite topics as well :). Nice rendition of thoughts on Change Management using 7R. :)

In line with your thoughts, I was wondering, havent we missed another important 'R', which is Post Implementation 'Review'? A lot of things can be learnt from PIR. Also it is useful in enhancing the maturity of the change management process as well as reducing the probability of incidents from changes.

Aswin-

Your points are definitely valid.

I feel some of the points raised are a result of the fact that ITIL is not prescriptive. Sometimes it only gives us a starting point to direct our thoughts. Most of the statements are at a level where it has to be interpreted. The fulfillment of the directed thought and the interpretations are always influenced by the experience of the individuals who are involved.

For Eg: I would interpret the "returns' as 'Direct and indirect BENEFITS to the business and/or IT'. This would include the ROI and the Value part (be it for business or IT).

The section of the 7Rs in the book starts like this:

"The potential impact on the services of failed changes and their impact on service assets and configurations need to be considered. Generic questions (e.g. the ‘seven Rs’) provide a good starting point". So I would take it as something to start a thought process in those directions rather than take it as a definite list.

Explicit emphasis of the 7Rs portion in the V3 foundation syllabus is also another factor I feel. Because if we read further in the book, it indirectly addresses most of the questions (requirements and end user aspects), raised here. When it comes to 'value', it addresses the elements of utility and warranty part as well. So again it indirectly addresses it.

When it comes to major changes, ITIL suggests us to go back to the design stage where we have the help of other concepts and processes to address lot many aspects. So we need NOT to try to solve all concerns of a change ONLY using concepts within change management process.

5 aspects of design is a classic concept that could address many of these.

I've also been very critical about some of the concepts within the ITIL V3 publications and at times even about authors. Many of us are not aware of a lot of factors that had influences during the authoring phase of these books. This always makes us very critical. But when time passes by and when we meet more people one starts realizing that we cannot have that 'one perfect book' which will tell us everything. All these can only guide us.

Sometime back I had the privilege to meet and spend time with the authors and architect (people like Ivor, Sharon, Vernon, Gary etc..), which changed my views about the BOOKS a bit (positive though!). It is really difficult to put across all the knowledge of all these people and many others thru 5 books in an easily understandable way!!

It was too long a comment, isn't it?.. Happy blogging!

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.