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.
[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".
Posted: Thu Apr 07, 2011 5:06 am Post subject: Compromise between Successful and Failed
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.
Joined: Mar 04, 2008 Posts: 1890 Location: Helensburgh
Posted: Wed Aug 17, 2011 4:53 pm Post subject:
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
All times are GMT + 10 Hours Goto page Previous1, 2
Page 2 of 2
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum