Best Practice: "Converting" an incident to a Demand, Story, etc...

[Brian Bouchard]

Wondering what is considered best practice for handling "tickets" in general when they come in through an incident, but need to be "converted" to something else, like a Demand, story, or a simple change.  For example, a user opens up an incident indicating some functionality is missing. We agree it is an incident, but the fix is "bigger than a bread box" so we open a Demand (could be a Story or maybe a change) for planning and tracking the amount of this size effort.  I'm not resolving the incident until the resulting Demand is complete and implemented through a Change Request.  Currently, I'm putting the Incident in a state of "Awaiting Resolution" and linking the incident as a parent of the Demand for tracking purposes.  However, there is an effort to measure how well we're addressing incidents based on how long they have been open, so if it takes 2 months to prioritize and implement a fix for the incident, my incident is in the "2 months since it's been opened" list.

This doesn't really bother me, since I can filter on the "Awaiting Resolution" State, but I'm curious if there is a best practice around this level of service management...

1. Is it better to leave the incident open until the issue is ultimately resolved and filter out based on something like the state of "Awaiting Resolution" to remove things that you know are waiting to be prioritized and implemented?
2. Is there a preferred way (or state?) to resolve an incident once the other task has been created that indicates the incident still isn't fully resolved, but will be handled through this other process/task type?
3. Should there be an "Unresolved - moved to Demand" type state, that could then be automatically updated to Resolved when the child Demand is completed?
4. Is there some other preferred option I haven't thought of?

[Mike Allen]

I have always viewed an incident in the myopic 'it was working and now it is not' view.  Anything else that comes through incident that isn't, in my opinion, gets cancelled when an appropriate ticket type is opened.  Also, I am in love with the new_call module (though not in love with the fact that it doesn't extend task).  This module allows users to open a generic ticket and have someone assess what type of ticket it is and transfer it to that ticket type.  This takes out people opening requests as incidents, etc, and helps keep the tables clean.

Of course, this is just my two cents.

[Brian Bouchard]

I agree with your view of an incident, Mike (and your thoughts on the Call module, which I'm excited to get our team to.)  My question is less about is it an incident vs. a request, but more about tracking incidents that don't have an easy resolution. 

Maybe not a great example, but as a for instance...  Let's say we have a process that is working today, but is running some sort of deprecated code.  We do an upgrade and for whatever reason, we missed the fact that the upgrade has broken the existing process because that deprecated code is now dysfunctional.  An incident gets opened, we acknowledge it is a break/fix situation, but the fix is going to take a great deal of analysis and work to implement.  The challenge for us now is I am creating a Demand to track the work of analysis, coding a change, testing, etc... We have a business rule, for instance, that says if it is going to be more than 8 hours of work, it needs to be put into a Demand/prioritized against other Demands, etc.  the fact that it's parent is an incident helps elevate the prioritization, but we still have 2 tickets basically tracking the same issue.

In that instance, would you just have an incident and leave it open until it's resolved & have something in your measurements to indicate why the incident is taking so long to resolve?  Or would you close the incident with some understanding that the incident itself is still an issue, but that it's being worked on in the context of some other ticket type (in our case a demand)

[Mike Allen]

Ok, I see the issue.  I think, in reality, you just eat the time.  Categorize them in a way that you can remove them easily when metrics are pulled, but an incident is an incident, and if it is still ongoing, then it is still open.  Moving it to problem doesn't make sense, unless multiple people are reporting it and a known error is needed.  Even then, the incident should remain as awaiting problem.  I think that the resolution time is the resolution time and there is little you can do that you aren't already doing.

[Brian Bouchard]

That's where I was starting to lean, Mike. I'm thinking if we have incidents that are taking that long to address and/or we're that backed up that we can't resolve them more quickly, the measure of incidents that have been open "too long" is accurate in this case, and it should raise a flag with folks that something needs to change.  By trying to manage around that measurement, we're really just masking an issue of either being understaffed, overworked, unskilled, etc...