developement type incidents(?)

[zoe41]

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

[UrgentJensen]

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)

[UKVIKING]

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

[zoe41]

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

[mnsmith]

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

[UrgentJensen]

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)

[Mark-OLoughlin]

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

[zoe41]

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

[Mark-OLoughlin]

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

[zoe41]

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

[Timo]

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?

[zoe41]

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.