Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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.

1 answer

1 accepted

3 votes
Answer accepted
Dirk Ronsmans Community Leader Feb 28, 2021

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

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

Like Stuart C likes this

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

Dirk Ronsmans Community Leader Mar 01, 2021

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.

Like # people like this

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.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Published in Jira Service Management

Announcing Mindville Insight is now part of Jira Service Management!

Hello Community! We’re excited to announce that Mindville Insight’s asset and configuration management capabilities will now be integrated into Jira Service Management Premium and Enterprise plan...

693 views 10 15
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you