Unrecognized activities of Change Management (Part 1)

By Laurent Duenas, September 18th 2013 

 

Change: a broad and finally unclear word

 

Everything is change (almost)

It represents about everything an IT department does, provided there is a will to change something. Needless to say that its scope is wider ! There are changes, both in applications and infrastructures. There are operational changes and changes in test environments. There are small changes, even tiny ones, and others that are so big that they have a strategic dimension for a company. There are changes initiated by activities and others by technology. There are changes which aim at correcting things, others, at promoting evolutions. There are so-called “standard” changes, and others which are not. Moreover, if this vocabulary is used by all IT organizations, it is far from being based on universal criteria.

 

The word “change” involves many different things which do not require the same involvement from stakeholders, the same quality levels and which do not address the same issues.

 

The notion of change is the same for all

In outsourcing companies which deliver IT service for business, the notion of change cannot be the same as in the engineering department of a company's IT service. Depending on who you are, the notion of change is perceived differently. The more integrated the perimeter, the more it includes design, integration, then deployment, the larger the notion of change.

 

The word in ITIL represents all possible uses and can thus be misleading. Because each one of us, according to the job he holds, only partially understands what change is. For this purpose, one has to take a sufficient elevated view to understand that, in the ITIL context, change encompasses most activities we call “change” in daily life.

 

Here are some examples to illustrate this:

 

For organizations in charge of managing physical infrastructures for example, change often means replacing one type of infrastructure with another.

 

►   In some cases, this simple process means change. In other cases, it is only a step in a series of events, which, put together, constitute change. To be accurate, for ITIL a replacement will be a “deployment” of Release and Deployment Management

 

►   As a result, the daily vocabulary puts up with very personal notions of change. Infrastructure deployment providers will consider the replacement of equipment as a standard request and the same operation repeated a number of times (i.e. the installation of 10 workplaces) will be considered as a change, because in terms of cost and organization, it is no longer considered as a standard operation that can be performed over a long period. But this notion has little to do with the definition of ITIL ”standard changes”. This is an adjustment which does not make understanding of basic concepts easier

 

 

For a Design Department, change will mean developing a program from design stage to development (writing from scratch or rewriting of an existing program), or simply configuring a software package on the market.

 

►   But for ITIL, Design is just a contributor. The notion of “change” includes the integration of the new program in an industrial operating environment and its release deployment too

 

►   Yet in their vocabulary, their internal processes and their tooling (demand, versioning and bug management), they operate on a daily basis with their own notion of change which mixes with those of downstream stakeholders (Integration and Release), to which the ITIL framework tries to contribute with its definitions

 

Take Design, integrators or deployment stakeholders, all of them are part of a Change process chain. This chain involves the same process: Change Management.

 

 

The chart below shows the various visions of a change according to stakeholders, before ITIL was introduced: 

 

Nothing in ITIL prevents us from considering (and managing) each contribution as an independent change. But these changes are linked to the initial change as ”parent and child” incident tickets would be. Impact Analysis and other Change Management activities primarily apply on the initial change, which contributes to keep a coherent vision of the various changes attached.

 

 


Other articles

►  No link


External links

►  No link


Related products

►  Change & Release ...

Copyright © 2013 - PRACT Publishing