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


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: CurtLind
New Today: 5
New Yesterday: 37
Overall: 231690

People Online:
Visitors: 113
Members: 0
Total: 113



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.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Assessing potential risk of a proposed change
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Assessing potential risk of a proposed change

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

Joined: Jun 06, 2010
Posts: 10
Location: Canada

PostPosted: Fri Nov 19, 2010 4:10 am    Post subject: Assessing potential risk of a proposed change Reply with quote

Earlier this year I changed the risk assessment questions we use to calculate the risk level (in Remedy). This risk assessment was developed with input from our CAB members and SMEs and thoroughly tested but it seems weíre at the point where we have to fine-tune it further. I would like some input from all of you experienced ITIL people out there on how we can better evaluate the potential risk of a proposed change. In our environment, it seems lack of communication and projects trying sneak changes under the radar (i.e. donít go to CAB because of low risk level) are the biggest threats to the environment.

Are we asking the wrong questions? If so, any suggestions as to what should be asked (I have some thoughts)? I donít want to be changing the risk assessment every 6 months because of behavioural issues or 'hot topics' so I want to know what works in your environment.

1) Have you consulted with all governance processes to determine IF sign-offs are required? (I.e: architecture approval, operational readiness, business approval, CI approval, security approval, etc.)?
2) Number of people that will be impacted during implementation?
3) Will the change cause interruption of service?
4) What services will be impacted?
5) Pre-implementation test results?
6) What is the potential security risk?
7) Implementation effort?
Cool Back out effort in the event of failure (during or after the implementation)?
9) Business impact in case of a failure?
10) Based on your assessment, how confident are you that the change will succeed?

Your input is highly appreciated!!!
Back to top
View user's profile
Senior Itiler

Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Tue Nov 30, 2010 5:15 am    Post subject: Reply with quote


From the list of questions you gave, it appears to me that some don't really address risk or are unlikely to get you useful answers. For instance, the implementation effort is interesting to know, but doesn't necessarily say much about risk. Also, there will be very few change requesters that are willing to admit having little or no confidence that the change they want to implement will succeed.

When you submit a change, there are a couple of 'related' attributes that need to be set: Impact, Urgency, Priority, and Risk (I know Remedy supports these attributes). For each of these attributes you will need to decide what they mean and what the different levels indicate. Also, you need to prevent "double dipping". By that I mean that if a change will for instance affect a critical business system, then that should not result in a high Impact and a high Risk. Only one attribute should be influenced by each characteristic of a change to avoid building a bias into your change assessment and classification.

Here are some thoughts that I would suggest you consider:
- Use Impact to indicate the consequences of not doing the change. For instance, is there a problem that will continue to exist unless this change is implemented and how severe is that problem? Is the business in a slightly/severely disadvantaged position if we don't put the new functionality in place? [note: some organizations will use Impact to indicate the severity of the consequences when the change fails; you could argue that this is an aspect of Risk.]
- Use Urgency to indicate how important it is to implement the change fast. Is the change to fix a problem that is causing a current/imminent service disruption or is there just a chance that the problem will result in an incident some time in the next 90 days? How much time is left until the deadline when the new functionality must be operational?
- Priority is derived from Impact and Urgency, where you define how the mapping occurs. Priority should tell you something about the overall importance of the change and should for instance drive timing and resource allocation.
- Risk is to indicate the chance of failure/negative side effects and the severity of the consequences.

Some factors to consider when assessing Risk and that should drive the development of your risk assessment questions:
- What is the success rate of past changes to the same system or of a similar nature? (example answers: never done before, successful track record, mixed results, high percentage of failure)
- How representative were the tests performed for this change? (examples: cannot be tested, test is truly representative for production)
- What are the chances that the change and/or back-out activities will take place outside the defined maintenance window (examples: change must be implemented during business hours, if the change fails and need to be backed out itwill probably exceed the maintenance window, change and back-out fit within the maintenance window)
- What will likely be the consequences if the change fails? (e.g. critical/non-critical system, total outage/disruption/minor inconvenience) [note: This should be a reasonable assessment; not "if the changes fails and the stars are aligned unfavorably and the temperature drops below freezing then it will be total disaster". And again: if this aspect is covered by the Impact assessment, then it should not be included here for a second time.]

I hope this gives you some ideas. There is not a single right way to do this, but as long as you define each attribute clearly for your organization and follow the "no double dipping" advise then you should be heading in the right direction.
Manager of Problem Management
Fortune 100 Company
ITIL Certified
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

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.