It was inevitable. After some time using the brand new, “clean” slate of Jira project configurations, additional adjustments needed to be made. I am not resistant to additional changes. In fact, I inform team members that they should expect changes to the initial configuration to occur in order to adapt to changing business needs - a big selling point for adopting the Jira platform.
Before I even begin to fulfill the incoming request, I hit the brakes and run through a few questions before any configuration. Here are the questions I ask before implementing the configuration:
Note: These thoughts only pertain to configurations that support company-managed projects. Team-managed projects don’t require much involvement from Jira administrators.
- What is the problem we are trying to solve? It is important for me to understand the context behind the configuration request. Once I understand the problem, I can use my knowledge to either move forward with the configuration request or suggest another option that may serve as a better solution.
- Do we really need this configuration? Sometimes, I discover that the configuration does not solve the problem at hand. When an additional discussion is held with the requestor and/or team, we usually arrive at a solution that does not require the original configuration request to solve the problem. In this way, we can avoid unnecessary configurations and keep the Jira site clean.
- Can we use a configuration that already exists? To minimize redundant configurations, I will first identify existing configurations that can be reused. For example, instead of creating a new status, I will pitch a similarly named status to the requestor. The same holds true for priorities, custom fields, issue types, and more. If I recommend something different than what was requested, I promise I am not trying to push my own agenda or exercise control. I simply want to meet your objective and keep the Jira site simple to manage.
- Is this a change that you are able to do without my assistance? There are multiple levels of administration in Jira. I will oftentimes receive requests from project or board administrators to implement a configuration that they are able to do without my help! For example, a project administrator may ask me to provide project access to a user. If the project’s permission scheme uses project roles, then a project administrator is able to provision access to users. In these situations, I will coach the requestor and/or appropriate user on how to fulfill this request so that I can empower my coworkers and reduce my workload.
Once I run the configuration request through these questions, I’ll implement, validate, and ask the requestor to validate the configuration.
This is my thought process for Jira administration. Yes, I realize that these principles are useful when administering other systems as well! Fellow Jira administrators, what is your thought process and approach to Jira administration on the sites you manage?
4 comments