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: ncfguwtyspao
New Today: 25
New Yesterday: 106
Overall: 149901

People Online:
Visitors: 47
Members: 3
Total: 50 .

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 - Reduce Incidents Caused By Change
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Reduce Incidents Caused By Change

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
JDYE
Newbie
Newbie


Joined: Aug 26, 2010
Posts: 2

PostPosted: Fri Aug 27, 2010 1:15 am    Post subject: Reduce Incidents Caused By Change Reply with quote

Hello,

I'm just a newbie so be kind to me.
We are a large IT business and have been using ITIL standards for Change and Problem mgmt. for sometime now. We require Controlled work instructions with Peer Reviews but we still have a high number of incidents caused by change.
Simple story is that most are caused by human error. People not following the work plan or sleep deprevation might be the cause. Could be that people are just not following their work plan 100% and/or "fat fingering" their typing.
I have researched the web and can find tons of info on HOW you "should" manage change but I can find nothing on how to reduce the number of incidents caused by change. Expecially when human factors are involved.

I guess I'm just looking for common sense advice.


Thanks !
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Fri Aug 27, 2010 1:58 am    Post subject: Reply with quote

JDYE

First questions:

How do things go to Production ?

a) they are tested first using the same instruction set in a non production environment by the same team / individual that will do it in Production

b) it is done for the first time in Production

Are these done as Emergency Fixes and Rushed to be done ?
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


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

PostPosted: Fri Aug 27, 2010 2:51 am    Post subject: Reply with quote

Wow... you almost sound kind, John.

I had same question - how do changes get into prod? To add to John's, do same people deploy changes to prod and produce and test (presumably) rollout work instructions? If yes, there will be propensity to make shortcuts.

Have you tried the threat of physical violence technique?
Back to top
View user's profile
JDYE
Newbie
Newbie


Joined: Aug 26, 2010
Posts: 2

PostPosted: Fri Aug 27, 2010 4:09 am    Post subject: Reduce Incidents Caused By Change Reply with quote

Well, without telling too much of myself on the Internet I am 6'4" and 260lbs so yes I have thought about "physical" compliance. (jus kidding) !

We do have some test and pre-prod environments where some changes can be tested. Our systems are very complex which makes it hard to have a test environment for everything especially Network and SAN.

The change requestor is the same person performing the change (99% of the time) and doing the testing were possible.

All planned changes with a moderate or major impact must go through our CAB. All Standard and Normal (minor) changes are self- approved with a work instruction and peer review. So at the very least even the simplest change would have 2 people review the work instruction prior to implementing.

I hate to tighten the screws on technical peer reviews but if mistakes are taking place then people are not following the WI or there are errors in the WI.
Back to top
View user's profile
Timo
Senior Itiler


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

PostPosted: Fri Aug 27, 2010 5:33 am    Post subject: Reply with quote

I hear you about the complexity of the env't and testing... it's a pretty common problem I think.

Well... I don't know if there is one answer that will solve your problem but with one client we did significantly reduced incidents caused by moving changes into production by segregating build and test roles from deployment roles. Most of deployments happened at night, making people responsible for deploying less than happy... hence the deployment team went an extra mile (more like harassment toward developers and testers) to ensure that the instructions and packages they were given would work, so that they wouldn't have to stay up any longer than they had to.

Personally, I love nothing more than tightening screws on techies and developers but they don't pay attention to me cause I am "the process guy". When their other technically inclined peers apply the same pressure it has different effect. It's kind of a soft stuff, but in our example it worked.

I am sure others (when they wake up) will have different suggestions.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Fri Aug 27, 2010 5:33 am    Post subject: Reply with quote

The only way to reduce the change related incidents is to investigate the occurrences. If there are quite a few then there should be some underlying pattern that will point to what needs to be remedied.

Perhaps people are under pressure, perhaps instructions lack detail (or have too much detail), perhaps their is a training need, perhaps the environment is overly complex, perhaps there are inadequate controls on the configuration or operational processes.

One thing for certain, attitude (or culture) is important. Do the staff understand (in their gut or heart Smile) the importance of the transition activities? Do they see it as a chore before getting into their next exciting project? Are development and operations different countries with border disputes or is everyone sailing the same ship in the same direction?

Try going over the details with the people making the mistakes and ask them how things could be different to prevent such errors in future. Make sure everyone understands that the quality of the release process is as vital as the quality of the development.
_________________
"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
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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.