Successful change: definition?

[Skinnera]

For my organisation, I have defined a Successful Change as follows;

A Change that was implemented and satisfied its prescribed criteria by meeting all of the following conditions:
• Delivered fully what was expected
• Fixed what it should have
• Did not have any unexpected impact on service
• Did not have to be backed out.
• Did not over-run its Change Window

However we are just about to move to a very different model, which does away with Successful and Failed in favour of these more informative options;

Implemented - No Impact
Implemented - With Impact
Backed Out - No Impact
Backed Out - With Impact

These are less subjective and emotive, and accurately describe exactly what happened at the end of the Change's lifecycle.

[Ines]

[quote="Chilly]The possibility that an incident may occur, may be a known risk. It may be very likely that when you cut over the core router, you will recieve some incident calls from users saying they can't access the system.[/quote]

It may be a known risk, but it doesn't mean stakeholders are happy to wear it if it happens. IT's not like you would make a change, it break something, and leave bits broken. You would fix the broken bits. Those risks still need to be mitigated.

A successful change should not require utilisation of a backout plan, or additional resources, time and effort than that documented in the implementation plan. Everything should still work as though the change never happens - key phrase is that it should be "seamless to the end user".

[TomG]

Chilly and Ed, great back and forth. I struggled with the same topic a few years back and so I introduced a classification of, Successful With Problems.

Call it what you will, there was a need to capture changes that were implemented to plan and gave the requestor/benefactor/stakeholder what they wanted but an issue appeared in production that was otherwise unforseen.

There's usually no easy way to capture these types of occurances but the few that did get caught were quickly classified in our change reporting and since I held the problem manager title, I bypassed trending it because there weren't enough to be trended and went right into problem analysis and gathering info.

As for a successful change definition, my criteria matches that of the posting from Skinnera with slight modification.

Whatever criteria you choose to define a successful change, my advise based on learning for past mistakes is to ensure you involve your CAB members and process sponsors in designing them and to get buy in. You'll need this upper management support and CAB support when your assessments or the change results are challenged by those who don't want to be measured because they will have a perception that they need to defend themselves if anything perceived as negative arises.

My first post.... hope I'm not off my rocker... I love this kind of stuff.

[Pixxolo]

Hi All.....please advise on this....

Here is the example:

RFC is submitted and approved for Date X @ 21:00.
RFC is communicated and scheduled on a Forward Schedule of Change Calendar….effectively ‘reserving’ that date/time.

The implementation date/time passes without any change being made and no notification to Change Management.

Question:
Should the RFC be marked as FAILED?

[noneforit]

What does your CM process define as a 'Failed' change

We currently use 'Sucessful' and 'Unsucessful'

Using your example, that would be an unsucessful change according to our definition

They said they were going to do XYZ at a particular time and they didn't do that, so would be an unsucessful change

The change itself hasn't failed (as in gone wrong) but it has failed to happen so it would be down to how you define a failed change

[Diarmid]

Does it matter to your management whether a change (not an RFC) has failed or has not been applied?

Is such high level and undefined information of any value? Can you make use of 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