A partly implemented process (Part 3)

By Laurent Duenas, July 30th 2013 


A process implemented within a limited scope - the reasons


Historically, ITIL had never been implemented in this scope (suite)

Even if other frameworks, such as CMMI, have opened their scope beyond project management activities by adding development, assembly and (development) support, they remain very much focused on the design of a new system. They do not address the operational guarantees of IT Service, as ITIL does.


As far as ITIL is concerned, the deliverable is larger than the system designed. Additionally to the system (applications and infrastructure), it includes a service delivery and a commitment, i.e. availability, capacity, maintainability, security, etc. (known as warranties according to ITIL V3 vocabulary), in line with business expectations. These services are delivered thanks to the process “ecosystem” ITIL represents.


Example: if an IT Department customer wishes to have a quicker Sales System, Project Management, in response, will build a new dedicated Sales System with a new architecture and new components probably integrating new technologies. The new system will be integrated into the existing live environment, i.e. its support, deployment, management organization. Only rarely do projects re-consider the environment applying to all other IT Services. In ITIL, a new customer requirement can lead to the evolution of the process ecosystem, additionally to the system itself. A new commitment (SLA) requires a review of all processes (Incident, Problem, Availability, Capacity, Suppliers, etc.), to ensure that this commitment is held during the whole Service lifecycle. ITIL V3 reasoning is more “holistic”


Illustration of ITIL processes ecosystem” throughout the Service lifecycle:


In the above illustration, processes are presented in a similar way to the way they are presented in ITIL V3 books. They are positioned according to their main vocation. This illustration does not represent the real sphere of influence of processes. For example, Change Management activities start at the beginning of Service Design, as soon as Build activities start.


The same remark applies for Project Management as in paragraph Why 2 processes?” in the previous chapter. This process is not actually included into ITIL (but activities are widely addressed).


The department partition

Historically, Design (& Development) departments have often considered Release (to Live environment) departments as obstacles to the implementation of new IT Services because of their demands on development operability and deadline requirements. In an effort to preserve their independence, Design managers do not wish to get involved in common processes in which they would not be the sole masters of rules (the opposite is probably also true). Although everyone does Change Management, Design and Production rarely share this process. The solution which consists, for each one of them, in industrializing its practices according to its own framework, or in its own camp, is much more attractive to managers*, because it preserves some freedom of action.


The author found out that in some Design departments, the maturity level reached (II or III CMMI) is insidiously used to justify a sufficient industrialization level to remain autonomous and not have to mix with the processes of colleagues from Production.


Resistance to change

Also, Change Management principles impose discipline in formalization, compliance with circuits and control requirements. All of these are measures which are often considered as obstacles to agility (see the article about new IT trends). It is also difficult for an organization to adopt all Change Management principles without deep, and above all, progressive transformation. That is why organizations often restrict themselves to RFC implementation, deployment go ahead through a CAB and post-change review. This is because even at this  early stage, implementation meets resistance.



Copyright © 2013 - PRACT Publishing