Why in the world are there "Team" and "Company" managed projects?

[brad-anderson]

Why in the world are there "Team" and "Company" managed projects?

[Trudy Claspill]

Hello @brad-anderson 

With Company Managed project the project configuration can be managed only by Jira Administrators. Organizations that want to limit administrative access for the Jira system may find it challenging to accommodate the customization requests from end users with a limited Jira Administration staff. Additionally changes to the configurations can impact other existing projects if the configurations have been shared between projects.

Additionally, only a Jira Administrator can create a new Company Managed project.

Note that some Organization want to exert centralized control over project configurations so that they have a standard information set that can be used to generate rolled up data reports for management.

With Team Managed projects the project configuration can be managed by the project's Project Administrators. The customization they make are limited to their own project. The changes to Notifications affect only their project. They can create addition issue types, change the workflow, and add custom fields that are used only in their project. They don't have to worry about impacting the configurations of other projects when they make these changes. 

Additionally, Jira Administrators can set a permission allowing non-Jira Administrators the ability to create new Team Managed projects. This reduces the overall burden on Jira Administrators.

[Matt Doar _Adaptavist_]

Trudy's answer is the right one from a business perspective. Historically there were only "company managed" projects, and there was a lot of complaining about Jira being too inflexible for teams because the local Jira admin had to make all the changes. So Atlassian introduced team managed projects. Unsurprisingly those were very different from the original kind of projects and didn't play nicely with them in various ways. So Jira admins generally don't want to manage the seemingly random set ups of many team projects later on, and just see them as added work. It's a tricky balance but many large orgs do not use team managed projects at all, in my experience.