Thoughts/advice on when does a defect become an incident?

[frank1965]

We have implemented incident and project management modules and are just starting to use the defect management one.     We have made a global decision (not sure if is the best one, but a decision none-the-less) to not put incidents from projects that are still in a test/development mode.   Or to say it differently, we do not record incidents that occur as a result of a project that is still in development and testing.   Only production systems, post project completion get recorded.

So how do others do this?   Furthermore, I am looking to find out how to track incidents from post project implementations.

So if you have an incident associated with an application, do you record it as the application (like Cat1) then the name of the application or have some created a CAT1 items called project and then list all the IT projects underway within IT?

Hope this makes sense and please share how others may do this.

Thanks

[Uncle Rob]

Function of a piece of Software that's part of how I propel the business -> Incident.   But also defect.   That's the real problem.   Both are true.

[James_Neale]

Incident and Defect are similar, but in no way the same. A defect would never become an incident (to my knowledge). In my mind, there are more similarities with Problem and Defect than Incident and Defect in terms of management.

- Incidents: think of this as logging the effect. They are raised by customers to report issues with services. There is likely little detail beyond "This ain't working.". I'd agree that pre-production CIs should generally not warrant an incident (size of organisation may affect this), but why would general users be using pre-prod services without having contact with the owning group anyway (i.e. they shouldn't even be talking to the desk!)?

- Defects: think of this as logging the cause. They are raised by service desk agents, or developers, as part of either Incident or Problem management (depending on complexity and process), or even just, and more likely, ad hoc as defects are found in day to day development/maintenance. They are generally going to contain much more detail, but sometimes they might just be a reference to the incident and the dev has to work out what went wrong.

It is a real issue what to do with incidents that are caused by defects that can't be immediately fixed. You have no workaround nor resolution and I haven't seen any organisation come up with a good way of managing this. The way I've treated incidents like this in the past, assigned to my group, is to effectively pretend I'm a vendor and put the incident in Pending Vendor, which should pause the SLA thereby not affecting resolution stats. After all, I am providing a service, so I am technically a vendor, right?! It wouldn't be right to close the incident because the user still has an issue and you would also remove the inherent communication method along with proper tracking. You could also send it to Problem Management and then onto the Defect stack if you wanted to go the extra mile, but I would seriously question that as a process.

Frank Hathaway I would suggest you take the simplest approach that fits with your organisation right now. You can always improve, as you should. As for what other people have done, I think logging an incident against a CI/Service is about as far as it goes. Linking this out to projects becomes almost irrelevant because the project is delivering the service and not providing it. Get your feedback loops right from the start and define hand-off points and proper assignment groups and you should be fine.

Always question where the value lies and find alternative ways of gaining that value - there is usually at least 2 or 3 other ways. That way, you should keep your processes clean and manageable, instead of becoming garbled messes that provide everything but nothing.

Of course, all of this is subjective based on my experience, but I could be wrong.

[kellykaufmann]

My opinion, form a project manager perspective:

A 'Defect' will be found on the development env't for a project underway, and will be logged as a Project Defect.

Where it gets hairy is during the 'support' period just after go-live (e.g. 30 days support post go-live) where things are found in Production. Some teams have a 'war room' and a support team just for that, where end users do enter INC's or call into the War Room to have an INC created - we in fact created a tag (or something like that..I'm not an Admin, it was all done magically behind the scenes) to tag certain Incidents as a category related to a recent ERP go-live. So we were able to easily report against all those. Our next step is to be able to relate an Incident to a Project.

If your end users will just be calling a War Room and not entering Incidents and don't care that they can't track the progress of what they called in on, sure you could get away with using Project Defects during that support period. But you may instead want to find a way to use Incidents, tag them related to a go-live, and relate them to the project (somehow - ha!).