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: BKittredg
New Today: 8
New Yesterday: 66
Overall: 142227

People Online:
Visitors: 64
Members: 1
Total: 65 .

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 - developement type incidents(?)
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

developement type incidents(?)

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
zoe41
Itiler


Joined: Jun 23, 2008
Posts: 21

PostPosted: Wed Jun 25, 2008 8:36 pm    Post subject: developement type incidents(?) Reply with quote

From an ITIL point of view I wondered what this scenario would be classified as.

Devlopement teams produce some code. It is released into the live environment. THe release is allowed with accepted bugs. These bugs are to be logged in the service desk tools. Probably use a separate type of classification to track report approrpiately. These incidents are effectively accepted as is and therefore should be closed (the business do not want them to be progressed).

However in reality at a future date the business would like to rectify these 'closed incidents' So effectively I am asking in ITIL terms should these closed incidents go into problem management for assessment and eventual passing back to the developement / project environment. At least if they are tracked in Problem management they can be managed and not just fall off the radar.

Is that logical?

regards

Zoe
Back to top
View user's profile
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Wed Jun 25, 2008 8:43 pm    Post subject: Reply with quote

Hi Zoe,

No point passing this to an operation-level PM team. Bug tracking is part of the SDLC, so send the developers a monthly report.

Cheers,

UJ
_________________
Did I just say that out loud?

(Beige badge)
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Wed Jun 25, 2008 8:48 pm    Post subject: Reply with quote

Like UJ Said,

This is a Software development issue.

What I would do is gather teh change request which should have the the list of fixes - both corrected/ uncorrected - and make sure that teh Software development team
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Jun 23, 2008
Posts: 21

PostPosted: Wed Jun 25, 2008 9:28 pm    Post subject: Reply with quote

totally agree it is software development issue. I am trying to work out whether it is appropriate to use the service desk functionality to track / record bug issues in the test environment. Assuming of course that some of these bugs get passed / accepted into the live environment.

I think what you are saying is that the incident is kept open, reported on appropriately managed etc. Then the resulting change request is passed back to the design teams / development teams to fix?

Zoe
Back to top
View user's profile
mnsmith
Senior Itiler


Joined: Mar 31, 2008
Posts: 109
Location: North West England

PostPosted: Wed Jun 25, 2008 10:09 pm    Post subject: Reply with quote

Hello

The important point is that the release has been allowed into the production environment with the known bugs. Therefore, these bugs are part of the advertised Service and should not be handled by incident or problem management.

I'm only new to ITIL but my understanding is that raising an incident against a delivered bug (as opposed to a bug found after delivery) is just as pointless as raising an incident to say you can successfully log on.

Hope that helps.
_________________
Mick Smith
Change, Configuration and Release Manager
Back to top
View user's profile
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Wed Jun 25, 2008 10:15 pm    Post subject: Reply with quote

Zoe,

I'm not telling you anything you don't already know, but most service desk tools will capture whatever you want them to, so you just need to look at how much enhancement work would be required to capture any specific bug-type data and set up a separate queue to hold them.

Otherwise, of course, use the service desk tool but exclude those incidents from your operational reports.

Cheers,

UJ
_________________
Did I just say that out loud?

(Beige badge)
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


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

PostPosted: Wed Jun 25, 2008 10:56 pm    Post subject: Reply with quote

Hi Zoe,

I have been involved in a similar scenario in the past. I did use the Service Management tool to have the "issues" or "bugs" recorded and used a special classification for these issues so that we could report on them and access the calls quickly in the SM tool. it also allowed us to provide the Service Desk and PM etc. with a repository within the SM tool that they could use to identify id calls received were about the know bugs defects.

When the bugs were eventually fixed the service desk could also see what was fixed.

These did not go directly to either the service desk of PM to resolver. We set up a Defect team (made up of someone from the SD and PM and others) who would be responsible for managing these to a close or fix within the release managament programme.

It worked very well.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant
Back to top
View user's profile
zoe41
Itiler


Joined: Jun 23, 2008
Posts: 21

PostPosted: Thu Jun 26, 2008 12:59 am    Post subject: Reply with quote

Not coming from a development background I was trying to work out the best way to incorporate and manage bugs throughout the development lifecycle and any that 'spill' over into live. (not sure it matters that I am not a recent developer anyway?)

I believe that there are tools which do this function specifically whether they are incorporated into the service desk function I do not know.

The answer you have just given in terms of classification and reporting / and segmenting off these new release type incidents is what I was just explaining in a meeting so can understand totally what you are saying. I think that is the most symplistic.

Generally speaking are there ITIL based products which do more than this for a development type workflow?

I think the simple way to resolve this is to try and understand what our developers are seeking in terms of reporting and workflow and see if this is any different from general incident managment. I can't seem to find any logic to treat it differently in terms of process but just isolate the information when it comes to reporting.

Zoe
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


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

PostPosted: Thu Jun 26, 2008 1:03 am    Post subject: Reply with quote

Hi Zoe,

there is different logic in dealing with Incidents and what I will call "defects" and if you use the same Service Manageemnt tool for both you will need to have different proceses.

Incident records have ficus to return the user back to a working position asap. Defect fix (in your case) may take months to deal with, they need to have a validation step when they are logged to ascertain if the caller is reporting an incident or a known defect and then the handling of the defect process or incident proces kicks in.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant
Back to top
View user's profile
zoe41
Itiler


Joined: Jun 23, 2008
Posts: 21

PostPosted: Thu Jun 26, 2008 1:56 am    Post subject: Reply with quote

Mark so effectively the incidents are logged per normal, identified against the known error database. They have a different service response / ola because they are accepeted defects. THe workflow from this point onwards needs to be set up so that the impact on the operational enviroment can be monitored with regards to these 'accepted defects' the defects themselves as sent back to a 'developer support queue' to be managed and tracked accordingly. So it is all about classification, known errors and reporting.... nothing more special than the norm. thank you Zoe
Back to top
View user's profile
Timo
Senior Itiler


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

PostPosted: Sat Jun 28, 2008 8:14 am    Post subject: Reply with quote

Maybe a silly question or may have missed something in this long thread, but since the development bugs are in the live environment and affect live service(s) why would not they be processed as regular incident?
Back to top
View user's profile
zoe41
Itiler


Joined: Jun 23, 2008
Posts: 21

PostPosted: Mon Jun 30, 2008 6:13 pm    Post subject: Reply with quote

I think in the end we / I conluded that they would be. However they need to be classified as a separate type of incident with a particular OLA / SLA etc etc. The business has decided that they are not to resolved within the immediate(ish) timescales you would normally see for a general incident and therefore require to be managed in a different way. The resolustion could be in a future release some months down the line etc. etc.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk 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.