Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: CMotley
New Today: 154
New Yesterday: 176
Overall: 131399

People Online:
Visitors: 48
Members: 0
Total: 48

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - Successful change: definition?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Successful change: definition?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
jfcyr
Newbie
Newbie


Joined: Nov 23, 2007
Posts: 2
Location: Montreal

PostPosted: Sat Nov 24, 2007 1:31 am    Post subject: Successful change: definition? Reply with quote

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)
Back to top
View user's profile Send e-mail MSN Messenger
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Sat Nov 24, 2007 1:36 am    Post subject: Reply with quote

Hi,

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
Back to top
View user's profile
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Tue Nov 27, 2007 2:23 am    Post subject: Reply with quote

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.

Hope this helps,

Michael
Back to top
View user's profile
Vida
Newbie
Newbie


Joined: Nov 14, 2007
Posts: 1

PostPosted: Tue Nov 27, 2007 5:16 am    Post subject: Reply with quote

Hi

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.

I hope that this information was useful for you
Back to top
View user's profile
jmc724
Newbie
Newbie


Joined: Nov 06, 2007
Posts: 14

PostPosted: Tue Nov 27, 2007 1:23 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
Ines
Newbie
Newbie


Joined: Mar 21, 2006
Posts: 18

PostPosted: Mon Dec 03, 2007 2:08 pm    Post subject: successful changes Reply with quote

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?
Back to top
View user's profile
Chilly
Newbie
Newbie


Joined: Dec 18, 2007
Posts: 6
Location: Australia

PostPosted: Wed Dec 19, 2007 11:02 am    Post subject: Reply with quote

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"?
Back to top
View user's profile
m_croon
Senior Itiler


Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Wed Dec 19, 2007 9:18 pm    Post subject: Reply with quote

So: as long as you describe in your implementation plan that the change WILL cause incidents, it is still a succesfull change? Cool 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"?
Back to top
View user's profile Visit poster's website
Chilly
Newbie
Newbie


Joined: Dec 18, 2007
Posts: 6
Location: Australia

PostPosted: Wed Dec 19, 2007 10:59 pm    Post subject: Reply with quote

m_croon wrote:
So: as long as you describe in your implementation plan that the change WILL cause incidents, it is still a succesfull change? Cool 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. Rolling Eyes

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.
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Thu Dec 20, 2007 12:15 am    Post subject: Reply with quote

Sorry

I am with Michel here.

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.

As far as I am concerned such a change would be considered a Failed Change, or at best, a Problem Change.

Regards

Ed
Back to top
View user's profile
Chilly
Newbie
Newbie


Joined: Dec 18, 2007
Posts: 6
Location: Australia

PostPosted: Thu Dec 20, 2007 9:37 am    Post subject: Reply with quote

Ed wrote:
...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. Confused

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


Surprised Ohh that's scary - what's a problem change? Does ITIL have a "Problem/Change" definition now?
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Thu Dec 20, 2007 5:49 pm    Post subject: Reply with quote

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!" Smile

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! Shocked


Chilly wrote:

Surprised Ohh that's scary - what's a problem change? Does ITIL have a "Problem/Change" definition now?


Laughing 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 Embarassed

Regards

Ed
Back to top
View user's profile
Chilly
Newbie
Newbie


Joined: Dec 18, 2007
Posts: 6
Location: Australia

PostPosted: Thu Dec 20, 2007 6:30 pm    Post subject: Reply with quote

Ed 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.

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! Shocked



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.
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Thu Dec 20, 2007 8:13 pm    Post subject: Reply with quote

Hi,

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
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Fri Dec 21, 2007 1:42 am    Post subject: Reply with quote

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! Smile

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! Shocked


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! Sad

For myself, I will always strive to achieve the impossible - the perfect Change

Regards

Ed
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.