Should An Incident State Be Automatically Changed to In Progress When First Assigned

[johnfeist]

One of my key stakeholders is asking why the state of an incident should be changed just because the incident has been assigned.  While it isn't hard to stop that behavior, I have to believe that there are good reasons why the behavior exists rather than just leaving the state as New and having Assigned To set it to In Progress.  Aside from the obvious problem of people not always doing what they are supposed to, can anyone tell me:

• Why the behavior is set that way
• Have you changed it so that the assignees must fully manage state and if so how has that worked

We've been live for over a year, so I'm hesitant to make that type of change without some good research and understanding of the implications.  I don't expect to get a final answer.  I would appreciate getting opinions and hearing about your experiences in this area.

Thanks for any information.

John

[BigMikeyVegas]

We have a different question being posed because our system is configured to keep the incident state the same upon reassignment and we are discussing having the state revert to NEW when an assignment group change is made. 

Governance feels that if an assignment is changed and the state is On Hold or Work in Progress, that the team receiving the assignment will assume that. If the state reverts to New at reassignment, then they take responsibility for the state change on their end to meet the 'true state' based on how they are handling the incident. 

I think this would be an ask of your SN governance body, to see how the assignment groups feel about the proposed change and the current state. 

[SanjivMeher]

It is obvious that when incident is assigned to someone, incident is actually responded and some work is going on in the background.

It is helpful from an end users point of view, that they know that someone is working on their incident. Lot of times, analyst start working on the incident, but they forget to move the incident to work in progress. So from the end user's perspective, work has not started yet. So moving it automatically definitely end user experience.

We also use it for our response SLA. So when the ticket is moved to Work in Progress, that means ticket is responded.

I also cant think of a reason it will harm any process or work.

[ken_mooring_007]

I completely agree with this response as requiring assignment to an individual to progress from New to In Progress accounts for multiple process facets including the triggering for the Response SLA task, identification of progression of the incident to the next stage in the incident lifecycle, and to create accountability in the action of the handling of the incident record from an audit perspective.  We make the "Assigned To" field mandatory in order to facility the natural progress of the lifecycle with a control measure.

[RenBeau]

From the requestor's perspective, the incident being assigned does indicate a degree of work performed and progression towards resolution, but from the fulfiller's perspective, they have been assigned an incident which may not have had any actual attempt at investigation or resolution. 

Fulfillers end up with a list full of "work in progress" incidents, which isn't really giving the fulfiller information on what incidents in their queue they have actually reviewed or started work towards resolution, unless they dig into each incident. 

It seems like moving it to "work in progress" at assignment is ostensibly meant to inform the end user, while simultaneously obfuscating the nature of the meaning behind "work in progress".  Something like "assigned" would be a more honest description of its current state.  I wonder if this is purposeful because end users might become frustrated if they see an assigned task is not being immediately actioned?

This is also not consistent with the way other tasks are assigned, but left in the "open" state, even though they have received the same amount of work applied towards resolution.