Successful Change Definition ?

Discuss and debate ITIL Change Management issues
User avatar
Murphysbone
Itiler
Itiler
Posts: 13
Joined: Wed Jul 23, 2008 8:00 pm
Location: Newbury

Mon Nov 23, 2009 8:56 am

A very subjective subject it would appear, can anyone tell me what definitions they are using for 'successful change'?

I have presented a fair few to my CTO, but he is of the opinion that even if a change is regressed within the agreed timeframe and as described in the RFC, this change is still NOT successfull...grrrrrrrrrrrrrr

What does everyone else use !?


Simon Humphries

-----------------------------------------

Operations Authority

-----------------------------------------
ITIL Change Practitioner
ITIL V2 Service Manager
ITIL V3 Manager's Bridge
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Mon Nov 23, 2009 9:33 am

Simon

I call successful changes in two manner

successfully deployed changes - it installed OK
Successful implemented change - it installed correctly and the business are happy it does what it said it does
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
mnsmith
ITIL Expert
ITIL Expert
Posts: 109
Joined: Sun Mar 30, 2008 8:00 pm
Location: North West England

Mon Nov 23, 2009 11:06 am

Hi

I categories my changes in two ways: what state did the change end up in and how well it was left in this state.

For example, most of my changes are Implemented-Successful but I also have Implemented-Unsuccessful, Rolled Back-Successful, plus a few such as Canelled and Rejected.
Mick Smith
Change, Configuration and Release Manager
User avatar
Timo
ITIL Expert
ITIL Expert
Posts: 295
Joined: Thu Oct 25, 2007 8:00 pm
Location: Calgary, Canada

Mon Nov 23, 2009 11:21 am

Outlining what 'successful' means BEFORE the change is implemented and then validating against that success criteria will work every time. Promise. It is the same as defining a success criteria in project management, just typically on a slightly smaller scale.
User avatar
Murphysbone
Itiler
Itiler
Posts: 13
Joined: Wed Jul 23, 2008 8:00 pm
Location: Newbury

Mon Nov 23, 2009 11:35 am

Thanks for the info so far Guys... certainly food for thought.

Timo, exactly what I'm trying to achieve ! Just having a few issues getting Snr Management to agree on the definition of success !! :roll:
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Mon Nov 23, 2009 12:22 pm

I would also use different kinds of criteria for different types of changes

Application, Network, system etc

If a change is because of a need to solve a Problem (ITIL), then if the change is successfully installed and implemented, there would need to be some way to test whether the conditions for the problem have now ceased

some times this is a negative succes value rather than a positive value

for example

System crash due to memory fault ... patch fixes memory issue
system crash due to something else

The patch was successfully installed. it fixed one of the possible solution but the system is still crap. ..... wintel you know ;-0
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Mon Nov 23, 2009 12:42 pm

Simon,

The best way to achieve an acceptable definition is to start at the other end. First agree what you want to do with the status "successful".

What I think you are trying to achieve is a statement about the change management process. In that scenario a change can be deemed successful so long as the process was performed correctly from beginning to end. In other words the change may have delivered no benefit or it may even have been regressed or cancelled, so long as this was caused by an outside circumstance and not as a consequence of a fault in change management activities or process.

Your colleague may be trying to come up with a statement that can be made to a customer (or a measure of service quality as distinct from process quality) about success. In this case any regression, lack of delivery or even delay would tarnish the idea of success.

"Success" is such an everyday word that it is not easy to use in the manner you are asking and perhaps you shouldn't try. You can take John's and Mick's definitions and use each of them in context.

"The change ...
  • ... successfully delivered the desired benefits"
    ... was successfully implemented"
    ... management system successfully cancelled the flawed change before it did any damage"
    ... management system successfully recovered the service by regressing it after issues emerged"
    etc.
Timo hit the nail on the head, but that does not help you. I cannot imagine a change planning process defining an outcome involving regression within the success criteria.

If you need to regress and do so expeditiously and at without undue cost according to the regression plan, then you may have had a successful regression, but you certainly have not had a successful change. Again the distinction between the process and the change.
Last edited by Diarmid on Fri Nov 27, 2009 5:00 am, edited 1 time in total.
"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
User avatar
procman
Itiler
Itiler
Posts: 9
Joined: Tue Nov 17, 2009 7:00 pm

Mon Nov 23, 2009 10:04 pm

