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: Richardhit
New Today: 11
New Yesterday: 75
Overall: 142305

People Online:
Visitors: 69
Members: 0
Total: 69

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 - Why do calculate risks on IT Changes?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Why do calculate risks on IT Changes?

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
RodrigoAlmeida
Newbie
Newbie


Joined: Mar 28, 2006
Posts: 2

PostPosted: Tue Nov 07, 2006 1:56 am    Post subject: Why do calculate risks on IT Changes? Reply with quote

I`ve been thinking about a series of reasons to know the value of the risk on IT changes. The matter is: How the value of risk on IT changes can support the change manager's decisions? In what change management activities the risk value can help? I would like to know from you if these reasons are real reasons for companies to interesting in knowing the risk value of an IT change. The reasons are:
1. The risk value will be useful to set the scheduling of changes (i.e., we only can put changes in a change window whose sum of its risks cannot be higher than a pre-defined value X);
2. We will classify changes based in the risk value (for example, determined changes, by its risk value, will be classified as 'high risk changes');
3. We will prioritize changes in change windows (for example: We will implement first the changes with lower risk value. Later, those with higher risk value)
4. We will allocate staff based in the risk value (example: for changes with bigger risk, we will allocate more qualified staff - We will allocate staff and involve product vendors in the change based in the risk value)
5. We can use the risk value to support decisions during the change implementation, like: Time to implement the change, resource allocation…
6. We will use the risk value to determine how detailed our back-out plans will need to be.
7. Any suggestions? Smile

I would like to know from you, if the reasons described above are reasons that you have in mind when you think about risks related to IT changes.

thanks in advance,

Rodrigo Almeida
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3298
Location: London, UK

PostPosted: Tue Nov 07, 2006 7:49 pm    Post subject: Reply with quote

When I had to make a decision on a specific change as to risk, I would do the follow

What is the service being affected by this change
WHO uses this service
How long would the service be affected
What is the risk if we dont do the change
who and how long would be impacted

and are the system/network/etc engineers capable of dooing the change w/o screwing up - IE havethey done this beofre and how often

I would look at the directly affected and the indirectly affect

It is both a subjective and an objective analyst

I make a preliminary decision and keep it to myself. Then I go back and try to justify the change for & against

Examples

Hardware replacement on a GIGA Switch.

Usually a Card can be hot-swapped from a gigaswitch, especially if the card is bad. However, the card being replaced is not bad and the net engineers want to do this during a peak period because they have staff resource issues. The switch has no low usage time because the other unit in the pair is down for major work. SO I have a SPOF device.

The card needs to be replaced because there is a know fault which will occur which will cause the switch to drop bandwidth

So what is the decision.

If I do nothing, there is a chance of a complete failure of teh switch for a long period (10 minutes+)
If I authorize the h/w swap, there will be a short outage on the VLANs, LANs and bandwidth which were on the card.

So..... what did I do.

My decision was to make this an EMERGENCY Change, due to the change meeting the Emergency change criteria after I involved senior management in the decision making. To be honest, they just went uh uh... what ever you decide john...

Result: notifications went to customers & Service Managers 4 hours before the work being done. Work went off w/o hitch.

I did however have several meeting that week with irate Service Managers but the customers (external) were quite fine on the decision/work
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
JoePearson
Senior Itiler


Joined: Oct 13, 2006
Posts: 116
Location: South Africa

PostPosted: Fri Nov 10, 2006 1:21 am    Post subject: Re: Why do calculate risks on IT Changes? Reply with quote

In addition to John's answer, Rodrigo, I have some comments on your specific points:

RodrigoAlmeida wrote:
1. The risk value will be useful to set the scheduling of changes (i.e., we only can put changes in a change window whose sum of its risks cannot be higher than a pre-defined value X);
It's very difficult to summarise the entire 'risk' of a change into a number, so that you could do things like adding them together.

A change may have several risks associated with it, and the risks could materialise at various stages - readiness (at 5pm Friday pre-requisites are still not ready), preparation, implementation, post-implementation test, user acceptance (for high risk changes you'll need user acceptance even if it's out of hours). Different risks will have different possible back-out plans - and a change properly backed-out avoids any impact of the failed change in the live environment. (Not having the change may have a financial impact as well, though.)

Also you need to look at dependent changes and risks - a good rule might be no more than one change affecting a given system, unless they have been built and tested as a single release.

RodrigoAlmeida wrote:
3. We will prioritize changes in change windows (for example: We will implement first the changes with lower risk value. Later, those with higher risk value)
I don't think this is safe. In many cases a higher risk change could require more time for back-out, so you should do it earlier. It depends.

RodrigoAlmeida wrote:
4. We will allocate staff based in the risk value (example: for changes with bigger risk, we will allocate more qualified staff - We will allocate staff and involve product vendors in the change based in the risk value)
5. We can use the risk value to support decisions during the change implementation, like: Time to implement the change, resource allocation…
6. We will use the risk value to determine how detailed our back-out plans will need to be.
These are good decisions to make, but I feel that you should make them directly from the detailed change plans and impact assessment - not from a numerical risk value number which will inevitably lose some information.

Of course, after you've done the planning and made all those risk-containment decisions, a risk value per change may help to communicate to management and users why you've rejected certain changes or why the overtime bill will be higher!

Joe
Back to top
View user's profile Visit poster's website
Globis
Itiler


Joined: Apr 17, 2007
Posts: 36
Location: Cape Town

PostPosted: Fri Apr 27, 2007 5:16 am    Post subject: Reply with quote

Quote:
3. We will prioritize changes in change windows (for example: We will implement first the changes with lower risk value. Later, those with higher risk value)


This is not really the way to deal with risk. If at all possible you should never make high risk changes at all.

The whole point of performing risk assessment is so that if you identify potential risks, you then put extra effort into finding mitigating factors to reduce the risk, and once those factors are applied, you end up with a residual risk. If that level of risk is acceptable, you make the change, if it is not then you either do not make the change, or look for more mitigating factors.

In other words you do notmake high risk changes.

Dave
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
Page 1 of 1

 
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.