Claudio Ombrella's 5 crucial tips for first-time Jira admins

February 6, 2018

One could say that Claudio Ombrella is a fixture in the world of Jira admins. Ombrella and his team at Autodesk have completed one of the greatest consolidations of Jira: they migrated Bugzilla, TFS, Rally, Lotus Notes, and Trello instances to Jira. His accolades don't stop there: Claudio has been Atlassian customer for more than 10 years, starting with a small system and 9 projects that are now being used by 8,000 people at Autodesk. He's been invited to present at 3 Atlassian Summits*. He currently helps manage a Jira instance with 2.2 million issues and is working towards moving to Datacenter.

All that being said, we'd be hard-pressed to find a better person to give advice to first-time Jira admins! Read on to learn Claudio's take on how to set yourself and your team up for a successful and scalable Jira journey. (Also be sure to check out this thread full of first-time Jira admin tips to hear other gold nuggets of wisdom!)

*Claudio's Summit presentations are linked at the end of this post

Top 5 starter tips

To start, I'd advise all first-time admins to properly read the Jira documentation. It has a lot of useful things to get you started with the right approach.

1. Give admin rights only to people that know what they are doing :)

Question: What's your definition/test to see if someone knows what they're doing? What could potentially go wrong if admin rights fall into the wrong hands?

Having admin power in Jira requires responsibility, no matter how large is the instance but in particular in large instances with a lot of users. I will give you a recent example, where I was doing a demo to the sales team about how flexible is Jira in creating different workflow statuses. My example included the creation of a status named “New Contract Request”, but while doing this live and quickly to my audience, I accidentally clicked on “rename” instead of “create a new status”. Result, the New status we have in hundreds of workflows was renamed to “New Contract Request”, the consequences were very wide: the change broke any and all filters that were queries issues with “status=New”, broke all the associated dashboards and irritated several thousands of users in few minutes And all these done by me with 10+ years of experience in Jira.

Another example from today (fresh): organizational change, now EIS – Enterprise Information Services became DES – Digital Enterprise Services, so now there are around 130 projects that people want to rename to reflect the EIS -> DES initials change. That is easy, but there are few hundred filters that use “project=EIS – SaaS” or “project=EIS-Single Sign On” that will need to be changed. While the change does not corrupt data, those filters will fail to execute. Now in a company that works around the clock, it is very hard to change this without some disruption.

Conclusion: The best way to administer correctly your Jira instance is to perfectly understand the impact of the change you are implementing.

2. Make sure the organization agrees on some working standards: my experience in large organizations is that people want to do work their own way without thinking about the bigger picture: this results in hundreds of workflows.

Question: Can you share some of your organizations working standards? Where/how are those standards shared out?

EIS now DES (see above for explanation about the acronym) has 130 projects but they only have 3 workflow schemas. This is a result of the good prep work they did in order to keep their working process standard across different teams. On the flip side, in 2013, we (Autodesk) created a standard Agile Project Template that is shared by around 400 projects (out of 1,650 we have) but there are many projects even within the same division that do not have a standard workflow. Sharing the standard is easy, agreeing on the standard and adopting it much more difficult. The common excuses, “we can’t now we are close to release,” or “we have some important features and can’t do it now,” or “this is not a customer improvement activity,” are just some of the many reasons not to adopt a standard.

Conclusion: Adopting a standard workflow process or project setup requires more than good Jira administration skills, you need to be an influencer.

3. Make sure the organization has a process: I found at times that organizations did not have a process but wanted Jira to invent one for them :)

Question: Whose job is it to invent this process?

Each development team needs to define how they want to work, if possible across all different teams. Example: what is the workflow when a defect happens? Is it assigned to developer first or is it assigned to QA to verify before engaging the developer? Many people believe that Jira needs to resolve this point, but that's not at all the case. About a year ago, I was contacted by one of our engineering teams with a long list of 22 things that "Jira does not do." After the 4th bullet, I found that the team did not have a clear engineering process. I tested this theory by asking, “after a defect is created what do you do?” They had few different answers, proof they did not have a process. They eventually came around, worked on it, and out of the 22 things only the first 4 on their list remained pertinent. That is, of course, until I implemented their 4 bullet requirements via a small workflow customization.

4. Keep the number of custom fields + number of workflows under control

Question: Can you attach a screenshot or describe what happens when there are too many custom fields?

Custom fields are both paradise and hell in Jira. Many times we have created almost the same custom field just because someone wants to name it in a way and another one in a slightly different way. Sending a screenshot is almost impossible for me because it has PAGES not screens, but I can send a screenshot of the system information of our production system: