List of what you lose going from Company to Team Managed Projects

[Nancy S. Bennett]

Hello. I am a Jira consultant and I have a question about my client's situation. They have an offshore team doing development in the offshore team's Jira instance. The offshore team is using a company managed project in what appears to used in be a reasonable and typical way that dev teams use Jira. My client (their customer) wants the project in their own instance of Jira. Makes sense. The problem is the client is not a Jira administrator and can only create team managed projects and would have to go through some red tape to become one. He is fine with doing that but he said it would introduce delays and would not be quick and wanted to do a team managed project in the interim so he doesn't lose time and momentum on the project.  I reminded him that there would be feature loss and also that migration between project types is manual. He is admitting this is not ideal and is ok with going with this route anyway. I am not an expert on team managed projects because I don't like them so I avoid them at all costs. It seems that every time I give them a chance I hit a roadblock like today, I noticed team managed projects don't support the resolution field. That is crazy to me and I know the offshore team is using that field currently in their dev workflow. Yes I could create a custom field that would represent the resolution but I hate the idea of that.  Anyway, I would like to make the argument that there are too many roadblocks doing this and they should wait to go into the client's instance until the client is a Jira administrator so we don't have to do this interim team managed project nonsense. I think it will disrupt the current dev team by making this change and also it will cost them money to have me configure the team managed project with all of the kludgy workarounds (assuming we can even workaround everything).  I just don't have enough clear data points on all of the things you lose by going from a company managed project. If I had those I think I could convince my client to skip the team managed project altogether, keep working in the vendor's instance and just wait until he has proper access and do a company managed project in his instance. So does anyone know of a good summary of the true nitty gritty of the roadblocks you will encounter when leaving a company managed project to go to a team managed one? My client is reasonable and I would like to give him some data on this so he can avoid the pain of this decision. Thanks in advance.

[Trudy Claspill]

Hello @Nancy S. Bennett 

Is the project a Software, Service, or Business/Work Management project?

I ask because the Team Managed Software projects do use the Resolution field.

There is not a comprehensive list of differences between the two project types, but here are some that I've seen raise concerns:

1. Team Managed projects don't support multiple types of Sub-task issue types.

2. Team Managed project workflows don't support the same diversity of transition Conditions and Validators as CMs, and what they do have can't necessarily operate against all the fields types. Workflows also don't support Properties nor Transition Screens.

3. Team Managed projects don't support the built-in Components field. You can add a custom field that does the same thing as a work around.

4. Currently with a CSV import you can't set the relationship between Epics and Child Issue when importing to a Team Managed project. 

5. Advanced Roadmaps don't support Team Managed projects.

6. Some functionality provided by third party apps does not work in Team Managed projects. For example, the workflow Condition and Validator additions from ScriptRunner are not available for use in workflows in Team Managed projects.

7. Not all built-in reports supported on Company Managed Scrum and Kanban boards are available for Team Managed projects.

8. The native agile boards function somewhat differently. For example in the Kanban board you can't configure the time period for when Done issues are automatically hidden from the board view. And the only way to see Subtasks as cards on the board is to use the equivalent of the Stories Swimlane feature.

That's just a few of the differences. What is most impactful to your client and the developers depends on the features they use.

[Nancy S. Bennett]

Thank you!  I was aware of most of these, but a few not so thank you very much.  As for the resolution field, I am not finding it to be supported, am I still incorrect on that? See the following link suggesting to use automation to populate the field triggered on transition event (since it is not supported in team managed projects).

https://confluence.atlassian.com/jirakb/set-resolution-field-for-team-managed-project-jira-issues-1236437014.html

And  this article says resolution is only applicable to company managed projects:

https://confluence.atlassian.com/cloudkb/best-practices-on-using-the-resolution-field-968660796.html

So are these outdated or not?

[Trudy Claspill]

The Resolution field is set in Team Managed Software projects. It will be set to "Done" automatically for issues transitioned to a green/done-status-category Status value. On the board you will see a checkmark in the column header to indicate this.

The Resolution field will automatically be cleared when an issue is changed to another 'not-green' Status value.

Team Managed projects don't support having a Workflow Transition screen that lets you manually set the value for the field. Nor can you add the equivalent of a Workflow Transition Post Function to set and clear the field.

The Resolution field is not used in Business/Work Management projects at all. In Company Managed projects you can work around that with Automation Rules, but the Automation Rules won't work to set Resolution for a Team Managed Work Management project.

I have not personally investigated how the Resolution field is or isn't used for Service Management projects.

[Mikael Sandberg]

You can find the differences if you go What are team-managed and company-managed projects? and also check out this article, Company-Managed vs Team-Managed Projects in Jira .

[Nancy S. Bennett]

Thank you and yes these explain the high level differences but they don't get into the important details such as 

-No component support

-No quick filters (only custom filters)

-Appears as though resolution is not supported 

None of these details were mentioned in any of the types of documentation that compared team and company projects, rather I found myself in a team project looking for a feature I assumed would be there then when I couldn't find it. Then, I looked at the Atlassian documentation page for that feature to find it is only in company managed projects. So I am tried of being surprised I just want a detailed list of differences and don't want to keep discovering these things unexpectedly.