Top 3 Instance Configuration Actions for Novice Jira Admin

[Sarah Schuster]

We have a novice Jira admin who needs to configure a new Jira Software instance for a Product Development Team.

Your thoughts: What are top three critical actions this admin should do in customizing this new instance in order to make this team successful in Jira Software, and why? 

("Actions" meaning updating settings or features like permissions, schemes, boards, roles, dashboards, workflows, etc.)

[Mariano Galán Martín]

1. Think about and configure new groups And Group membership of users.
2. Think about and configure global Project Roles you need. (Don't forget the default members). Associate users&groups to Project Roles in each Project. 
3. Create Project "templates" with configuration schemes you can reuse when you create new projects ("with shared configuration"). One template per project "category". Configure notifications & permission schemes with Roles.

[Sarah Schuster]

Thank you @Mariano Galán Martín! Great feedback!

[C]

We allowed teams to customize their JIRA instance to meeting their teams needs since we had no direction from our leadership to standardize.  the result was a 2000 hour project and a lot of of pissed off users who had to change.  (at one point we had 52 JIRA Admins, it grew organically to 2000 users, today we have 3800 ) 

I strongly encourage the restriction or limitation of allowing teams to create their own custom fields, workflow statuses, and other system level configurations. 

we found that JIRA out of the box was more powerful to transform teams then complex processes and workflows they created.

We created very loose best practices that drove our we created project templates and what teams could do on their own.  

Most important:   Think of reporting first!   if we considered our reporting requirements up front, 90% of our decisions would have been different.

[mhw_ytg]

+1 for Reporting first - this resonates strong with my experience in a totally different field - map making. For example, knowing when you start that international borders need to visually distinguished from internal border saves a lot of time fixing after the fact. To avoid spending all your time hand tuning every line the "border" features can to have a "type" field international lines are drawn differently from province different from state different from county different from municipal, all powered from a single symbol rule set. 

[Victoria FREDERICKSON]

Noted, thank you for posting on this topic. Very important to keep in mind.

[david.partridge@cleargage.com]

Try organizing your boards and teams in Process flow first. When I started at my current company there was a board for everything and it was an adminstrative nightmare to get it cleaned up. I agree with the above posts to limit the amount of Admin rights that you grant within your Org.

[Myles Fullen]

Reporting first is definitely important, especially if you're wanting to demonstrate value - it means you have a fixed baseline from the start, and can then use the reporting to measure how the system is affecting (and hopefully improving!) performance of the teams using it.

[Vickey Palzor Lepcha]

1) Board

2)Workflow and permissions

3) Filters

[Marcela Junyent]

I agree a lot with its being said.

I'd like to add, that to me the first most important step is to talk with the Projects Administrators (and key users)  to know what problems are they facing into using jira to track and organize their projects and teams.

Then establish a set of priority objectives to change in order to solve those problems. Always having in mind the best practices in the configuration of jira, such configuring the needed groups, creating the project roles and standardizing schemes (permission, notifications, workflows) to be use in most project. In order to share as much schemes configuration's as possible, in this matter avoid overload of schemes (and therefore improve the administration work and performance)

[deayrs]

My firsts to consider:

Roles: Discuss, Communicate & Configure Global Project Roles, Groups.

Permission: Now that you have an idea of the Roles who belongs in what group and what permissions will they require to execute their function(s). 

Project Type: Agile or Not - Considerations Frequency of Change, Incremental, "WestWorld" or "Waterfallish" all will determine what Project 'type' that will best fit the work ahead.