We are experiencing similar issues and although a means of addressing has not been formalized some thoughts are that the Change Implementer and the Change Manager are required to identify whether or not the Change has been successful. The former, from strictly an implementation perspective at the time just following implementation and the latter, from the perspective of the 'user community' some days later after enought time has passed to understand if there was any negative outcome as a result.
User avatar
Murphysbone
Itiler
Itiler
Posts: 13
Joined: Wed Jul 23, 2008 8:00 pm
Location: Newbury

Tue Nov 24, 2009 5:27 am

Diarmid,

Good points, well made, thankyou !

I had actually started to look at how I was going to deal with the 'unsuccessful'. The reason for the definition was around Change Governance, not necessarily the process, although this may just be semantics??

My colleague is indeed looking at customer and service impact, I have an objective around reducing the transactional cost of changes, hence the reason for a solid definition of success.
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Tue Nov 24, 2009 6:29 am

Simon,

from a governance perspective, success/failure may be too blunt an instrument. You can get some goals and metrics ideas from COBIT (which you can download), although I'm not fully convinced by their list.
"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
User avatar
Lizh
Newbie
Newbie
Posts: 1
Joined: Mon Nov 16, 2009 7:00 pm
Location: North Wales

Fri Dec 04, 2009 5:34 am

8O
I have tried to look at it from a different direction, what is classed as a failed change?
Our organisation class a failed change as any deviation from the detail within the RFC, for example,
Change implemented without approval
• Implemented outside of the agreed change window
• The functional description is deviated from
• The stated post change testing is not followed
• An unexpected impact is experienced and it is found that the pre change testing environment is found to be different from live
• The service impact is different than stated in the RFC.
• The system specified within the change is incorrect
What do other people class as a failed change?
User avatar
Murphysbone
Itiler
Itiler
Posts: 13
Joined: Wed Jul 23, 2008 8:00 pm
Location: Newbury

Fri Dec 04, 2009 6:52 am

We class failed change as any of the follow scenarios

Regressed (backed out)
Incident as a result of change
Overruns
Un-authorised change
-including deviation form RFC Plan
Rejected
-QoS issue
Cancelled
-QoS issue
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Sun Dec 13, 2009 6:40 pm

I suspect the details are more important than the classification as "failed".

If you have all these categories, what can you gain from lumping them all together to produce a total of "failed" changes?

At the very least you are dealing with:

design processes (not a change process)
test processes (not a change process)
the change approval process
the change planning process
the change implementation process

for rejected changes a vast array of reasoning from "daft idea" to "unfortunately, its just too much to do in present circumstances".

for cancelled changes you have such legitimate (but very different) reasons as discovering practical problems when you get into the nitty gritty of design and test, or changed external circumstances rendering the change inappropriate.

You might also be dealing with defects in the infrastructure, issues with suppliers or just plain old unexpected events.

Any of these might need addressing and most of them need watching/reviewing anyway but, considering how emotive the word "failed" is, what is the audience for the total of all these different circumstances in a single figure called "failed"?
"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
User avatar
DYbeach
ITIL Expert
ITIL Expert
Posts: 413
Joined: Sat May 24, 2008 8:00 pm
Location: Sydney, Australia

Tue Dec 15, 2009 6:52 am

Murphysbone wrote:Thanks for the info so far Guys... certainly food for thought.

Timo, exactly what I'm trying to achieve ! Just having a few issues getting Snr Management to agree on the definition of success !! :roll:
Politics! :lol:
DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell
User avatar
changeborg
Senior Itiler
Senior Itiler
Posts: 42
Joined: Tue Jul 14, 2009 8:00 pm
Location: United States

Thu Jan 07, 2010 3:24 pm

Howdy!

We had similar issues in our organization as well until we realized that while we defined 'closure codes' within the toolset, we never actually put a hard defination to each of them. The most abused one was that of a Successful change. To that, here is what we selected as our defintion of a Successful change:

Any change in which the desired outcome was achieved (i.e. incident resolution, problem resolution, outcome to plan) and no incidents have been noted or raised relating to the change, you shall use the closure code of Successful.

We also have a definition for partial success which may come in handy:

Any Change which is either a deviation from the approved implementation plan, spans outside the approved change window, carried out successfully but does not completely resolve the Problem or Incident it was logged to resolve or any change which results in incidents shall be considered to be Partially Successful. Any change which is classified as being Partially Successful may be subject to an informal or formal PIR to ensure future partial successes are mitigated.
Post Reply