Move Tickets to a Long Term Project

[Jon Krasnichan]

Forgive me for the terminology. I am looking for a way to declutter a Service Management Project. Typically the workspace is used for ticket processing. We have a 3rd party vendor who works with us. When a ticket comes in and the request needs to transition from a standard work flow 2-3 business day resolution to a long term "project" it tends to linger in the queue.

We have thought up a couple options for keeping the queue manageable and not let these long term "projects." clutter up the queue.

• Create a new status called something like "Project." Assign these tickets to that status. Then create a filter/queue that removes that from the default Queue.
• Create a new JSM Project and move the tickets out of the initial JSM Project into the new "Long Term Project" JSM Project.
• Utilize the concept of a change order.

It is not uncommon for tickets to come in and contain a feature request or in working through resolving the issue it leads to a larger conversation or more in-depth work than what a normal 2-3 business day service window is able to accommodate.

Thank you for any help, guidance, or advice you are able to provide.

[Walter Buggenhout]

Hi @Jon Krasnichan and welcome to the Community!

From what you describe, it seems like you have the main elements of the situation well mapped out. It very much looks like you're dealing with a classic change management like challenge.

This does consist of a first step where work comes in as a request (JSM), that is taken in by the service team, categorised as something that needs to be approved (optionally) and then managed as planned work.

Flavours of a change management workflow may be variants of something like this:

I think you are doing the right thing in keeping the JSM ticket open (as it came in) and assign it to separate queues, so it remains traceable for both your team as for the customer who raised it initially. It remains your line of communication with the person who raised the request.

However, the planned work is usually managed in a traditional Jira project (not JSM), as it normally needs to end up in the backlog of the team that will be doing the work. To represent the link between the original request and the issue(s) representing the implementation work, the most common way of going about is by creating linked issue(s) to the original change request. While these won't be visible to the customer, they allow tracking the progress of the implementation from the change request.

Add automation rules to sync the status of the linked issue(s) to the original change request when e.g. the implementation starts and completes to reduce the amount of manual updates.

Hope this helps!