Handling projects and service requests (JSM for business teams)

[Arielle Unterberger]

How do you balance creating projects for teams (business and partly-technical teams) that are both working on projects and providing service to internal teams in the organization? 

I like the flexibility of JSM forms and different request types, which allow the teams to customize the intake process and info, without having to create additional custom fields. 

However, most of the teams that provide services internally, also have projects/initiatives that they're working on which is not recommended to track within a JSM project. 

Is it best practice for a team to have a JWM + JSM project? Do you have suggestions or any experience in dealing with this? 

I've been used to having both a Jira project to track my work effort related to projects, and also work on our "service queue" whenever there are requests related to anything that falls under an Atlassian admin's responsibility or any related questions they would ask. 

From talking with other teams, some think that it would be more difficult to manage their work since they are in two different places and that there could be a tendency that they would focus on one or the other. Visibility on work to be done is also not so easy. 

In addition, other teams are big and have specialized team members specializing in particular topics. They usually work on projects, but could be pulled into attending to "service requests" when needed, so to assign them in a JSM project, a license is needed.

I understand that they could be requested as participants, but since they're also the primary person assigned to that request, it doesn't seem enough.

When the users are not constantly working on the queue, this seems like a steep price to pay per agent. It could be that there are possible 10-20 agents that could work on service-related requests, depending on the topic.

Some teams are currently tracking this in a software/JWM project, but they request ~10 additional fields so that the people requesting something would provide the info they need, and I can't justify creating that much of custom fields for them. 

Any insights are highly appreciated! 

[Paul Wiggers]

Hello @Arielle Unterberger 

Thank you for your question. It is quite an interesting one and although I can't claim to be an expert, perhaps my view can be of assistance.

First of all, I don't believe JSM is meant to track your work. JSM is meant for requests of all kinds and those requests can result in other tasks.

For example; A customer requests the development of a new feature. This request will end up in JSM. The request is evaluated by some process that suits your business and ends up as a body of work for development. The product owner will create an issue in Jira Software, add it to a sprint, link it to the JSM issue, and assigns a developer to do the work. When the feature is done and available in production, the customer can be notified and the JSM issue can be closed.

This means that the developer should not require access to JSM and will save you a license. You can also design workflows and automations that can help you create issues in another project with the required information. Use automations to notify the service agents when a linked software issue is being updated so that the customer can be updated when needed. You might also just close the JSM issue when the Software issue is closed, but that is up to you to decide.

The concerns about having to check multiple sources are void in my opinion, especially if you consider JSM not to be a work scheduler. If a request requires you to do something, add it to Software/JWM/Trello and use that to keep track of your work. Schedule regular checks of JSM to keep up with the incoming requests and you should be fine.

You can use different tabs that open automatically when you open your browser if it turns out that having to open them manually results in not checking them regularly. 

But, as always, it all depends on your requirements and how you would like to work with different teams. Your situation might be totally different from mine and the above might not work for you if you have different requirements.

[Dave Liao]

@Arielle Unterberger 

Agree with Paul. 🙌 

🔎 Like he said, as part of your work cadence, schedule time to review incoming requests. Whether this request collection and review happens in JSM - or some other solution - is the technical solution.

🗓️ Any request that needs to be scheduled (due to resource availability, or a dependency, change management requirements, or sheer scope of work) should graduate from JSM to a JWM project. This “graduation” can be handled by something like Jira Automation. I suggest closing the original JSM request and having the requestor follow along in your JWM issue.

Hope this gives you some inspiration!