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

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)

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

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.

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)

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._________________"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

Last edited by Diarmid on Fri Nov 27, 2009 8:00 pm; edited 1 time in total

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.

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.

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

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?

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

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.