A partly implemented process (Part 4)

By Laurent Duenas, July 30th 2013 


Consequences of this restricted scope


A limited anticipation of changes

As change control only begins when they are about to be deployed, the anticipation level of risk and all actions aimed at reducing risk such as assessment of change technical impact, coordination of all stakeholders involved in impact, etc., are strongly minimized. As a result, it becomes more difficult to avoid last-minute discovery of failure, or even worse, late discovery after change has been deployed.


Example: In an industrial company selling capital goods, a new HR software package had been chosen by both Human Resources Department and the IT Design department, without any coordination with Release (Production Department). When the change was announced (corresponding to production implementation date, in this context), the Release department found out that most transactional activities could not be controlled by standard supervision tooling and that support could only be purely reactive. As a consequence, the service levels expected by HR Department could not be met and commitments had to be renegociated with a strong frustration from the HR Department.


A limited quality control

As regards the important mission of change quality as “control tower”, it can only be efficiently carried out and accepted by everyone as long as process positioning actually covers the whole lifecycle of IT Service.


Nowadays, the process is perceived as “bureaucratic” because its control takes place at the end of the chain when the build and integration stages are over and IT Service delivery to business is imminent, that is, when it brings no other added value.


Now, the contribution of a Change Management process is to bring added value as early as the initial (and key) Build stage. Controls and authorizations are carried out with a view to guarantee “embedded quality” as early as Build. This contribution goes on during the whole lifecycle through the next stages of integration, certification and finally deployment into the release environment.


The illustration explains where Change Management can carry out controls aimed at insuring that architectural, development, test, integration, operability and the ability to deploy, etc., “norms and standards” are correctly taken into account to guarantee “embedded quality”.


* The notion of the model presented in this illustration refers to principles of normalization and applicable standards implemented according to a specific model.

However, the incomplete scope of Change Management encountered today within companies implicitly limits the process capability to guarantee that all these norms and standards are taken into account. It gets into play much too late, and sometimes, does not get into play at all (see the illustration below). Therefore it is obviously considered by "build teams" as an obstacle to agility and an additional cost.


Illustration of limits of influence as far as methodology and control are concerned:

* This illustration shows on the one hand, that build and development principles potentially escape quality control and depend on project teams will to implement them. On the other hand, the scope of influence of the Change Management process is limited to deployment activities. Once all elements of change are integrated by project teams, Change Management cannot but helplessly watch deployment because subsequent improvements turn out to be too expensive and incompatible with the customer's schedule.

A limited industrialization of change

This point refers to the scarce capacities to capitalize, whose purpose is to industrialize repetitive changes through models. This point is more thoroughly addressed in the next paragraph dealing with facts about the Release and Deployment Management process (the same remarks applying to both processes).

A limited optimization of change cost

As it comes into play after Change development and integration, Change Management is not able to implement one of the key principles of the “validation” activity: assess the business benefit of a change. Development and integration efforts have already been deployed and if, as is often the case, the company does not benefit much from the change, then it is too late, cost is already incurred.

Of course this case is not likely to arise for big projects whose development budget is high and very visible. The latter is subject to opportunity studies in pre-project stages. However, Change Management does not only address big changes. This efficiency control also targets the whole range of small and medium-size changes which are often decided by operations teams themselves without real evaluation, and whose purposes can potentially be questionable.

This limited scope of Change Management observed within organizations deprives them of a major cost reduction tool because at least 50% of the build, integration and Third-Party Application Maintenance resources activities involve minor changes.

Example: The Export department of an industrial company in optics used to request frequent modifications of documents to submit to customs. Of course, these changes were urgent. Because of this, build and integration teams were mobilized without previous notice, which brought constraints on them to guarantee production implementation. Analysis showed that modifications turned out to be linked to personal evaluations of Customs needs and sometimes to punctual requirements of Customs services. A thorough analysis (carried out several years later) demonstrated that consolidating the needs would have decreased the number and cost of change operations by 10.

In an investment bank, the infrastructure department in charge of servers systematically planned minor updates of technical software packages as soon as editors made them available. These updates were not justified by business requirements and could perfectly wait for a major grouping of all previous minor updates. The motivation of the manager in charge of server infrastructures was to remain up to date from a technical point of view. This approach, purely stemming from his own need, potentially jeopardized the business activities of several Business Lines and regularly incurring costs covering preparation and release of server images. 

An underexploited RFC content

Given the limited scope of Change Management, its deliverables are aligned on it and their yield is implicitly below the required potential.


Request for Change (RFC) is a significant example. Today, its content is limited to the main information known: changeover date, prioritization, status and result of its post-implementation review (PIR). This information could be enriched with build and integration activities results. As a result, you have to put up with having (and sharing) =limited information, which does not enable you to anticipate risks and make the best decisions.


The following picture lists the differences between a RFC content in the current business context and in a target situation (that we voluntarily call “state of the art” here):



Copyright © 2013 - PRACT Publishing