Organizational aspects of a stable Jira setup at scale

[#1]

The very first Jira installation I came across was one where almost everybody could get global administrator permissions. This lead to a enormous boost of acceptance but same time to an incredible configuration mess that no one was able to clean up in the end anymore.

Inspired by some dicussions about best practices regarding workflows, custom field setup but also structuring projects I'd like to share my experience with the organizational side of managing Jira instances within an enterprise.

One term that often is used to describe this instrument is "Governance" - basically it is a group of people really interested in creating a sustainable setup of Jira (or any other tooling, it does not even have to be Atlassian based - the idea behind it can be understood as an universal approach).
This group, we call it "Governance Board", meets regularly to discuss new ideas and process requests from the userbase which are beyond standard processes (creating a new project or providing user support) - we call those meetings "Governance Board Meetings".
By the way: recently we found out that an exchange of thoughts and ideas via a Confluence page work as well, sometimes even better!

We noticed a great benefit when we invited attendees of a diverse background.
Jira administrators, power users of a specific department and interested parties come together. Project managers, developers, non-technical staff are invited - sometimes they are selected based on their previous experience but in busier times applications come in not so frequently.
We found out that this is rather an advantage to onboard less experienced people, they tend to see challenges from a different, non-biased angle. Their contributions led to several smart solutions in the past, so it is really about a team which is able to attend in-depth discussions rather than a few persons bringing in a huge amount of knowledge.

In most cases, the Governance Board is moderated by a Governance Lead. This person takes care of writing a short summary for all who could not attend, to maintain the governance Jira project and to keep documentation up to date (I will cover this part later).

By now, this model has been adopted and installed by several business units that run Atlassian products. We consider it normal that, based on culture and specific requirements, each Governance operates in details a bit different.

How does an example for a good working governance model look like?

There are many examples what the Governance is tasked with throughout a year, let me just highlight one very easy example.
Imagine, two teams want to have an App from Marketplace purchased for project management but two vendors did a great job and have awesome offerings.
Surely, both teams could theoretically purchase two different Apps providing the same feature but at the end it is a question of budgeting and also user training.
Also it would not foster a common understanding of a collaborative tool usage and there is a risk of building silos which is absolutely not the goal.

The Governance Board meets in such a case and acts as a mediator between both parties. For example, a project manager attending the board could report from their past experience and tell about pros and cons with each App. We found this works better than a single person needing to take the decision.
It surely requires some discussion and amount of time to get to a decision but it is worth the effort.

Also the Governance board is a perfect forum for sharing ideas and always a chance to learn from each other.
Why learn? In many cases, a solution for a requirement can be found - without additional configuration, simply based on existing elements and knowledge.

After a decision on an intended configuration change is made a smaller subset of Jira administrators is asked to implement the solution. They know almost every part of their instance and the interactions between other teams and configurations.
By implementing this approach we saw huge improvements in performance and reliability.
From past experience the whole system works best when admins are also members of the respective governance board.

How are decisions made in particular by the Governance Board?

In general, decisions are made based on a few core questions, some of them include:

• "Will a great amount of users benefit from the change?"
• "Are there current requests that aim for the opposite of the proposed solution?"
• "Do we need user training? If so, how much effort will it be and who is responsible?"
• "Do we need to purchase an App? If so, how much is it? Are there alternatives? Which vendor provides the one that works best for our teams?"

How important is documentation?

We found out that documentation is key. Confluence works best for our teams and an important learning is to document as much as you can. Configuration like workflows, schemes, user management basics and system settings are of interest for users which want to evaluate if Jira is a good match for them.
They do not need to ask an administrator over and over which configuration is available but can check everything carefully as a self-service offering.
Also documentation about the Governance itself is very valuable. Users can see what is available out of the box and what needs consultation of the Governance Board.
This, indeed, needs some time to evolve and improve.
For example you could later add documentation when the next upgrade is taking place and which version you will be upgrading to.

How can the model be summarized in a few words?

To summarize it in a few words: the whole approach aims towards a clean and tidy setup which is easy to understand and provides all users the best possible value. However, in case a specific requirement is needed from a business perspective the Governance Board meets and starts a discussion to find an appropriate solution.

[Dave Liao]

@Daniel Ebers - This 1000%!

To those reading: To help with adoption of structures like this, consider naming your governance board something less (or more!) intimidating/appropriate for your org.

I've seen engineering organizations call their governance board "change control board". I also happen to know a media company that calls their governance board a name of an influential group from one of their media properties. 😅

[Capi [resolution]]

Great article @Daniel Ebers , thanks for sharing! Do you find that the governance board needs to go very technical sometimes to make decisions about how to standardize and simplify the instance?

[Kathi Paquet]

I agree with you!  I am constantly experiencing  organizations that have almost everybody with global administrator permissions and no collaboration/coordination when adding apps, modifying core issue schemes, etc.  I always recommend limiting admins and forming a governance board.

[Kathi Paquet]

Yes, the word "Governance" sounds so strict.  I sometimes utilize the naming as  "Atlassian Steering Committee" or "Atlassian CoP" 

[Brian Hill]

Great article @Daniel Ebers, thx for sharing, encapsulates a lot of good practices that can be hard, but necessary, to retrofit onto a wild west estate. I've also used an alternate Atlassian Pattern Mgt title, with relevant APM spaces in Conf/JIRA. The reality is that its a governance role but needs to be able to do technical deep-dives to find optimal patterns needed.

[Dave Liao]

@Kathi Paquet - ooh, haven't heard "CoP" in awhile - I like "Atlassian Guild", where the actual board consists of Atlassian Guild Leaders. Insert your ideal titles there ;-p

@Capi [resolution] - I've found many former Jira and Confluence admins are ideal members of a Governance Board. They tend to be outspoken on their experiences as an admin, and they have practice translating what a configuration change means when it actually "hits the road" for end users.

Just because something can be done doesn't mean it should be done.

[Daniel Ebers]

@Dave Liao+ @Kathi Paquet: thanks for the input, very true! A friendly and welcoming name can change a lot - like everywhere else also for this model there is a lot about marketing...
The term "Steering Committee" is already in use 😅, this is when several Governance Boards come together a few times a year to have an exchange on a greater level.
I absolutely see what you mean - and would give the model a better suited name if we were to start today.

@Capi [resolution]: yes, I would say so. While Jira offers an interface where non-technical staff can do a lot without having deep knowledge of software ("a few clicks and I am done with a beast of a workflow") - on the other hand admins need to have a good knowledge on how all pieces work together. This needs then a good knowledge of technical details.

@Kathi Paquet: yes, reducing the amount of admin accounts contributes a lot to a tidy instance. We saw in past a direct connection between adjusting the amount of admin accounts and global configuration mistakes like a renamed status reflecting in all worklows and such.

@Brian Hill: I agree that some aspects can be hard and are not considered very 'popular' with the staff. Sometimes even an oldschool voting is inevitable - where the requester sits with his smartphone and checks if they already obtained a majority for a solution that they want to have implemented. But like you said, it is about finding the optimal patterns after all and if done respectfully the model can work well.

[Dave Liao]

@Daniel Ebers - heh, nothing's wrong with a group literally called "Governance Board" - I've worked at places where that would be the friendly name of such a structure. 😂

[John Dunkelberg]

Our is simply "JiraGov" :)

One item I don't see mentioned above is discussions about the performance of the Jira instance.  We've learned the hard away about well-meaning customizations done in our early rollout stage that had substantial impacts on performance.  We make an internal "release" of Jira every month, and performance benchmarking helps us monitor that a new change does not degrade performance.  This also helps compare when we upgrade to a new version of Jira (we're on Datacenter) to see if user workflows have improved or degraded.  That said, this is an area I think is ripe for both Atlassian and third parties to improve on.

[Dave Liao]

@John Dunkelberg - would love to learn more about how you performance benchmark!

What tools do you use? What do you monitor? What's your methodology? Anything you're willing/able to share would be nice 🙏

[elizabeth_jones]

This is fantastic advice. Thank you so much for taking the time to detail this process and sharing it with all of us.