How have you structured your JSM Environment for ITIL Processes?

[Kim Galway]

Hi Community,

We're in the process of refining our Jira Service Management (JSM) setup to better align with ITIL processes, and we understand this is a major decision that impacts scalability, maintainability and team workflow.

We'd really appreciate hearing how others have approached this.

Specifically:

• Did you build everything (Incident, Problem, Change, Request, etc.) within a single JSM project, or did you create separate projects for each discipline?
• What were the Pros and Cons of the approach you chose?
• What factors influenced your decision (SLA's, reporting, team ownership, automation, etc.)?

We know there's no one-size-fits-all solution, and we'd be grateful for any feedback, lessons learned, or gotchas to watch out for

Thanks in advance for your time and insights!

Kim

[Julia Watson-Clarke · Accepted solution]

Hi @Kim Galway ,

We have built everything within a single JSM project which we call out 'ITSM Strategy'.

We currently use JSM to handle internal requests that are escalated to our Technical team.

This could be a incident request such as a potential bug raised by a client to Support and then escalated to Technical. Or it could be a change request asking for new functionality. We use it to cover the BAU tasks carried out by a section of our development team and a section of our Sys-Admin team.

We have documentation in Confluence detailing the processes from a requester and an agent perspective.

Using JSM this way has been transformative for how we operate. We use ITIL best practice and the tools available in JSM to effectively categorise and prioritise work directed at our team.

It has been a really positive journey for us, but not without it's bumps in the road.

Pros:

• Improved information about the issue being raised (Forms, custom fields, request categories)
• Improved service delivery (internal SLAs help us to review our performance)
• Ticket analysis is presented in a quarterly Balanced Scorecard and allows us to see resource and capacity trends. This enables us to set lead times.
• Automation has helped us to speed up triage and response rates as well as inform agents of any caveats such as 'client has x script running' which allows us to process change requests without impacting current functionality.
• Better cross-team communication.
• Less team burnout.

Cons:

• Some rogue team members not following documented processes - unwillingness to adopt change.
• Initially a big cultural shift to how we previously worked meaning response times were slow whilst we adjusted. This was very temporary and we are now seeing the benefits.

What factors influenced your decision?

The main driver for using JSM and setting it up this way was to start managing client and internal expectations better. Rapid growth of the business meant we had to be smarter about the way we handled requests coming in to the department.

Hope this helps.

Julia.

[Kim Galway]

Hi Julia,

Thanks so much for sharing such a comprehensive look into how your team has set up and evolved your JSM environment. Your approach and the benefits you’re seeing are very encouraging.  I’d love to dive a little deeper into a few aspects if you don’t mind:

1. You mentioned that JSM was a big cultural shift — what specific steps did you take to help teams adjust to the change? Did you do phased rollouts, trainings, champions, or anything else that really helped adoption?
2. How do you manage access and visibility between the Sys-Admin and Development sections within a single project? Are you using issue security levels or something else to manage what each team sees and works on?
3. Your use of the Balanced Scorecard is really interesting — could you share a bit more about how you designed that and what kind of metrics you include? How do you tie it back to performance and lead time setting?
4. What Confluence documentation was most valuable during the rollout? (e.g., process flows, request forms, team responsibilities, etc.) Would love to know which pieces had the most impact in guiding agents and requesters.
5. You mentioned some resistance from a few team members — how did you handle that reluctance, and did anything in particular help get them on board over time?
6. Lastly, now that you’ve been using this setup for a while — is there anything you would have done differently at the start, knowing what you know now?

Thanks again, Julia, your input is extremely helpful as we shape our own environment.

Kim

[Julia Watson-Clarke]

Hi @Kim Galway 

No problem at all, please see answers below:

1. You mentioned that JSM was a big cultural shift — what specific steps did you take to help teams adjust to the change? Did you do phased rollouts, trainings, champions, or anything else that really helped adoption?

Training was delivered to team managers so thy could champion the new processes / ways of working. They were in charge of ensuring adoption was successful within their teams.

We then delivered training to the team members, providing documentation and videos. Recordings were taken and made available to those absent from the training sessions.

Following launch, we did a week of drop-in sessions to mop up any queries.

1 month after launch, we held and Q&A session to gather ideas for what did / didn't work. This later became our roadmap for continuously improving how we deliver our ITSM Strategy.

---

2.How do you manage access and visibility between the Sys-Admin and Development sections within a single project? Are you using issue security levels or something else to manage what each team sees and works on?

Our developers, QA and Sys-Admins all form our overall Technical team so they all have access to the single JSM project.

---

3.Your use of the Balanced Scorecard is really interesting — could you share a bit more about how you designed that and what kind of metrics you include? How do you tie it back to performance and lead time setting?

We use the data collated from custom fields such as Source of request to identify which internal teams are requesting the highest volume of tickets and we then review whether any internal upskilling / knowledgebase articles could be created to help deflect the number of requests we receive.

We look at overall utilisation to see which request types (e.g. change requests) are the highest requested and the average time it takes to close the different request types to work out what we should then communicate our lead times as. For example, if the average time to close a change request is 14 days then we communicate leads time for changes are 2 weeks. This can then help set expectations and avoid unnecessary escalations to expedite a request.

---

4.What Confluence documentation was most valuable during the rollout? (e.g., process flows, request forms, team responsibilities, etc.) Would love to know which pieces had the most impact in guiding agents and requesters.

Process flows with examples of when to use them helped the Technical team get used to the new workflow statuses. Team responsibilities were included too.

We created process documentation for:

• Change Management
• Service Request Management
• Incident Management (including escalation paths)
• Problem Management
• A Customer Portal User Guide

---

5. You mentioned some resistance from a few team members — how did you handle that reluctance, and did anything in particular help get them on board over time?

As we had trained team managers to be ITSM champions, we went back to them to reiterate why ITSM had been introduced and highlighted the benefits it had for the business as a whole. We ended up producing further documentation as 'Quick Guides' to help those team members who didn't have time to read through all the documentation, allowing them to review the key takeaways that impacted them as individuals.

---

6. Lastly, now that you’ve been using this setup for a while — is there anything you would have done differently at the start, knowing what you know now?

In hindsight, seeking input from team members about what to include on our forms would have been a helpful exercise. We initially built the forms keeping in mind the data we needed to capture to best triage requests. However, the forms have since evolved with new / different fields which is a direct result of feedback from those using the forms.

Hope this information is helpful,

Julia.

[Josh · Accepted solution]

@Kim Galway you are wise for reaching out for thoughts on these consequential decisions. I am curious to see what other responses you receive.

I'm curious about your thought to potentially split your JSM projects by work type (Incidents, Problems, Changes, etc). Since JSM can handle multiple work types within a project, I haven't been able to envision a situation where it'd be helpful to split things up along those lines (but could surely be missing something).

In general, I prefer a consolidated approach to portals for teams that have similar functions (e.g. an IT department). There are plenty of tools available to virtually partition the work that different teams have within the project (e.g. work item security schemes, associating work items to teams, and so on). One of the big benefits there is that it's a lot easier to reassign work to different teams rather than having to "move" work items to different projects.

One of the big downsides to a consolidated approach is that it requires more organizational alignment on how the project is configured and evolves over time. It's usually easier for Jira admins to just create new projects / schemes etc. to avoid that hard process and "political" work, but I'd argue that the outcomes are better (especially when it comes to reporting) when teams are aligned.

[Kim Galway]

Hi Josh,

Thanks so much for your detailed response — I really appreciate your insight. You bring up a lot of great points, especially around virtual partitioning and the long-term benefits of a consolidated setup.

I’d love to better understand your experience and reasoning a bit more:

1. When you've used a consolidated approach, how did you handle reporting and dashboards across different ITIL practices? For example, were you able to easily isolate metrics for Problem vs Incident vs Change?
2. You mentioned it’s easier to reassign work within a single project. Can you share a scenario where this was especially beneficial, such as shifting ownership between support tiers or across functions?
3. You also noted that a downside is the need for stronger organizational alignment. What kind of challenges did you encounter in getting that alignment? Any tips on how you navigated those “political” aspects?
4. For teams considering splitting by work type, is there a specific scenario where you might recommend separate projects (e.g., regulatory reasons, business unit silos, or tool limitations)?
5. Finally, when it comes to user permissions and customer-facing portals, how have you balanced visibility with control in a single-project setup?

Really appreciate your thoughtful take on this — I’m trying to balance long-term maintainability with clarity for the teams involved.

Thanks again!
—Kim

[Josh]

Hi @Kim Galway

1. When you've used a consolidated approach, how did you handle reporting and dashboards across different ITIL practices? For example, were you able to easily isolate metrics for Problem vs Incident vs Change?
   1. This is one of the easier parts. JSM has "work types" (formerly "issue types") and "request types" that can be used for searching and visualizing data. For example:
      1. As you build out your request types in the project (e.g. "Account Issue), you map them to the appropriate work type (e.g. "Incident").
      2. You can then use "issuetype = Incident" to show all incident tickets.
2. You mentioned it’s easier to reassign work within a single project. Can you share a scenario where this was especially beneficial, such as shifting ownership between support tiers or across functions?
   1. We use this for a variety of scenarios including across functions. For example, when the ticket starts off as a request for Team A (e.g. an Infrastructure team) but turns out to be for Team B (e.g. an Application team) or vice versa. You just update the team associated to the ticket and it's now in the right place without having to go through multiple dialogs for the "move" process.
   2. We use a separate field to denote support tier. This allows easy filtering across all tiers or segmenting to specific tiers.
3. You also noted that a downside is the need for stronger organizational alignment. What kind of challenges did you encounter in getting that alignment? Any tips on how you navigated those “political” aspects?
   1. Agreeing on workflows, fields, screen layouts, etc.
   2. Get solid representation across all teams involved early and often. Give the concept of "design thinking" a try if you're not familiar with it; we used it to help facilitate design workshops.
4. For teams considering splitting by work type, is there a specific scenario where you might recommend separate projects (e.g., regulatory reasons, business unit silos, or tool limitations)?
   1. Regulatory / security reasons would be a big one if issue security schemes weren't sufficient.
   2. If you anticipate a huge volume of tickets (e.g. 500,000+ a year) then it'd make sense to make sense to split things up.
   3. If teams report to different senior level executives and you're not sure alignment will be practical.
   4. If the customer base is dramatically different and/or the services are vastly different.
5. Finally, when it comes to user permissions and customer-facing portals, how have you balanced visibility with control in a single-project setup?
   1. Still making strides towards this. All project members have access to unsecured tickets.
   2. All customers have access to their requests and anything that has been shared with them.
   3. In terms of broader sharing (e.g. everyone in Sales or Marketing) we've been looking at "organizations" a bit more but it can be challenging at scale.