A partly implemented process (Part 2)

By Laurent Duenas, July 30th 2013 

 

A process implemented within a limited scope

 

The facts

We observed that in 90% of cases, organizations which implemented Change Management did so within a limited scope. Usually, Change Management only considers changes when they are about to be deployed.

In other words, Change Management is restricted to deployment preparation and implementation activities of Release and Deployment Management. Therefore, from a practical point of view, we are very far from ITIL objectives.

 

Illustration of the actual scope of the Change Management process in companies “true life”:

 

For example, what is often called change within companies is the release of the new version of an application, the modification of a database format or the implementation of a new network addressing plan, etc. However, each one of these examples is prepared beforehand (risk evaluation, stage and resource planning, etc.), thus totally escaping the Change Management process.

 

To compare with the full scope of change activities according to the ITIL framework please go to part 1 of this article; Activities of Change Management (Part 1)

 

Reasons of this situaton

 

Historically, ITIL had never been implemented in this scope

ITIL is a framework stemming from the world of Production (Run environment), which was never adopted, either by Design or Build project teams. Even with system and network infrastructure project teams closer to release, project methods generally organize build activities up to deployment, but they very rarely rely on process approaches such as ITIL*.

 

*For the author, process approaches mentioned in projects methods such as PMBOK or Prince2 should not be compared to ITIL process approaches. As regards projects, the process approach mainly aims at capitalizing previous experience by standardizing approaches for specific project types (as to repeat the lessons learnt - but projects stay mostly"creation processes"). Industrial approaches addressed in ITIL go above and beyond as regards operations standardization and automation, and they provide answers to any of the day-to-day requests, while guaranteeing a constant result.

 

Project approaches often exist within organizations before ITIL. So, they are better established. Also, they are often preferred because of their customized approach and are therefore more compatible with the build business itself -to the extent that for many people, project mode is the solution to everything: planning, risk anticipation, controls. Build people’s attitude towards project approaches is more positive than towards process approaches, which are usually considered as too binding (and less creative).

 

In reality, experience has shown that project mode, without denying its added value, is a comfortable way of masking the difficulties of industrializing with standardized processes, through dedicated management organization and sizing (of resources and financial means).

 

Illustration of the differences between Project and industrial Process approaches (such as ITIL):

This illustration shows the territory occupied by frameworks other than ITIL



Copyright © 2013 - PRACT Publishing