How do you manage a lot of projects in Jira?

[Steve Wright]

I am looking for advice and insight into how other people might be handling a large number of projects in Jira. Our organization has over 30 software projects. These represent various APIs, applications, and microservices each with their own release track and delivery. When we initially set this up we thought the best approach would be for each thing should have it's own project in Jira. This works well for the most part with respect to controlling releases and getting release notes. But there are certain use cases that come up that make it very time consuming to manage.

Is anyone else in this community tracking a large number of projects in Jira? Would you be willing to share your strategies with me?

[Rilwan Ahmed · Accepted solution]

Hi @Steve Wright ,

We have 3 instances of Jira and all has 200+ projects in it. 

In each Jira, we have categorized the projects and the schemes are shared between.
Project categories like Product support, Internal Support, Management project etc. 

We have template projects and any new projects are created only from templates. So that they have same schemes based on project category.

Example: If a project is for Product development, all other product development project uses same workflow, permission and other schemes. When they need any modification to a particular workflow, we ask them the business justification and has to go through senior management approvals. After that we create separate scheme for the project. This also reduces our effort to maintain different workflows and schemes. 

Permissions are mapped to roles and no individual users are added.
Roles are mapped to user groups with a naming convection like jira-ProjectKey-Team,  jira-ProjectKey-admin, jira-ProjectKey-developers etc, . All users and groups are from Active directory. So if anyone needs the access to a project, they should contact the helpdesk team. They will add them to groups in AD. 

[Tim Perrault · Accepted solution]

Hi @Steve Wright,

I have a couple of Jira instances I manage. I have one instance with two projects and after initial setup it pretty much comes down to user management. My other instance has over 150 projects. Most my work there is still user management. When setting up a new project we take our time and gather all the requirements. This allows us to get the project setup with minimum changes required afterwards.

The biggest help though is having my own project where it handles all the request for configuration changes and new project requests. We have built in approval workflows so that all configurations have been vetted and completed.

We also have a sample project setup that we let users look through and test. This is our baseline so that we can just clone/copy configurations instead of building something from scratch. All projects are different and not all will be able to use the sample, but if you can get a majority of projects to at least start at the baseline that's a lot of time saved.

There are so many ways of doing things that it really comes down to the human processes you build with your team. From there the technical aspects should be easy to reproduce fairly quickly.

Thanks,

Tim

P.S. can't wait to see other answers on this post because I bet there are some things that I haven't even thought of.

[Steve Wright]

Thank you for the response. What you are doing makes a lot of sense. How would you handle the following situation?

A ticket has to be cloned to 50 of your projects?

For me that means I have do 50 clones and 50 moves.

[Tim Perrault]

An automation rule would make sense in that situation. Have a job you could manually run that clones the issue to the projects you select or all.

[Steve Wright]

Ok cool, thank you. I will look into setting that up.