How can you create a jira project for a change request in a jira service management

Question

Hello,

I have a question regarding the jira service management. We got a change request, but actually this change is a full project. I would like to create a jira project, but within the service management. Is there one way I could link these? Same as you can create tasks within the service management project.

I hope that this is feasible.

Walter Buggenhout · Answer

Hi @Lotte Vaesen and welcome to the Community!

Adding to what @Mark Segall suggests, if a change request actually leads to a full blown project for implementation, you would normally roll into the project management practices that you have in place at your company:

* The project will need to be defined;
* Most likely it will need to be approved by some level of management;
* Once it is approved, it will be planned, tracked and reported on as an actual project, not as a request.

As request and project management are totally different things, it is not a bad idea to just close the change request, registering the decision that this thing will be implemented as a project and that this is no longer a change. There's nothing wrong with even mentioning the expected timeline or waiting to close the CR until you know the project was or was not approved.

How you may further track the relationship and/or progress of the project in relation to the CR mainly depends on your Project (Portfolio) Management practice. It is not uncommon - if you are on a Premium plan - to define projects as issues in Jira. In that case you can indeed track project progress like you would do with any type of linked issue, but it would lead to a CR issue being open for a very, very long time potentially.

Hope this helps!

Mark Segall · Answer

Hi @Lotte Vaesen and welcome to the community!

You have a couple ways to handle this, but first it's important to understand that ITSM is generally designed for first-in/first-out behaviors with heavy focus on SLA.  So, let's look at the options:

1. Separate Project

If its more the exception than the norm to have projects initiated from your JSM requests, I recommend going this route.

If you wish to keep your SLAs pure, the best approach is to actually create a Jira project and link your originating issue to corresponding stories/tasks in that other project. You can even set up automation to provide updates to the originating request to keep the requestor in the loop on transactional updates (e.g. linked stor(y/ies) added to sprint, sprint started, sprint complete, etc.

I imagine you don't want this one mammoth request to skew all of your SLA stats. So, if you don't already have one, establish a status and/or component that pauses the SLA timer.

2. Separate Queue

If these types of occurrences happen frequently enough, you may need to just find a way to manage within your existing JSM project.  Here are some steps I would take:

* In my past, I've leveraged sub-tasks to capture all of the activity related to the original request and create a queue specifically for managing those sub-tasks* parent = Original Request Key

* As with above, make sure your SLAs are adjusted accordingly.  For example, you have a longer SLA for projects and want to track those with special SLA rules.  You could use a separate request type, component, etc. to indicate this is a project and adjust SLA.
* Also, similar to option 1,, you can use automation to ease the burden of transactional communications as sub-tasks are worked on/resolved

There are other ways to go, but these are my go to approaches.