Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How to administer a lot of projects in Jira


We are working in some companies managing a lot of projects.
With Profields we have managed to have all the important information about our projects in Jira and searchable. But too much information can make you lose focus so we were wondering which were the three most important fields to have in a Gadget to have a good overview of all your projects.
Right now we are working with:

  • Last Activity (BH) which represent the last time there was any activity in a project
  • Open Issues, to check the issues we are working right now and
  • Issue Count so we now which projects are the ones with more activity


** All fields are script field type


Would you change any of the fields? When you are managing a lot of projects which things do you need to be aware of everyday?


I have followed a different approach, keeping one single JIRA project (i.e a portfolio) and having an issue structure where one of the issues represents a project. Then I use calculated fields to have all sort of statistics per project and also a portfolio view using a filter gadget.

Hi @Leo Diaz _DEISER_,

One of the problems I have found is when the instance have several Jira projects, how can managers or project manager track all their projects. Maybe Profields can help to track their projects. The easiest solution is using something similar to BigGantt or Tempo.

Besides, @Adolfo Casari your solution sounds interesting. So you create one Jira project and, each issue is a project itself and you track your projects with Portfolio for Jira? Can you attach any snapshot in order to have a clear idea?

Hi @Francesc Arbó,

Yes, one (or a few) JIRA projects that have a issue scheme where one of the issues represents a project. Here's an article that describes the approach:

Thank you @Adolfo Casari. It seems an interesting aproach.

I'll try a PoC just to understand better this solution and find it's strengths and weaknesses.

Just another question, all these date custom fields are set automatically or manually? Do you use them in reports or in a Gantt?

The date fields are planned start/end dates for every Phase and are set by the owner of the project (or whoever holds responsability). One of the things the scheme does is that you can't set a duedate on a subtask if it's later than the planned end date of the Phase it belongs.

The real start/end dates are set automatically when the first subtask moves to In Progress and when the Phase is closed by the project owner, respectively.

Using JWT and Jira Automation, you can do all sorts of metrics to show in a dashboard.

@Adolfo Casari interesting approach.  I too have taken the 1 JIRA-project to many actual projects approach and I do see some advantages.  The trouble I'm having is creating buy-in for key individuals leading development on those projects; using the JIRA-project's board to show progress, etc.

Many of these folks are very comfortable using a checklist in a spreadsheet to understand what they need to do next, and tracking on what they've done.  With that, many of the tasks within these projects are standard, and repeat from project to project.

I'm curious to know if you have run into some the challenges I'm seeing and if you have suggested approaches.  I'll also check out your blog.  Thanks!

Hi @Jason Warfe,

Key to using one JIRA project to hold many initiatives is to implement an (automated) issue hierarchy: this is what PMbok calls a WBS. By automated I mean that this hierarchy is created automatically by the workflow once you create an initiative.

In that regard I was able to configure hierarchies for handling Incidents and Projects that follows a phased approach (i.e. first analisys, then design, construction, etc.). For incidents I used a parent issue and a fixed number of subtasks and for projects a fixed number of phases linked to a main issue (i.e.the project) and subtasks under the phases.

In particular with the project hierachy I was able to configure custom fields that represents metrics for each initiative that can visualized in a filter gadget. For configuring these custom fields I used Jira Workflow Toolbox + Jira Script Runner. Here is a sample, each row is a project:


Thank you @Adolfo Casari !  I'll give this some thought.  Much appreciated, Jason

I have worked in a large organization where each Project had it's own JIRA Project. It just made sense from all angles:

- different issue ID to help differentiate

- clean boards without having to use labels or components to differentiate

- clean reports for each project

- less human error (ie. create a story and forget to label it for a particular project)

- flexibility on issue type schemes (some projects were simple and only needed Task, Bug, Request while others Needed Epic, Story, Task, Bug, etc)


The way we were successful is that we standardized a few JIRA artifacts: screens, workflows, statuses, etc across the organization. Note we did allow for a little flexibility based on justification.


I cannot imagine using one JIRA project for the entire organization!


Thanks for your feedback!! but in this case I was talking as a JIra Administrator or Project Administrator not as Project Manager...  Probably it would be a better a name "how to administer a lot of projects" for this discussion! ^_^


@Leo Diaz _DEISER_- We manage Jira systems with Hundreds of projects for various customers. Your question if I understand it correctly is "As a Jira Administrator how do I keep my Jira system clean so that only the truly active projects remain available and visible in the system?"

Here is what we do as a minimum for any customer:

- Establish an Archive and Read-Only Permission Scheme

- Establish an Archive and Read-Only Project Category

- Run automated queries that look at fields very similar to what you have Last Activity, and Issue Count. We personally don't focus on Open status because it can be very misleading. I have seen projects have Open Issues for years just because it was an abandoned project which is why we look at Last Activity.

- You can also automate some emails from these Queries that you send to Project Leads and Project Administrators. The Subject line of the email says something like "Your project has been Inactive for more than XX Days - It will be Archived within the next 30 days if we see that there is no activity on the project". This usually wakes people up to either claim the project or it goes archived. The archived permission scheme will allow you to do On-Line Archiving and someone comes back to you after you have archived it, no big deal, just reset the permissions on the project.

Then you can use the Permission schemes and Project Categories to manage the projects and keep it as organized as possible.

We have found this kind of process really helps.

This is what we do at the minimum and then you can always go one step further by implementing another check through a JIRA request process. Basically when you get requests from someone to make a change/addition in Jira you reconcile any project they are a part of.

Hope this helps! Good Luck!


Hi @Maurizio!

Thanks for your feedback!, It's not a question, it's just a discussion! ^_^, I like your feedback about run automated queries, it's a fantastic practice!!



Log in or Sign up to comment

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