Change based on an Incident/problem

[Robbie_Van_Hoegaerden]

Hi all,

In my company I've following discussion :

Person A (technical person) :

An incident has to be separate from a change, even ITIL indicates these 2 things as something different:
An change is to upgrade or to prevent further incidents, an incident is something that needs to be resolved asap (quick fix and can result later on by a change for descent fix)
Hence, the priority with an incident is to fix the issue at hand, if multiple incidents occure (or the incident is big enough) then you have a "problem" --> should be taken on and can result in a change to prevent further incidents.

I (as operational change manager) :

I don't agree with the above. A 'permanent' change to solve an incident = a change (even a quick fix has to follow the change rules). I want them to follow the change process rules in the above case.

Question :

How to convince the technical experts about the above. We can make rules and tell them to follow it. But still we'll have the same discussion over and over again. I want to convince them it's in their best interest, but they feel it's a loss of time and thus follow these rules without persuasion.

Thx in advance for the possibles examples of ways how to handle this.

Robbie Van Hoegaerden
Colruyt Group Services (>20000 employees).

[Diarmid]

Robbie,

in one sense your protagonist is correct; you do want to restore service as soon as you can. However any proposed action to restore service must be subject to risk and cost analysis (however quickly and broad-brush). That is what change management is for.

When someone quotes "book" at you, it is often best to change the ground, go back to basics and talk about what is really required.

Incidents that can only be resolved by means of a change (whether temporary or permanent), require that change to be implemented as quickly as possible (call it an urgent change or an emergency change if you like - then you can define specific processes for that context). All changes need to be managed:

Risk
there are areas of risk to consider - the risk inherent in the change (e.g. might it overload a server?) and the risk inherent in the performing of the change (e.g. if we send our only engineer to the Outer Hebrides to do this, how will we cope with his/her absence?)

Cost
what are the costs involved; do the outweigh the benefits?

Analysis
how certain are w that this change will resolve the issue?

Testing
To what extent does our test plan ensure that the change will work?

Contingency/Backout
Are we prepared for the possibility that the change will fail

If you have a high impact incident, you want to do all this very quickly and this increases the risks. Someone needs to sign off on the risks, legitimately representing the business rather than IT Services.

I dare say that many incidents are relatively straight forward and reasonable evaluation and controls can be achieved in little more than a matter of minutes whereas others will require hours of hard work to be sure that the risks are understood and how to manage them However there are also instances where something seems simple, but in fact have hidden consequences. This is why the process needs to be rigorous so that, by involving all the interested party (e.g. CAB), there is a t least a chance that the true complexity will be discovered in good time.

I seem to be waffling. Sorry.

Another point: I'm sure it has happened a million times that a technician has rebooted a server without even bothering to check if anyone else was using it.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[SubbuA]

Have your policy document record the need for having an approved change request for any changes made to the CI

I rekon your issue is on because you do not have a matured change management policy document. Formulate one - get buy-in from stake holders ane use it with rigour
_________________
Regards,
Subbu A
ITIL Certified and well experienced

[Robbie_Van_Hoegaerden]

Thx for the feedback.

I'll keep in mind the mentioned strategies/handlings and get back with some feedback.

Robbie.

[tstomczak]

in my shop, an incident happens, and in order to restore service, an emergency change (break/fix repair) is implemented to do so... After the fact, the "change" is documented and then the change is completed / closed and the incident is resolved...

The Incident says whats wrong
The emergency change "fixes" whats wrong in order to resolved the incident...

[Diarmid]

tstomczak,

documenting a change is not the same thing as managing it. After-the-fact documentation may be acceptable (to some), but a lack of risk and cost analysis, planning and preparation, authorizing and communication, etc. etc. are undesirable even in an "emergency".
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718