Pros and Cons for having 2 teams in the same service project

Esther Amunga

Hello Team,

I need assistance here.

Based on my past question asked here, it is possible to add 2 teams in the same service project.

The other team/teams can create their own issue types which can have their own screens, workflows, and SLA's while remaining in the existing project.  That way all of the tickets would together in one place.

However, I would like to make an informed decision based on the following:

The existing dev team in the project would not like their configurations changed or messed up with. They have been using the configurations and it works well for them.  I will be using (https://marketplace.atlassian.com/apps/1219994/external-data-for-jira-fields?hosting=cloud&tab=pricing) to link assets to Jira from an inventory system called OCS which will carry more than 20k tablets and laptops.

As a new Jira admin, I would like to maintain sanity of the existing configurations as well as bring the new team into jira in a simpler manner.

I would like the pros and cons of remaining in the same project and creating another so that I can advise my manager accordingly.

Dirk Ronsmans

Hi @Esther Amunga ,

The only pro I can see here is that all the tickets would be in one project.

Other than that I'm feeling you might be kicking a hornets nest here.. The Dev's don't want anyone messing with their configuration but you are adding new issue types/workflows in to their project.

While this is perfectly possible to split up everything (except your will have shared queues unless you buy an app for that to limit visibility) configuration wise you'll also need to consider notifications/automations/...

Sure, as an admin you can make sure you keep everything named properly and document it all so no mistakes happen but it's still a tricky setup.

My first question would be what is the need to keep everything in one place.

• Do the teams need to work together?
• Are they even allowed to see each others tickets?
• Will it become an annoyance that the issue types are there when the other team doesn't need them?

I would really like to understand your use case here. Very often there is a good reason to keep things together if they use the same processes (incident, service request, change, .) and since Jira doesn't show fields that are empty it's often fine to have a single set of screens.

However, if you start adding issue types, screens, workflows,... you're almost creating a project within a project and then I'm wondering why not just split them up and give access to the users where needed..