Jira Configuration Change Governance

Question

What do you use on the Enterprise level to manage Jira configuration change requests from the users? With thousands of users, I think some Change Control Board is needed. Also, how to roll out standardization from a once a wild wild west Data Center migrated to the Cloud.

Any thoughts or suggestions? Thank you for your input. It is appreciated!

Don Hames · Answer

@Trudy P Claspill Thank you for your response. I agree with everything you have said. I turned off Team Managed projects on day 1.

I agree with rolling out a standard configuration and putting some governance in place to request changes with justification. I plan on using Jira Service Management to create a Governance portal and have our Control Advisory Board review, vet, and approve/disapprove all requests.

I agree with the new Administration setup in Cloud and have reduced the org admins to myself and another person. Getting Jira admin privileges will require showing how it is necessary for your job function, and then it will be JIT and removed upon completion.

I have a long road to untangle the Wild West from our Data Center to an organized, standardized, and controlled Cloud instance. It's good to know people like yourself have already walked the path, which is doable. Thanks for the advice.

Trudy P Claspill · Answer

Hello @Don Hames

If you want standardization then one of the first things you need to do is ensure end users cannot create Team Managed projects.

At a previous employer (10k users, globally distributed, hundreds of projects) we rolled out standardized project configuration as part of a migration from one Data Center instance to a new Data Center instance. We spent time speaking with our users about the types of work that were being tracked (primarily software development) and came up with a small number of standardized configurations that met most of the users' needs. Our standardization was being driven by the Executives needing to be able to get cross team and roll up reports, so we had their support in driving teams to standard Jira project configurations.

Our goal was to keep the configurations simple. If there were teams that felt they really needed a particular custom field then we might make a generic custom field into the shared configuration and allow teams to use it to suit their own purpose.

We severely restricted the number of people who had Administrative access to Jira, and we did have a change control board to review any changes requested by end users that would have impact to the standard configuration.

Our admins understood that we had a policy that all projects had to be created using a shared configuration. It was not acceptable to create new projects with independent configurations without clearance from the Change Control Board.