Project Organization...

[Jane Ellis]

Hi there!

I recently started with a new company that's using Jira. Their particular Jira instance was already set up when I arrived so things are a little messy as me coming in as the new admin.

I have a question/wanted some input on the best way to organize Jira Projects. Right now, every team has their own project (which is over 60 projects across the company). All of these projects are company managed so that things are "scalable" across the company. I'm finding that having all of these projects is not at all scalable.

Each team is under a particular "umbrella" for lack of a better term. My thought is to create a project for each umbrella and then either use components or a custom field "Team", to assign the work to the team and create their boards off of those fields. 

I honestly think that is why each team has their own project is because  whoever built this instance didn't realize you could add multiple boards per project.

I am honestly just trying not to have to manage a million workflows and custom fields that are not applicable to the entire company. I think that by creating these "umbrella" projects, we'd have more customization available to the teams because they would all need the same workflow and fields rather than having a ton of generic fields that may not apply to them, but apply to others.

Thoughts? Let me know if this doesn't make sense. I'd really love to get some other folks opinions on this and see what works for your current set up. Thanks so much!

[Marcin Wiktor]

The first questions you should ask in my opinion are:

• Do all the teams work on the same product? If not, it's better to keep separate projects
• Should every employee be able to browse all the issues, even from different teams? If not, then you should keep seperate projects for security reasons
• Do all the teams share the same workflow and way of work? If some workflows are customized then making rules/conditions/validations based on teams - when you have 60 teams - would be a nightmare
• Keeping 60 boards in one project could be worse than keeping 60 projects - if people would like to browse issues from search bar, prepare custom filters etc... it could easily become a mess

I'd suggest to try to merge some teams that are working in the same "area" and share the same way of work but do not try to merge them all into a single project

[Sam Nadarajan]

I agree with the questions @Marcin Wiktor is posing here. I prefer to keep a product to a Jira project, and then use boards by team, but that approach doesn't always work.

I remember going into one organization where a single team was responsible for the development of multiple products/applications, and they had a single Jira project per team, but they ran into issues where they couldn't easily identify which issues belonged to which product/application.

After additional discussions with them I determined it was best to

• Create a Jira project per product/application
• Create a board for each team
• Modify the board filter to include multiple Jira projects

That way, if the team's staffing changed, or a Jira project needed to move from one team to another, I would just need to modify the board filter, and not have to worry about moving a bunch of issues between projects.

I'd be interested in a few more specifics as to your setup you have right now.

Hope this helps