How to kick start an Atlassian Governance Board
What is an Atlassian Advisory Board?
An Atlassian Advisory Board is a group whose charge is to receive, evaluate, and approve (or decline) requests for changes to be made to one or more Atlassian tools.
It's completely acceptable for this board to cover more than just the Atlassian toolset, but we'll only cover topics related to Atlassian tools in this guide.
Who should be represented on a board?
- Atlassian Service Owner
- Admin Team Representative(s)
- Project Leads/representative(s) of teams using the tools
- Executive Management Representative
The executive representative on the advisory board should have enough clout to ensure that decisions made by this group are taken seriously by the rest of the organization. Without executive stakeholder buy-in, changes with political impact may be difficult to undertake.
What does a board do?
Advisory boards meet at a regular cadence (semi-monthly or monthly usually) to establish processes and guidelines related to the usage of Atlassian tools in the client organizations.
Some of the areas in which we see advisory boards bringing the most value include:
Establishing governance
- Add-ons and customizations
- Put processes in place to ensure that add-on/plugin requests are handled based on business need, performance impact, security concerns and other factors.
- Lay out processes to effectively vet and manage tool customizations - workflows, custom fields and others.
- Decide when to encourage reuse and standardization and when customizations are necessary.
- Retention and archiving
- Set policies in place around retention of projects/issues (number of years for example) and archiving of unused projects/issues to minimize the impact of instance growth and keep the system performant for its users.
- Control vs. empowerment
- Decide how strict or weak the governance policies are going to be for the Atlassian Tools
- Governance in organizations which operate in very tightly regulated industries (e.g. finance, healthcare, etc.) needs to be very strict: permission and security restrictions have to be in place, audit trails are necessary, and the overall system is very tightly controlled. This is starkly contrasted with governance in companies like Atlassian where information transparency and user empowerment are more valued than regulatory requirements. Every organization has to figure out where on this spectrum their governance policies and processes lie.
- User communication
- Understand and communicate the impact of customizations on performance and usability of the toolset to their teams/tool users
- Set process and cadence for communication of upgrades, tool changes, new features to teams/tool users.
Enabling organizational transformation
- Ensure that the tools enable teams to work better together and be more effective rather than being a hindrance
- Align the tools better around teams and processes to support any transformations (e.g. Agile, DevOps, Lean, etc.) that the organization is going through.
Providing increased visibility & reporting
- Rollout Atlassian tools in a manner that helps teams using the tools work efficiently while providing increased reporting and visibility across teams.
- Get input from all teams before any major rollouts or changes in the structure and organization of the tools and decide the best course of action.
- Vet Integrations between Atlassian tools and other tools in their ecosystem to provide increased visibility across the different tools in the organization.
Establishing accounting good practices
- Strategize on the methodology and tools, and establish good practices to roll up hours across projects/teams as needed for accounting and payroll.
Facilitating tools training & adoption
- Facilitate training for end users, project leads, and management teams when necessary, introducing new add-ons, integrations, features and products.
- Create on-boarding plans for new users to the organization's tools and processes.
- Seek to understand tool use cases when a tool is being rolled out to new users/teams. (For example, non-technical teams like marketing might have very different requirements than a technical team.) Decide on the balance of tool customizations vs. tool usability.
- Serve as champions within the company for all things Atlassian. Become the SMEs for Atlassian tools.
- Help drive company and/or area Atlassian Community Experience groups to increase tool adoption
Driving tools expansion & integration
- Recognize differing needs of teams and evaluate & introduce new tools when necessary. For example, evaluate Trello for the marketing teams if Jira is not working for these teams due to technical complexity.
- Ensure that new tools integrate with existing tools in the ecosystem to provide visibility and tracking across teams.
What does a board not do?
- An advisory board is not in place to dismantle responsibility - it should drive policy.
- An entire advisory board is not needed to group review and judge an add-on request, for example; rather, it should set the process for how to evaluate the request based on business impact, performance impact, and other guidelines it deems important to the organization. An evaluated add-on request may have its final (dis-)approval made by this group if your process dictates it.
How do I get started?
- First, identify your key representatives above. Your executive stakeholder should be known and in alignment from the beginning.
- Second, document the charter for your advisory board. Answer these questions:
- What changes and/or decisions are in scope?
- What changes and/or decisions are explicitly out of scope?
- How will we agree on a decision? Do we require unanimity or consensus? Does anyone have veto rights for or against a change?
- In additional to changes, what other sorts of driving activities will we cover?
- How is the board makeup augmented over time? If new teams come onto the tools, do they get a vote?
- Third, determine your process.
- How will you track change requests? (We recommend you use Jira with a simple workflow.)
- How are changes classified? Consider urgency and scope, to begin.
- What level of documentation is required for each change? Is a justification sufficient, or do you need a completed DACI for some changes?
- How often will you meet? This cadence will drive, or be driven by, how often changes can be made. For example, if you have a monthly change window, you will want to meet monthly, with enough lead time before the change window so that your teams can submit and execute changes with a smooth process.
- What is your SLA?
- What is the exception process for urgent or standard changes?
- Fourth, communicate to all teams who make, propose, or influence changes how your new governance board and process will be operating.
- Finally, start meeting, and start deciding! Be sure you document your decisions effectively!
Was this content helpful?
Connect, share, or get additional help
Atlassian Community