Is it better to create multiple JSM projects or a single project with multiple request types for ent

[AGASTYA SHARMA]

Hello everyone,

I'm designing a Jira Service Management instance for a growing organization with multiple departments (IT, HR, Finance, Facilities, etc.).

Some recommend creating a separate JSM project for each department, while others suggest using a single project with multiple request types, queues, and permission models.

For those who have managed large JSM environments:

What approach has been more scalable?

What challenges did you encounter later?

If you were starting again, would you make the same design decision?

I'd love to hear about real-world experiences and lessons learned.

[Robert Wen_Cprime_ · Accepted solution]

Hello @AGASTYA SHARMA 

The true answer is going to be "it depends".  You really need to figure out the trade-offs of having everyone in the project access to potentially all the work items (with Issue Security as a stopgap) or by separating out each department's work items by separating them out into individual projects.

[Arkadiusz Wroblewski · Accepted solution]

Hello @AGASTYA SHARMA 

That's kind of a question of process.

Did your department have similar work processes regulating how they working, or did they have a completely different process for how they working?

If they working similarly, centralizing makes sense. If they working differently, you are more or less forced to split and separate everything.

Best,

Arek 🤠 

[Kai Krause · Accepted solution]

Hi,

in my opion you drive better with for each department a project, because i think its simpler to manage permissions on a project level as on a work type level.  Also with changes in the structure i think its easier to migrate . 

BR
Kai  

[Carlos Garcia Navarro · Accepted solution]

Hi @AGASTYA SHARMA ,

I would start with as few JSM projects as possible, but no fewer than your governance requires. You can create a separate project when teams require different:

• Administrators
• Workflows
• SLAs
• Approval models
• Automation
• Reporting

If in doubt, I would start with bigger project,s since It's also easier to split a project later if a domain outgrows it than it is to merge independently configured projects after they've diverged.

[Rahul Singh _AtlasOptima_]

Hi Agastya,

The two questions at the end of your post — what broke later, and would you decide the same again — are the ones that actually settle this, so let me take those rather than the project-count question.

The reframe that has held up best for us is that service separation and project separation are not the same decision. What a service area needs is to be visible in the operating model. Whether that visibility is a project, a request type, a queue or a permission scheme is a downstream choice. Teams that start from "how many projects?" tend to reopen the question every time a new department arrives.

At AtlasOptima we separate a service area when three or more of these differ:

• Ownership — a different team is accountable for triage, fulfillment or escalation
• Workflow — approvals, CAB, security review or procurement review
• Visibility — employee, vendor, privacy, financial or compliance detail
• SLA logic — targets that change by service or business impact
• Reporting audience — separate dashboards or executive reporting
• Agent group — the people working the tickets differ from those who need visibility

One or two signals is usually a request type and a queue. Three or more is usually real separation.

What went wrong later, concretely. In one shared JSM environment AtlasOptima reviewed — roughly 8 internal service teams and more than 25 request types — the licence count had reached over 100 agents. After mapping ownership against actual usage, the practical active-agent need was closer to 30–35. Nothing was misconfigured. The structure had simply never made ownership explicit, so "give them a licence" was the path of least resistance every time. Those numbers are specific to that environment, but the pattern is not: unclear service ownership usually shows up on the licence bill before it shows up in the portal.

Would we design it the same way again? Yes to starting consolidated — Carlos's point that splitting later is easier than merging diverged projects matches what we see. No to deferring the ownership map. That artefact is what makes every later decision cheap.

[Alina Kurinna _SaaSJet_]

Hey @AGASTYA SHARMA 

I think it really depends on how different the departments are in terms of their processes and governance.

If IT, HR, Finance, and Facilities follow relatively similar workflows, a single JSM project can be easier to maintain. You can separate the work using request types, request type groups, and queues while keeping the overall configuration centralized.

I’d consider separate JSM projects when departments need significantly different workflows, permissions, administrators, approval processes, automation, reporting, or SLA configurations. This gives each team more independence and makes the boundaries between processes clearer.

There can also be a middle ground: keep teams with similar processes together and create separate projects only where the requirements are genuinely different.

One more thing to consider is how you plan to manage service targets. If you need not only customer-facing SLAs, but also internal OLAs between teams, you may want to look at SLA Time and Report for Jira. It extends SLA management in Jira with SLA/OLA tracking, configurable conditions and schedules, notifications, and reporting across teams and projects.

So I’d start with the processes first, rather than the number of projects: how different are the teams’ workflows, access requirements, and service commitments? The project structure usually becomes much clearer once those are defined.

Regards!