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]

So there's a couple questions in there.

What systems can have stuff logged against them?   Prod?   Subprod?

A user calls up and says "WTF man!? I can't do XYZ anymore in test!".   Some random IT manager says "Who cares?   Its test".   Well, the customer cares, because maybe their job is testing code.   All systems are somebody's production system.   The business impact of a unit tester's access to Test system may be lower than a company wide email outage, but its still "production" to someone.   Business Impact > Prod/Subprod Classification

Defect vs Incident

Great question, since there's a TON of overlap in how these tables can be used.   ITIL tells us an Incident is an interruption / degradation of a Service.   What does ITIL tell us a defect is?   *cricket chirping*

Defect has been added to the system via SDLC.   Its the point at which a developer says "this thing you're talking about is actually a chunk of our code that doesn't work the way we want it to".   Bad news?   HUGE overlap with Incident since that chunk of code could be the technology component of a Service.   Defect introduced = Service degredation = Incident.

Now our world is difficult because we have two different Task flavors that can represent the same work.

Oh!   And they are under different license models.      

Which also stack!  

Can life get any worse?     YEP!   Because I'll bet you $5 your ServiceDesk uses Incident as the entrypoint for anything, regardless of what task type is ultimately the most relevant.   You could build something similar to Fruition's "Lift Intake" to empower ServiceDesk to create more accurate task types, but that might mean another stacked license

I love this thread, Frank.   Its something I've wrestled with for a long time.

[BryanS413339635]

This is a good explaination. I would summarize as an incident is when it affects the end user (something broken and they call the service desk). The support group or development team would investigate the incident and if appropriate open a Defect in SDLC (citing the incident). The question for us continues to be do we close the incident and track via the defect or leave the customer facing incident open. For customer service purposes I say leave the incident open until the defect is resolved, but upper management like those aging incidents off of their reports .

[Uncle Rob]

I think defects (and for that matter, stories) should also be customer visible.   They deserve to know when the 'stuff' affecting them is scheduled to be worked on (sprint) and released.

[Deepak Ingale1]

Interruption to service is an incident.

Network down...incident.

Cant not access folder which previous was able to...incident