When should users use the 'company-managed' project template?

[Michael Thaney]

We are implementing Jira cloud and defining our governance model.  We don't want to create barriers for users to start projects.  Anyone have good criteria on when to use 'company-managed' projects?  Are there reasons why we shouldn't create these as the default project type?

Follow up question, if we assume team managed by default and use of company-owned when needed, how do you inform end users so they don't get started with a team managed project and paint themselves into a corner and have to create a new project later?

[David Libby]

The fact that you're even using the word governance leads me to believe that you'll want to opt for company-managed. If you want to be able to create portfolio-level views of your delivery setup, using boards that traverse your project "ecosystem", you'll want to go with company-managed every time. My view on team-managed is that it's great for pop-up projects or hobby projects, but for anything beyond that they're just too limited.

[Lorenzo Phillips]

I agree with this assessment as well. :)

[Cheri Hansen]

I also agree.  Very well stated.

[Oksana Dersovitz]

Here is our experience : we started out with no governance, and quickly realized that we must have project templates (custom workflow schemes, etc), otherwise there are too many projects that were just test projects and abandoned later. Reporting was impossible due to no standards, and users were creating custom fields that might have been the same semantically but had different names depending on the department. 

We limited project creation ability to only a handful of super-users from each department. There is now a project request process. Software developers are forced to pick from 5 templates. Business divisions can use next-gen projects, but I create those and I assist in customization depending on their needs. 

[Lorenzo Phillips]

@Michael Thaney 

There's nothing wrong with using company-managed or team-managed. We typically tell clients to set their standards based on their internal requirements.

For example, if you don't have an internal Atlassian team or maybe you have a couple of admins but the workload is too great for them to keep up with, then we recommend that our clients use team-managed as this removes the burden from the Jira Admins and gives power to the Project Admins.

However, company-managed projects provides the most flexibility and power in regards to customizations so most clients like to go that route. Also, with company-managed projects, you can share the Schemes and reduce clutter.

Now if you're going to allow team-managed projects, you will definitely need create a cleanup strategy because team-managed projects allow users to work in a more isolated mode so you can end up with a lot of duplication (ex. status names).

To give you guidance, I'd recommend using company-managed projects for now. And if you can, create some project templates to reuse and share the Schemes. While team-managed projects are rapidly becoming more feature rich like company-managed projects, they still have a ways to go and you can avoid many headaches associated with making them generally available.

Hope this helps, but if you have additional questions don't hesitate to ask. :)

[Mikael Sandberg]

Hi @Michael Thaney,

Welcome to Atlassian Community!

Company-managed projects should be used if you want to be able to control that all your projects share the same set up. Team-managed projects are like it's own island, anything created within that project cannot be shared with other projects, for example workflow statuses and custom fields. 

[Joshua Mathews]

We don't want to create barriers for users to start projects

To me, this screams "team-managed".  If you want end-users to be involved I think you want the KISS mindset. 

The company-managed projects have a lot of horsepower, no doubt! But horsepower brings its own problems by its nature. A lesser known Yoda quote:  Power leads to Complexity, Complexity leads to Barriers, Barriers lead to Complaints. 

If you want users to be able to quickly throw up their own projects and workflows, I'm a fan of the team projects. You do lose features, but you also "lose" an amount of complexity across fields, screens, etc. 

[Mykenna Cepek]

There are folks who will discourage you from using Team-Managed Projects, and they have some reasons that are quite valid for many organizations (different processes for similar teams, various project limitations, etc). However, for a team that strongly wants to self-manage their process (albeit in a Jira silo), it can be an option.

As others have mentioned, consistency across an organization is a key driver for using Company-Managed Projects. Consistency among things like issue Status, Types, and Labels can be really helpful for metrics and reporting. Minimizing the number of different workflows and board configurations can help when team members span multiple teams. However, all of that is at the cost of your admin(s) in terms of support, oversight, troubleshooting, and user support/education.

There have also been a few topics in this Cloud Admins forum over the last month that have explored project setup issues. I recommend reviewing those, if you haven't already, to explore more of the details and admin feedback on those topics (scan for subject containing "Project").

[Gnan Arige]

Please consider the following points as a part of cons:

There is a problem when we are planning to migrate non company managed projects to server based jira application as you can't migrate them directly. You are required to modify from non Company managed projects to Company Managed projects before you do any data migration(s). This is one of the downsides of letting users to create their own projects. 

Secondly, there won't be any proper structure exist and users may start creating as they wish without looking at the vast usability benefits across the company.

Lastly, users may create custom fields left and right, which will downgrade the performance.