Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Sat Nov 24, 2007 1:31 am Post subject: Successful change: definition?
I just found this forum and I'm very happy to join this community. It will be a great experience to exchange on Itil concepts.
Now, I got a question from my user community regarding Change Management. They're having discussions about the metric of "Successful change". In essence, they're having problem to agree on when is a change considered "Successful".
My quick answer would be : it's whatever the business needs it to be. However, I'm wondering if there are some guidelines on this. I've gone back to the Itil v2 books but couldn't find a clear definition. I just got a copy of the Itil v3 and I'll see if there was cleared up. However, I was wondering if anyone has some best practices guidelines on the definition of a "Successful change".
Thanks _________________ ------------------------------------------
Jean-Francois Cyr
Senior Business Advisor, Chorus Solution
CGI Group
(Note from Admin: No Advertising Link Please)
just remember what may be a success for the business may be a total disaster for IT (it it involved a lot of manual work etc).
What I do is to capture the change success criteris in the change form before it goes to cab or is approved. That way after implementing the change it is easy. If your outcome is as you documented and expected then its successful. If not then it has not. Also if you get the expected outcome but the change actually caused a problem it would not be deemed a success as it introduced an error - you can have closing codes to futher define this. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
Joined: Oct 26, 2007 Posts: 295 Location: Calgary, Canada
Posted: Tue Nov 27, 2007 2:23 am Post subject:
Mark is correct that it is important to specify a success criteria for each change. That is how the change owner as well as implementation team will be able to identify whether they have implemented what was required.
It is also however important to have a more general/global success criteria from the overall Change process perspective, e.g. staying within specified time window, not causing additional incidents, proper resource utilization, etc.
Personally I haven't seen any guidelines to that regard myself and you probably will be hard-pressed to find a standard set anyway. From business perspective, I would refer to the business objective and KPI's for your Change Management process and see if you can derive some success criteria from there.
I asked to my change owner that gives me change goal in SMART form; when change owner ends change I ask to business if objective was accomplish according with SMART goal.
Other aspect is if change was done on time and finally that change doesn’t generate incidents.
My definition of a successful change is this: if the implementation plan clearly states the intent of the change, and the change has been implemented in production and no customer impact has been cause, then the change is successful.
On the otherhand, if the implementation was not clearly defined but the scope of the change lacked or did more to what was intended and has customer impact, then the change is unsuccessful.
Business can define what needs to be done in production but if the business accepts the risk of the deliverable "as designed" then the change can be successful.
Look at it in this perspective, if you plan to paint a house you can paint the house with a brush, roller, or sprayer or a combination of all. But you cannot paint a house with a hammer.
Again, you wont paint the roof or the windows. So the paint, brush, roller and/or sprayer are you implementation plan. If the plan lacks paint or one of the above tools then the purpose of painting the house wont achieve the desired outcome.
In addition, if you have all the tools necessary along with the paint, but you painted all the windows. Again, the purpose of painting the house didnt get the desired outcome since you now have painted windows.
Posted: Mon Dec 03, 2007 2:08 pm Post subject: successful changes
In my organisation, the view is that a successful change is one that:
- fulfills its justification
- PVT performed successfully
- is performed according to what is documented (tasks, timings)
- does not result in incidents being logged after implementation.
If there is a variance to the above, ie additional tasks needed to be performed within the change window to achieve success, or the change was performed as documented but ran beyond the change window, we classify this as "Successful with errors", in that there is no business impact, its justification has been fulfilled, but there is a need to review the change to obtain learnings/improvements for next time - something unexpected happened, how do we prepare for it for next time?
- Steps to implement change
- Decision points
- Steps to roll back change when a decision point demands rollback
Therefore by our definition a change can be successful if it reaches one of two states:
- The change is implemented, or
- The change is rolled back to a predefined state (defined in the implementation plan)
If the change ends up in some state that hasn't been defined as a finish-point in the implementation plan, then it is a failed change.
Therefore, a successful change could cause incidents to be raised during/after the change (generally, these would have been known and acceptable risks), and can cause distruption to the business (also identified as a risk).
It's all a question of "Was the change implemented exactly as described in the implementation plan"?
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Wed Dec 19, 2007 9:18 pm Post subject:
So: as long as you describe in your implementation plan that the change WILL cause incidents, it is still a succesfull change? Does your i.p.t. (implementation plan template) provide for indicating the number of expected incidents? Does it leave room for problems? Where is your business perspective?
Chilly wrote:
All our implementation plan's need to contain:
- Steps to implement change
- Decision points
- Steps to roll back change when a decision point demands rollback
Therefore by our definition a change can be successful if it reaches one of two states:
- The change is implemented, or
- The change is rolled back to a predefined state (defined in the implementation plan)
If the change ends up in some state that hasn't been defined as a finish-point in the implementation plan, then it is a failed change.
Therefore, a successful change could cause incidents to be raised during/after the change (generally, these would have been known and acceptable risks), and can cause distruption to the business (also identified as a risk).
It's all a question of "Was the change implemented exactly as described in the implementation plan"?
So: as long as you describe in your implementation plan that the change WILL cause incidents, it is still a succesfull change? Does your i.p.t. (implementation plan template) provide for indicating the number of expected incidents? Does it leave room for problems? Where is your business perspective?
I would change the word WILL to MAY, in your above quote.
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.
Just because a broadcasted outage notification has gone out to 30000 users doesn't necessarily mean none of them will ring up with an incident directly attributed to the change. You may get 1 call. You may get 1000 calls. The change can still have been implemented successfully within the window.
...The object of the exercise is to introduce Changes without an impact on the business.
If a Change causes an incident of any shape or form, it cannot possibly be considered successful.
I still disagree.
The object of the exercise is to implement change with a known / calculated risk. If the calculated risk says "it's likely we will receive incident calls during the change" then that is a known risk - either accepted by the business or not accepted by the business.
If it's an accepted risk, then when it occurs, you can't turn around and say the change failed.
Ed wrote:
...As far as I am concerned such a change would be considered a Failed Change, or at best, a Problem Change...
Ohh that's scary - what's a problem change? Does ITIL have a "Problem/Change" definition now?
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Thu Dec 20, 2007 5:49 pm Post subject:
Hi Chilly
Chilly wrote:
The object of the exercise is to implement change with a known / calculated risk. If the calculated risk says "it's likely we will receive incident calls during the change" then that is a known risk - either accepted by the business or not accepted by the business.
My immediate reaction was "What a load of toffee!"
So I went back to the Blue book
"The goal of the Change Management process is to ensure that standardised methods and procedures are used for efficient and prompt handling of all Changes, in order to minimise the impact of Change-related Incidents upon service quality, and consequently to improve the day-to-day operations of the organisation."
So I stand on what I said. You do not as a general rule accept that a Change will cause incidents!
I have made certain words bold because I think they are very important.
If we accept that a Change may/will/could cause incidents as a matter of course, why the hell do we bother? We might as well go home now and let the cowboys have their way!
Chilly wrote:
Ohh that's scary - what's a problem change? Does ITIL have a "Problem/Change" definition now?
No it doesn't , but I do!
If a Change has minor issues that are fixed during implementation, then we call that a Problem Change. OK OK It's not ITIL, but it works for me
"The goal of the Change Management process is to ensure that standardised methods and procedures are used for efficient and prompt handling of all Changes, in order to minimise the impact of Change-related Incidents upon service quality, and consequently to improve the day-to-day operations of the organisation."
So it seems the blue book and I are saying the same thing - key work minimise. It doesn't say "..in order to eliminate all possiblity of a change related incident". Instead it implies that change related incidents may occur, and that your implementation plan should help to minimise the possibility of incidents occurring.
Therefore there is no reason why your implementation plan can not specify that service calls (incidents) may be received during this change, and the change can therefore be categorised as successful should incidents be raised as a result of your implementation.
Ed wrote:
If we accept that a Change may/will/could cause incidents as a matter of course, why the hell do we bother? We might as well go home now and let the cowboys have their way!
We bother because we are trying to balance the risk/impact/cost of doing the change with the risk/impact/cost of not doing the change. If we demand that any change with a risk / likelihood of causing an incident not be approved (as by your definition it will be a failed change), then the change process will be bypassed for high risk changes, and the cowboys will find a non-controlled way of doing it instead.
in this world it would be great to be ablle to implement change without risks and the potential of problems. It would be great to have the number of staff required to deliver 100% customer satisfaction 100% of the time. it would be great to be given the budget to fix everything and have 100% availability, capacity etc etc. But alas in the real worldd this is not so. To do so bears too much cost.
Same applies to changes. if you are given enough time and resources you can almost elimiate any side effects. With less time and resources provided to change you icrease the potential of risk and the potential of something going wrong or issues being caused.
So with change management we try to ensure that changes are introduced with mininmal risk and minimal impact.
Be sure that management sign off on any change that medium or significant risk. After all they have to accept the risk on behalf of the users and the organistaion. IT should not be accepting the risk alone. if there are issues from such a change it will be determined from your success criteria if it was successfull of not.
I would not add that "we expect to receive calls from users with isues during this change" as a success criteria. I would expect that especially if you are changing systems that users use. You have to go back and look at what you are trying to achieve and did you achieve it e.g. upgrade from version x to version y within 4 hours. Your change windos here is 4 yours. Spend 10 hours doing the change and the upgrade is ok can still be considered a success - but you would need to look at why it tool 6 hours longer and learn from that for the next time. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Fri Dec 21, 2007 1:42 am Post subject:
Chilly wrote:
The goal of the Change Management process is to ensure that standardised methods and procedures are used for efficient and prompt handling of all Changes, in order to minimise the impact of Change-related Incidents upon service quality, and consequently to improve the day-to-day operations of the organisation."
So it seems the blue book and I are saying the same thing - key work minimise. It doesn't say "..in order to eliminate all possiblity of a change related incident". Instead it implies that change related incidents may occur, and that your implementation plan should help to minimise the possibility of incidents occurring.
Therefore there is no reason why your implementation plan can not specify that service calls (incidents) may be received during this change, and the change can therefore be categorised as successful should incidents be raised as a result of your implementation.
It says 'minimise' not 'allow for' which is my sticking point. I have been in this game too long to expect every change to smoothly!
Ed wrote:
If we accept that a Change may/will/could cause incidents as a matter of course, why the hell do we bother? We might as well go home now and let the cowboys have their way!
Chilly wrote:
We bother because we are trying to balance the risk/impact/cost of doing the change with the risk/impact/cost of not doing the change. If we demand that any change with a risk / likelihood of causing an incident not be approved (as by your definition it will be a failed change), then the change process will be bypassed for high risk changes, and the cowboys will find a non-controlled way of doing it instead.
I hear what you are saying, but still am in basic agreement with both Michel & Mark.
We have to try not to just give in. That is what I see you doing.
If you are not going to make the attempt to reduce those risks down to an absolute minimum then you might as well go home!
For myself, I will always strive to achieve the impossible - the perfect Change
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
Does your i.p.t. (implementation plan template) provide for indicating the number of expected incidents? Does it leave room for problems? Where is your business perspective?
Ohh that's scary - what's a problem change? Does ITIL have a "Problem/Change" definition now?
No it doesn't , but I do!
