IT Trends Impacts (Part 3)

 

Organizations wishing to keep a light package

 

Some organizations wish to maintain a Change Management and Release and Deployment Management package, as little binding as possible. Because they are convinced that their agility depends on it and that lightening the package is the solution which suits them best; or because initially, they find it difficult to do better ; these organizations search an intermediate solution between recommendations suggested in this book and the simple, easy to reach Level 1 of the maturity curve shown previously ; a solution considered as satisfactory compared to their needs.

 

Relieve controls

If no constraint can be borne and if no other alternative to agility exists but to free build or integration activities from controls, then, processes in these activities must be as transparent as possible.

 

Today the Change Management scope remains identical in most maturity levels observed within organizations. That is, the “gate-keeper” level, where at last, changes are actually presented at the time wished for their release.

 

RFC can exist before change implementation, in order to get minimum information in advance and a capacity to anticipate. But no previous approval stage, nor impact evaluation, nor deliverables control, nor “go/ no go” decisions, will be imposed during build and integration stages. Project Management methods remain the minimal governance level to guide these activities towards expected service levels.

 

The importance of humain factor

On the contrary, if flexibility is allowed during preparation stages, requirements and rigor must be maintained before changeover to live environment.

 

The responsibility of keeping existing IT Service available is maintained and in the majority of cases, prevails over the change under way. This responsibility in itself justifies the power of refusing any release implementation considered at risk.

In order to carry out an audit before authorizing implementation, there too, two approaches are possible:

 

►  A high-level control method, based on a real certification providing that most approval tests for main guarantees (or SLAs towards customers) should be performed in an environment representative of the Live environment. This approach requires an (often long) approval time, but allows maintenance of an adequate level of change quality and availability of existing Services.

 

►  A light control method, based on a “declarative” approach, where guarantees are not tested, but where change initiators and integrators are simply requested to declare that they have taken the necessary precautions and implemented the quality principles enforced in the company. Of course, this second approach is less reliable than the first one. But it is a good starting point when beginning from scratch.

 

Regarding the decision to authorize implementation, a real opposition power must be given to the Change Manager and accepted by all stakeholders involved in change. Of course, this power must be used guardedly and wisely.

 

Complete processes for compliance control (with norms covering application architecture, infrastructure, data), then for test covering the nature of customer guarantees, must be enforced (and formalized in SLAs). Just like for aircraft manufacturing, where operations excellence and test comprehensiveness are standards. Of course, requirement levels vary, depending on the criticality of business IT Service. Control processes must be adapted according to impacts. There too, the approach consists in comparing the cost of risk (of Service unavailability) to savings in terms of formalization and norms control.

 

Maintain "embedded quality" principles

Even if there are no more controls, principles aimed at “embedding quality” as soon as the first build stages can be shared between stakeholders involved in various activities, whether at build or integration stage.

 

These principles are various:

 

►  Use a framework with standard modules of development aimed at focusing on program re-use, scripts, software package or operating system settings and other specifications meant to be re-used, in order to limit duplication of efforts

 

►  Set up norms and standards as regards design, test and integration, aimed at sharing principles considered as compliant with service requirements (or service levels), preventing each team from setting up its own norms

 

►  Formalize standard design and test, or integration and certification processes, guiding stakeholders towards the use of the above principles. Of course, these standard processes should be integrated as “standard processes*” in project methods

 

►  Automatically rely on test teams independent from build and integration teams, highlighting by nature any non-conformity, without compromising

 

►  Automate repetitive and standardized process activities through industrialization tooling

 

►  Enforce control checklists and real or declarative checks carried out by initiators themselves

 

 

* Here the notion of “standard process” refers to CMMI maturity Level 3 and any equivalent in other project frameworks. The main objective here is to perfectly integrate the objective of standardization in existing project methods, rather than add another framework or method on top (which would by no means be a contribution to agility).

 

Set-up simple but strict Release Policy principles

Another IT Department requirement is discipline around the planning of releases. Even if release teams see changes come up on the fly, their implementation in the live environment must follow a structured planning providing both the frequency necessary to business, and the preservation of the stability of existing IT Service.

 

Relying on "release windows", (see chapter about "True life"), the organization sets up authorized changeover windows based on business impacts, regardless of Release Units content, without trying to set up policies specific to IT Service, application areas or businesses.

 

Develop a responsible culture

In order for all these more “permissive” principles to operate, the organization must acquire a “responsible” culture. This culture requires a mature behavior from organizations stakeholders, guided by the sense (or awareness) of customer service, responsibility towards risk, capacity to focus on re-using rather than being tempted to exercise one's competences on one's own developments, and on the opposite, the sense of sharing gained knowledge to evangelize other teams with identified good practices.

 

Even if some of these qualities are at the heart of the spirit of the Agile manifesto (such as giving a stakeholder “end-to-end” responsibility over a deliverable or trying to simplify in all areas), gathering them all and sharing them with all their employees remains a very ambitious objective for a number of organizations. That is why a minimal balance between freedom and control must be preserved.

 

 

Illustration of an adapted Change Management scope for organizations wishing to use a light package:

(End of article)

 

 

Copyright © 2013 - PRACT Publishing

iStock_000013603983Small - looking.jpg


External links

►  No link


Related products

►  Change & Release ...