JIRA configuration management (centralized/decentralized)

[Michael Schlueter]

JIRA allows/requires a lot of project specific configuration (workflows, issue types, custom fields ...). Changes to this configration requires a JIRA administrator.

We have decide if we setup a central service unit that does the job for the entire company; or if we have decentralized, domain specific JIRA administrators which to the job locally. It would be nice, if someone could share his experiences. I would also be interested in the average effort that we have to calculate for such a configuration service.

[Nic Brough -Adaptavist-]

There's no easy way to work out how much administration time and effort you might need.

If you've got a stable and well defined "we all do things in one way", or even "there are a fixed 5 ways of doing assorted things" type approach, then you'll need an admin who can set it all up and then their workload will drop as they move into maintenance mode.  But if you've got a constantly moving approach where a lot of projects may work differenty and expect to change their processes a lot, the workload will be constant.

I've worked in a range of places, and the one thing I would absolutely recommend is a small team of administrators who talk to each other properly.  It is very easy in JIRA for one admin to change stuff (partially or completely) globally, and even experienced admins sometimes mess up, let alone an inexperienced one.  That means I would tend to recommend your "central service" over domain-specific services - a lot of my jobs with JIRA have started from "we had local admins, it's a mess, please sort it out".  But it can work, as long as they work together.

[Michael Schlueter]

Thank you!

[MattS]

Search for Governing JIRA at Scale from last year's Summit to see my experience at Yahoo. Basically centralized

[Michael Schlueter]

Thanks, Matt!