Should I Create a Jira Company-managed or Team-managed Project?

[#1]

When creating a new Jira project, you are faced first with what type of project you truly need. And while there are different types of projects in Jira – Jira Software, Jira Business, Jira Service Management – one more layer of decision is needed. Will it be a Company-managed Project (CMP)or a Team-managed Project (TMP)?

What’s the difference? How do I decide? How do I create the desired type? This article will delve into those questions and provide hands-on steps for project creation.

Atlassian Documentation

First, let’s acknowledge that there are couple of online Atlassian support documents related to the topic.

https://support.atlassian.com/jira-software-cloud/docs/what-are-team-managed-and-company-managed-projects/

https://support.atlassian.com/jira-work-management/docs/learn-how-company-managed-and-team-managed-projects-differ/

These articles are helpful for some of the nuts and bolts about the two project types so that we don’t have to reinvent the wheel here for that information. But realize that Atlassian documentation can get a bit dated and/or might not answer everything you want to know.

Apart from that, the following is my take on the different types and recommendation. I would love to hear your thoughts in the comments below. The Atlassian Community is about feedback from other end users and their real-world interaction with the tool.

Things to Decide

Next, let’s talk about some things you want to decide up front. Like will this project be used by a specific set of users in your organization and no others? Is it possible that you will want to share the configuration of the project to create other similar projects in the future? Can I handle the administration on this project myself or do I need a Jira Admin to do the detailed changes when needed (workflows, custom fields, screen changes, etc.)?

Can I Share the Stuff?

Depending on your answers to the above questions, that should help guide you for the type. Team-managed projects are completely self-contained. That means that NO CONFIGURATIONS will be/can be shared between this project and other project in Jira. The slight exception is Custom Fields (see the documentation for more information).

So, if you are thinking, I want to create a “template” Team-managed project in Jira and then use it to create additional TMP projects based on what I have set up. Can I do that? The answer is No. Every TMP must be created from scratch, though you can use one of the built-in Atlassian supplied Templates. But you will always start with the same template which will not include any changes you make.

What’s the ramifications of that? If you create a specific workflow for that project, for example, when you create the next project, you will need to create the workflow all over again if you want to do the same functions in the next project. So, if you plan to make a lot of configuration changes and use that as a “template”, you will find that you need to do a lot more work. And that goes for each configuration – screens, issue types, automation rules, etc.

But can things be customized? Yes, with several exceptions. For example, Components are not available for TMP projects. Certain field types are also not available.

But Company-managed projects can do these things? Quick answer is yes – but keep reading.

Call to Action!

I have been thinking about trying to compile a full list of things that can be done in Company-managed projects but can’t be done in Team-managed projects, but just haven’t gone to the effort. Maybe you’ll help?! Include them in the comments below, and we’ll build a full set together!

Company-managed Projects Rule!! (Or do they?)

So, you’re thinking, why don’t I just always create CMP projects then? Great idea! But what’s the ramifications of that? Most notably, unless you are a Jira Administrator for the organization, you won’t be able to create the project at all. You will need one of your Jira Admins to do that for you.

Oh, and you want to change the workflow or add a totally new custom field? You’ll need the Jira Admin to do that for you, too. This frustrates a lot of people and, in my opinion, is the number one reason that Team-managed projects get created.

No Harm, No Foul

There’s an expression for friendly neighborhood basketball pickup games – no harm, no foul. In other words, don’t be nitpicky about calling out a foul on another player if it didn’t really affect the outcome of the play.

In your mind the same must be true of picking a Jira project type - I’ll just give it a go with one or the other, and if it doesn’t work out like I want, I will just convert it to the other type. All good then!

Nope, it doesn’t work that way. There is no “conversion” of project types. Same is true if you select Jira Software vs. Jira Business (or JSM) when creating the project. You might create a totally new project and migrate any existing data between the two projects. And as you might guess, that’s not straightforward either – there are pitfalls to be aware of.

Here is a fairly good document by Atlassian that discusses that migration. But be aware that data can be lost in the transfer. And there is no current tool available that handles this for you – it’s a manual effort.

https://support.atlassian.com/jira-work-management/docs/migrate-between-team-managed-and-company-managed-projects/

The Tradeoffs

We have tradeoffs then between the two project types then. And the more you use one or the other type, you will know which is best to use in which circumstance.

How Do I Create a New Project?

It’s pretty straightforward. Click the Projects menu option in the top navigation bar and then select Create project

Your next screen is filled with those pre-defined project templates from Atlassian that we mentioned earlier. And it’s not real clear which Jira project type goes with which option. But a general guide is that Software development will give you Jira Software project templates, Service management will give you Jira Service Management project templates, Work management will give you Jira Business project templates, and Product management will give you Jira Product Discovery project templates.

Clicking on any of the options on the left will give you an even greater number of templates to choose from. But be aware that some options are associated with certain project types. For example, if you click on Finance, all the templates will be related to Jira Business projects. Be sure to read the descriptions for each template to know which is which.

Beware the Big Sneak!

If you choose Software development and continue on that path, Atlassian makes it very obvious that you need to choose between Team-managed and Company-managed projects for your type.

However, if you choose one of the non-Software templates, Atlassian has sneakily defaulted the project type to Team-managed!! Using our Finance template example, we land on the Create project details page and all looks good.

But if you simply fill in the information for the visible fields and click the Create project button, you will get a Team-managed project. That’s because the place to choose the types is hidden under the Show more link. Also, note that if you want to choose your own Project Key for a project, you will need to click the Show more link.

Clicking on this link opens you to the world of the Company-managed project.

Here, you will need to click on the option for Company-managed ADMINISTRATORS ONLY block to create a Company-managed project. It is unknown why Atlassian has implemented project creation as such, but you can draw your own conclusions.

Recommendation

Team-managed projects are very appealing to many people who are just getting started with Jira. Or those users who are not well versed in the administration of projects in Jira. They sound harmless enough and are very quick and easy to create.

However, as we have seen to a small degree, there are lots of drawbacks to TMP projects. They work well for many people, and I know they are grateful. But they have also led many people to a trap of not being able to customize as they desire or to save time on building future projects.

Unless you KNOW for certain that you need to have just a simple project that will never have any part of it shared with other projects, then for me the safe and best bet is Company-managed projects.

I am interested in your thoughts and experiences. And also the CTA for things you can do in CMP projects that you can’t in TMP projects.  

[Dave Mathijs]

My answer is simple: No team-managed projects, NEVER!

At one point or another, it causes issues in search, filtering, dashboard gadgets, reporting, ... Migrating from team-managed projects to company-managed projects has way too many limitations, of which the unique project key is the biggest hurdle in my opinion. So removing this global permission for EVERYONE is the first thing I do in a new environment.

The ONLY downside is not being able to delegate the creation of projects with shared configuration to non Jira-admins, but there are third-party workarounds available to tackle that issue.

Convince me otherwise...

[Tobias Hüttenmüller]

There is a huge drawback for team managed projects for any jira instance that hosts lots of projects/users:

users can create custom fields (and statuses) that already exist globally with the same name. The consequence is that you will have to "play the lottery" at any place you need to pick a custom field from a drop down, e.g. automations, jql, reports,...
"Click the first status field and see if the report populates, then try the second, third,....until you finally get the correct field"

We have about 10 fields called Status and about the same amount of fields called Request Type. It's no fun to deal with.
We are now building custom scripts to crawl our custom fields via API and rename colliding field names every few hours to keepthings manageable.

My recommendation would be to only use this for small instances or implement the missing guardrails alongside the rollout on your instance.

The liberties for especially young and forming teams are fantastic in team-managed projects! But due to the drawbacks we use company managed software projects with the simplified workflow now instead.

[Jimmy Seddon]

Thanks for sharing @John Funk!

Much like the other have shared, I have no love or desire to see a team managed project.  I think Atlassian needs to let them go. 

[Bill Sheboy]

Hi @John Funk

Thanks for sharing ideas on this topic, and encouraging others to join the conversation.  There are several pros / cons to project type differences, and having well-informed customers and admins helps them "turn up the good and mitigate the bad".

Yes, and...

When a site only uses company-managed projects (CMP), as soon as the first team-managed project (TMP) is added (regardless of type: software, work management, JPD, etc.) the external behavior and complexity of JQL results, dashboards gadgets, and automation rules appears to be permanently impacted.  The primary cause of this is a feature of TMP: field uniqueness is no longer visible across the site.  For example, a basic JQL expression to feed a dashboard gadget may produce confusing or nonsensical results, perhaps breaking your rollup reporting for teams.  Workarounds require using specific custom field ids in JQL, marketplace addons, or extra automation rules (consuming the now scarcer monthly limits) to programmatically align information.  In some cases for automation rules, the only solution is to directly call the REST API endpoints rather than using the intuitively-named rule actions, such as Create Issue or Clone Issue.

Also please note the impact of license level and the marketplace.  Several things which could help mitigate / manage the impacts of project type differences may not be available for Free license customers.  For example, monitoring who did what and when to configuration is not possible without access to audit logs (and better logging for TMP changes).  Instead, customers need at least Standard license and / or to purchase marketplace apps.

Some changes you noted, such as allowing use of global / CMP customs fields with TMP, may help solve one challenge while removing some flexibility from teams using TMP.  There is no right / wrong answer, and instead conversation leads to what will help the team and org meet their needs.  With that in mind, I recommend reading the release blog at least once a week to monitor for such changes impacting TMP: https://confluence.atlassian.com/cloud/blog  TIP: Once you have read the entire blog for a week, you can quickly scan for updates in the future, looking for "New This Week" and "Coming Soon" additions.

Kind regards,
Bill

[Matt Doar _Adaptavist_]

Screenshot from The Jira Life merch website

[John Funk]

What an awesome shirt - I love it!!

[Robert Wen_Cprime_]

Here's the link to the Apetech merch store where you can get the t-shirt https://my-store-dc4aec.creator-spring.com/

[Tomislav Tobijas _Koios_]

I'll have to link this to our internal documentation for reference. It's a great comprehensive article about the differences and some tips and tricks when it comes to these two. Thanks for sharing @John Funk !

Pretty much like everyone else here, we tend to immediately disable team-managed projects during implementations to avoid administration clutter in the future.

One thing worth mentioning though - Edit Workflows permission is slowly rolling (on the cloud) out and with it, non-Jira admins on company-managed projects will also be able to update workflows (if permission is granted in the permission scheme). This should be rolled out together with separate Manage Issue Layouts permission.

[Chris Buzon]

if you get trapped, remember you can bulk move all the TMP tickets into a Company Managed project...
(it's still a lot of work, but you don't always have to redo-everything from scratch!)