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

[AGASTYA ANOOP 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 ANOOP 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 ANOOP 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]

Hi @AGASTYA ANOOP 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.