Understanding Team and Company-Managed Projects
- Haddon Fisher
Overview
Jira projects can be set up as two different configuration types: “team-managed” and “company-managed”. One of these things is not like the other; it also is not possible to convert a project from one to the other and the migration process can be painful. It’s worth a moment to investigate the best option during initial setup.
The Big Difference
There are a lot of small functionality differences, but the main difference between the two types of projects is:
“Company Managed” projects can share configurations and objects (think workflows, custom fields, etc.). These must be managed by Jira administrators.
“Team Managed” projects use a lot of their own individual configurations and objects. These can be managed by people with administrator permissions to the project but are not Jira instance administrators.
The Right Project for the Job
Picking the right project type can be harder than you might think. While the attraction of managing your own fields and workflows might seem tempting, team-managed projects also come with some major downsides.
In general, it’s safe to use a team-managed project if:
Your work is self-contained and does not roll up into a larger roadmap or coordinated plan.
Outside of regular issue linking, your work do not need to interact with issues in other projects.
You are comfortable making project configuration and administrative changes on your own.
Conversely, you need a company-managed project if:
Your team’s work will appear on a multi-team roadmap, particularly using Jira’s “Advanced Roadmaps” feature (this is less true than it was, but I can’t say this isn’t still true).
You want to view or report on work from multiple teams or projects in a consistent way.
You don’t want or don’t know how to manage a Jira project, or otherwise want\need a Jira administrator to manage your stuff.
The other thing to be aware of is that, in addition to the way configurations are handled, there are a lot of smaller differences. These gaps exist all over the landscape, so I wouldn’t automatically assume anything in company-managed projects work the same in team-managed projects.
TL;DR
Team-managed projects are great for teams whose work is almost-to-completely siloed within that team.
Everyone else should use company-managed projects.
Should I Enable Team-Managed Project Creation?
It is possible to configure Jira to allow users to create team-managed projects. In most situations and all things being equal, I would could recommend disabling this.
Team-managed projects in and of themselves have a couple of decently painful negative implications for the entire instance.
Even instances actively trying to follow best practices will have a few projects just hanging around; things archived for compliance reasons, projects that have gone into the icebox, or noble attempts since slipped into the icy grip of entropy. Multiply that by anyone who has access to this. Which leads me to…
You’ll likely end up with a lot of projects, which can have some negative performance and UX implications. My experience is that it also will likely be very hard to clean up post-facto.
For Jira Service Management Customers
You should absolutely disable team-managed project creation by users if you are a Jira Service Management customer.
There is no ability to restrict which flavor of Jira a user can select when creating their team-managed project, meaning your users will be able to create new Jira Service Management team-managed projects with this functionality enabled.
Users generally will not realize they need a separate (and much more expensive) agent licence for everyone involved in their new project in order to use it.
TL;DR - This can balloon your bill if you’re not prepared.