Best practice methodology to setup JSM

[Jaime Gonzalez]

Hello, I would like to determine the best practice methodology to setup & configure JSM for my Org.

We are a Technology team that has 3 underlying areas:

• IT Operations
• Software Engineering
• ERP Services & Support

My question is; should I setup a JSM project for each of my "sub-areas" or should all services and support requests reside under one JSM project, and leverage custom workflows/screens to address specific forms depending on the issue type for each team?

Any feedback is much appreciated. We are working on leveraging Jira's features as much as possible to automate and reduce duplicate requests, integrate the KB in our overall company workflow.

Regards.

[Dirk Ronsmans · Accepted solution]

Hey @Jaime Gonzalez ,

That's one hell of a question :) Let's see if I can add my 2 cents.

My first thought here was how do you want to interact with your customers? Imho a single portal (meaning a single project) might be the most user friendly if the customers see this as a one stop shop for all their support questions.

Do they actually know that there are multiple teams behind it or would this be a more general entry point with different Request Types?

Secondly, do these teams ever need to work together? Will there be a SPOC for most questions (like IT Operations will triage and pass it to the correct team?)

The way I often look at it, if they use the same workflows/screens then I like to try and keep a single portal within the help center with some Request Types and the default ITIL practices.

However, if they are basically all different and they have different reporting needs/permissions/flows/screens/... then I would consider actually splitting them up. Even if they all use an Incident Management process for example, if they differ that much in flows (which I hope they wont as it is a best practice standard) then management might become so horrible for the project that you are easier of just splitting it up.

I get that I might not be giving you a clear answer as to how you need to set it up, but I'd love to discuss it more and see how your requirements fit in to what you can set up :) With that little information it's not always easy to analyze the full impact and needs for your organisation.

I'd start by drawing up the flows you need and defining which processes will be relevant. Going from there you can see what the similarities and differences are and go from there to see if you need to split them or if it makes more sense to keep them together.

Analyze twice, implement once :)

[Jaime Gonzalez]

Hi @Dirk Ronsmans. Thank you for replying.

The way we currently interact is, each of the 3 teams, directly gets assigned the flow of requests relative to them, as each team has an individual JSD project (these projects were created when it was still Jira Service Desk) I attached a screenshot of our current Customer Portal setup. 

So the triage or SPOC part is not in the equation, we intend to keep it that way, as we are a small team. The teams do work together, we are improving our workflow now by adding issue links, KB references, etc, between software projects, JSM projects, confluence.

So what I wanted to do is remove the 3 old JSD projects and create a single JSM ITSM project to handle all support, incident, change requests. Trying to streamline the massive flow of requests coming in daily, both for users and support agents. And besides all, managing it all in one project.

Upon reading your response, I looked at it again and played with the request types a bit more. I sadly (because it was something so simple) found out that I can manage different views, for instance change requests, meaning I can have 5 different change forms using the same workflow, which is exactly what I need, and I don't have to custom anything.

Please excuse the long post for something so trivial; however, your perspective helped me figure this out. Thank you very much!

[Dirk Ronsmans]

Great!

Thats exactly what request types are for. Creating a specific form for a request type which will then be linked to an issue type. Having a many to one relationship like that helps keep down the number of issue types and avoid duplication to have a different form. 

with Atlassian’s acquisition of ThinkTilt(ProForma) this should only become even nicer!

[Jaime Gonzalez]

Awesome!

Thank you for clarifying, hopefully this post will clear the way for some.

Just started using ProForma, its really cool