When is a new Jira project needed?

[John Bradley]

Hello everyone, this question might have varying answers but I'm trying to get a feel for when a new Jira project needs to be created.  Just to give some background, we are an IT department of approx 20 people that cover application development, third part application licenses, security, infrastructure, etc. Here are some of my scenarios that I wrestle with as an application development manager attempting to manage Jira as an admin:

• I am responsible for two applications developed in house, and about seven from third-party vendors.  I have one application developer, and I both manage and develop. The two in-house applications have been in production since 2021 and have had several updates to them over the years.
• The manager of security may need to find a new backup system
• The client services manager may have been assigned to purchase and distribute new laptops with Windows 11 on them.
  
  

For my personal scenario, I have a Jira Project named ITS Development.  In it I will create an epic for a quarterly application deployment release, a new vendor app setup and production deployment, etc.  I have a custom field called ITS Application which I use to distinguish each epic and the other work items related to it.

For the other two, each manager has a Jira Project and would also create an epic for the assigned project.

Are this how smaller teams normally would work, or would there be a Jira Project for each the applications I manage, on another manager in the given use cases would? Is there a point where a work project should have its own designated Jira project?

[Robert DaSilva]

Hey @John Bradley , that's a great question!

Regarding the examples you provided, here's how I would determine if a new project is needed:

1. Generally, I find it best to have one project per distinct application. Releases can be captured via the "Fix Versions" / "Releases" feature in Jira. This allows for an ongoing look at how the software you're developing is progressing, the historical work that's been done, and identifying future development opportunities by scouring the backlog.
2. Finding a new tool may warrant a Jira Project. In this case, I would look at the level of effort expected for this task. If this is a simple effort, it might make sense to use the concept of Epic and Tasks instead, and keep that within a "Procurement" or "IT Infrastructure" project. If the level of effort will be months long, and have many people contributing to the search and eventual transition, a new project can keep that work separated and distinct from the rest of the team.
3. This sounds like this task may fall under general every-day tasks for this individual. Here, I would likely recommend keeping this within an existing project for this individual. If this task will take months, and have 10s or 100s of individual tasks that need to complete, that's where I would recommend a dedicated project.

Your insight and instinct are pretty similar to mine. It sounds like you're part of a small team, so keeping things in singular projects works for the time being. My concern comes from scale, and a potential increase in the number of users who need to assist.

Generally, the litmus test I use is "How distinct is this work from other work". For the application development, to me that's a clear line between development for one application vs another, and warrants a Jira project each.

For everyday tasks of an individual, that's where the line gets much more fuzzy. I would say you can't really go _wrong_ with Jira, and if separation of work into unique projects works for your team, then that's a good idea. 

I would recommend keeping the goal and type of work within a singular project well defined, so it's clear to new and existing users where they can expect to find work.

Hope that helps!

Robert