You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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.
In general, decisions are made based on a few core questions, some of them include:
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.
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.