Why You Should Keep Your Jira Admin Group Small

We often work with clients that have granted JIRA Admin access to a large number of people. Sometimes many of these JIRA Admins are not actually tasked with making sure that JIRA stays running. Other times they are…but with “too many cooks stirring the pot,” they have a hard time doing so.

I recently ran into one of these situations in the field, and the end results were not pretty. The Jira Admin group was so large that the users didn’t have any idea who was in charge. When they needed to have a change made, they didn’t know who to go to. As it turned out, this was for good reason—there really was no one person or small group of people responsible for the overall health of their JIRA. With nobody available to take responsibility for the upgrade process, this meant that Jira hadn’t been upgraded. Now the stability of the system was in danger, and it was only a matter of time before the system crashed or otherwise stopped meeting the users’ needs.

How big should a Jira Admin group be?

The reality is, Jira was designed to have a centralized and limited administrative team, not a large, distributed group. What is the ideal size of a Jira Admin group? The answer is somewhat subjective, and depends on the size of your system.

If you only have 1,000 users, you’ll really just need two or three Admins. If you have 50,000 to 100,000 users, a group of eight to 10 Admins is probably about right. Installations of this size are typically for global companies, and require two to three Admins for each global area (such as North America, Europe and Asia) to ensure the ability to provide “follow the sun” support for all users.

Why should you keep your Jira Admin group small?

When organizations bring us in as consultants they often complain that even though they have “plenty” of Jira Admins to keep things running smoothly, their system is now in a state where nobody is happy with it. Our response often is that they don’t just have “plenty” of Jira Admins…they may have too many Jira Admins.

Here are some excellent reasons why you should keep your Jira Admin group small:

  1. Ensure everyone knows what’s going on – When a large group of people have Jira Admin privileges, it generally becomes impossible for them all to be aware of what the other Admins are doing, such as what projects each person is working on. This lack of awareness of other Admins’ projects can lead to situations where two Admins don’t realize they are both working on the same problem or project. It can also wreak havoc if one Admin makes a global change, such as to priorities or custom fields, without realizing that it will negatively impact other Admins’ projects. In fact, what often happens in organizations that have large Jira Admin groups is that someone makes a global change without getting everyone else’s buy-in, somebody else sees it and changes it back, and the change (and the problems it causes) ping pong back and forth.With a small JIra Admin group it’s easy for team members to stay in close communication and have weekly or bi-weekly meetings to ensure everyone is aware of what’s going on.
  2. Have clear responsibilities – With a large Jira Admin group it’s hard to know who has made what administrative change, or why they made it. If an Admin finds themselves in the situation described above where someone has made a global change that negatively impacts their project, it can be extremely difficult to figure out who made the change so that they can discuss the issue. This issue of not knowing who did what and why also tends to become a problem after a Jira Admin leaves the organization. Say Joe Blow had installed an add-on for whatever reason. Now he has left the company, and someone else begins to wonder why that add-on is there. An email goes out asking if anyone knows where the add-on came from and which groups might be using it. Because there are so many Jira Admins, that information may not have been disbursed to anyone else. So nobody knows if the add-on is being used or not.
  3. Make decisions easier to make and enforce – Anytime there’s a need for consensus, such as before making a global change, getting a small group of people to agree on what should be done will almost always be easier than getting a large group of people to agree on anything. With a large Jira Admin group the chances of running into philosophical differences regarding the best approach are quite a bit higher. For this reason, creating and enforcing rules and guidelines around the look and feel of the system is also easier with a small Jira Admin group.
  4. Make scheduling updates easier – Having a small JIRA Admin group overcomes the “nobody’s in charge” and “nobody knows what anyone else is working on” issues, which in turn makes scheduling updates a very doable process.

How can you make a large Jira Admin group smaller?

If your Jira Admin group has gotten too large, the best way to fix the problem is through the use of three different permission levels: System Administration, Jira Administration, and Project Administration.

By default, the Jira Administrators are also System Administrators. To make use of this permissions-based approach you change this and break these into two separate groups. Make the people who are most knowledgeable about the system the System Administrators, and give them permission to make any sort of system-level changes to Jira, i.e. things that could potentially break your Jira system. Typically there are just a few System Admins, and they’re in constant contact with one another regarding system-level changes that are taking place.

Next, give your Jira Admins slightly reduced permissions, letting them do most actions on the Jira application that do not have the potential for taking the system down.

Finally, figure out which people really only need the ability to make changes to their own projects, and change them from Jira Admins to Project Admins. An important thing to note here is that Atlassian recently introduced expanded Project Admin permissions. In the past only Jira Admins could make changes to a workflow, so everyone who needed to be able to do this requested Jira Admin permissions. With the Jira 7.3.0 release this is no longer necessary, as Project Admins can now edit their project workflows under certain conditions. 

Conclusion

Jira was not meant to be administered by a large group of people. If your Jira Admin group has grown too big, take steps—such as the permissions-based approach explained above—to shrink it down to size. And if you need help sorting out this or any other issue with your Atlassian tools, give us a call. As Atlassian Platinum Solution Partners, we have the expertise you need.