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 · Accepted solution]

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..

[Esther Amunga]

• Do the teams need to work together? No, the other team does tablet, laptop and network support.  While the engineering/dev team usually have production fixes type of tickets/ change requests, new engagement requests.
• Are they even allowed to see each others tickets? Tickets from these 2 teams are completely different in nature.  So even if the other team views no one can interfere with the other teams ticket.
• Will it become an annoyance that the issue types are there when the other team doesn't need them?  Elaborate on this kindly...

In our case the operations team and engineering team do not have or use the same processes.

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.. ---I feel a new project works because of creating a project within one.

[Esther Amunga]

I would also like your response on the Jira OCS integration that I am also about to do.

[Dirk Ronsmans]

Hi @Esther Amunga ,

So we're basically talking about 2 teams with different responsibilities that will never work on the same thing.

You mention "So even if the other team views no one can interfere with the other teams ticket." So you'll have to block that on the issue level. Most likely with Issue Level security as there is no way to limit specific editing if you have general "edit" permissions. (or you need to add it to the workflow step properties.

Will it become an annoyance that the issue types are there when the other team doesn't need them?  Elaborate on this kindly...

Well if you create multiple issue types in a single project they are available for the whole project. So if someone from engineering creates a ticket they will also see the issue types from Operations. Without jumping through some horrible hoops there is no way to block the issue types from one team to another.

The way you are talking about your use case I see more issues with putting them on the same project than splitting up the projects.

They can of course stay on the same instance of Jira but in 2 different projects. This way the management will be for each project separate, different flows, issue types, queues, screens, portal?, ... 

Imho, adding that team to your existing project will only give you more headaches than advantages.

I'm not familiar with OCS or the plugin you mention but it seems like a straight forward "pull data from an external source" thing.. 

However as you are on Cloud, it might be worth waiting till Q2 2021 when Insight becomes more integrated (the Mindville/Atlassian Asset Management DB) which then might just be able to do a json/sql import.

[Esther Amunga]

Thank you @Dirk Ronsmans I fully hear you and you have clarified a lot on my concerns.  Thank you on the last bit on (the Mindville/Atlassian Asset Management DB), if I had not asked this question I would not have known about it.  I will be looking out for it.