How often do YOU use shared configurations for project creation? Edited

[Gustav L'Estrade]

Hello,

As a new administrator to Jira i am curious to hear how all you other administrators handle project creation for you companies/customers. 

- Do you use shared configurations? if not, what is your process for project creation?

- When do you use shared configurations?

- Have you stumbled upon issues with shared configurations (overlapping schemes etc)?

Thank you in advance for sharing your insights!

//Gustav

[John Funk]

Hi Gustav! Congrats on being a new Jira Administrator!

We use almost exclusively the shared configurations. I almost always create a new project by basing it on an existing project. I have even setup a template project, more of less, that has all of the basics for a Classic Software Kanban project and one for a Jira Service Desk project. 

We do not use Next-gen type projects. 

The biggest drawback is when you need to tweak a certain object (like a workflow or permission scheme) for a single project. But then it is easy to just copy the object, change the name, place the few edits you need and attach/replace the current object on the project with the new one.

I hope that helps!

[Gustav L'Estrade]

Hi John! Cheers!

What you are telling me makes total sense! It is as i expected. The standard scrum and kanban template projects always auto-generate a bunch of schemes, which to me seem to clutter up the instance quite fast. 

Doesnt seem too much of a drawback to copy and tweak schemes when needed! 

Thanks for sharing your experience!

[John Funk]

You are welcome.  :-)

[Dharma Ramos]

I like using shared configurations for projects from the same divisions as they tend to ask for the same issue types, workflows, screens, etc. I create templates for said divisions and then use that for the shared configuration when they request a new project. The only issue I find with it, is that when they want to change one project, but not the others, then you may need to split off from the shared configuration. 

[ChristopherJenks Qlik]

Hi Gustav,

We use a mix. 

In perfect theory, it'd be great to have templates for everything -- so I try to keep the backend as consistent as I can, and to push back on customisations.

But in reality, our legacy instance is stuffed with customisation, duplicate shared configurations, etc. It's an ongoing effort to cleanup technical debt. What I've found that sort-of works so far to is to:

1. Document a process for changes, and have a roadmap 
2. Document the business reasons for changes (i.e., can I recreate a configuration in Jira from scratch, or even implement it independently of Jira)
3. Be consistent going forward.
4. Generally question business reasons for projects, and seek why they want something different from everyone else.

I think the next step for us would be to setup Atlassian User Groups and sit down with stakeholders to discuss how they use Jira, what can simplified, and what they want to see improved. 

Shared configurations can be great for maintaining a consistent backend--but I do caution that if the stakeholders disagree then it's easy to end up with duplicate-but-not-quite-the-same groups of shared configurations that confuse both stakeholders and administrators; e.g. silos enforced by Jira.

The one skill I wish I'd had more of going into my position was more tenacity -- but also accepting it won't be improved overnight.

Hopefully this gives you an interesting perspective!

[Gustav L'Estrade]

An interesting perspective it sure is. Thanks for sharing!