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: JKnowles
New Today: 16
New Yesterday: 56
Overall: 145994

People Online:
Visitors: 65
Members: 3
Total: 68 .

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 - Bug Fixes - Change Management?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Bug Fixes - Change Management?

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


Joined: Oct 30, 2007
Posts: 16

PostPosted: Tue Mar 04, 2008 7:28 am    Post subject: Bug Fixes - Change Management? Reply with quote

I'm unsure what ITIL best practice says here, but I'm looking for some feedback/suggestions.

Should every application bug fix be pushed through Change Management or addressed as an incident?
    * The fix is to a service in production
    * The code is well tested before being pushed to production
    * The number of bug fixes weekly are quite large
How do others handle this? Do you handle the scenarios as emergency change requests? Do you submit a weekly bug fix list to CAB for approval? Do you handle them simply as Incidents to correct the application without submitting to CAB?
Back to top
View user's profile
mg10_86
Itiler


Joined: Jan 21, 2008
Posts: 21
Location: Canada

PostPosted: Tue Mar 04, 2008 8:20 am    Post subject: Reply with quote

Ideally, they would go as a standard change (pre-approved by the CAB).
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Tue Mar 04, 2008 12:09 pm    Post subject: Reply with quote

Bug fixes would go to the change management process.
The question is why was there a large number of bug fixes in a week?
There must be something wrong with the application
Back to top
View user's profile
Ed
Senior Itiler


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

PostPosted: Tue Mar 04, 2008 5:52 pm    Post subject: Reply with quote

Hi kwinston

The basic answer to your initial question is 'Yes'

All bug fixes imply a broken application, and therefore a loss of service to the user. This requires a SD ticket to be raised, and then a Request For Change needs to be raised to correct each fault.

There might be a case for raising a 'collective' RFC, but this is not usual in my company. The only circumstance that would allow this, would be if all the faults are repeats of the same fault. e.g. a router keeps failing on a specific network path, meaning a replacement is required.

I would not expect to cover bug fixes with a Standard Change, unless the requirement to cure the fault(s) was a hardware swap out. Code problems within an app are not covered by a Standard Change

All Changes should be well-tested before being put anywhere near Production, so this statement puzzles me!

Are you referring to the cut-down testing that moght be allowed for an emergency change? Even this testing should be as complete as is possible given the compressed time frame.

I hope this has been of some help
_________________
Regards

Ed
Back to top
View user's profile
Skinnera
Senior Itiler


Joined: May 07, 2005
Posts: 121
Location: UK

PostPosted: Tue Mar 04, 2008 7:43 pm    Post subject: Reply with quote

Incident raised for the service problem experienced, bug identified and either RFC raised on the back of the incident if the fix is available, or the incident goes to a problem and the RFC is raised on the back of that when the fix gets built.

But yes, always under Change Control.
Back to top
View user's profile Send e-mail
kwinston
Newbie
Newbie


Joined: Oct 30, 2007
Posts: 16

PostPosted: Wed Mar 05, 2008 3:48 am    Post subject: Reply with quote

Thank you all for your replies. Come to find out, majority of what they were lumping into the category of bugs were really escalated requests or enhancements to applications...not broken code. Again, thank you!
Back to top
View user's profile
OhioScott
Itiler


Joined: Oct 29, 2007
Posts: 26

PostPosted: Tue Mar 25, 2008 5:47 am    Post subject: Reply with quote

Sorry to be chiming in late on this but I was taught by an instructor from a company with a colorful pachyderm that a break/fix only went through Change Management if the resolution modified the CI.

If the resolution is simply restoring the CI to the approved baseline (whether swapping out like-to-like hardware or re-installing the baseline code) that this was not documented as a change. Only if the resolution actually changed the CI (different router or switch, or modifying code from baseline) would documentation be required.

Now I'm not saying anyone is wrong... and this training was 4 years ago... but has the documentation of break/fix always been considered to go through Change or is this up to interpretation?
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Tue Mar 25, 2008 10:09 pm    Post subject: Reply with quote

OhioScott,

The important thing here is for break/fix or change is the urgency of the break / fix.

and be pragmatic

If your incident tool links to your cmdb and the CI being 'unbroke / fixed' is tracked in the incident and the incident includes the fact that there is no service, then i would just use the incident to track the break/fix and h/w swap

if the incident that is break / fix and there is currently no outage and the solution to the incident is to replace h/w and incur downtime, track it in change management

the reason is that usually SLAs are sometimes written that approved changes that incur down time do not count against any availability stats or such like.

Our maintenance windows were exempt from the % availability

As to software bug fixes, i always recommend changes to manage this
but first i always insisted that the software team does a build / test in the dev world first

if this can not be done, when the change is raised, it should say so explicitly

And if the s/w bug fixes are tracked via both change and incidents, this should highlight to management that there is something wrong with the application
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
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.