Team-managed projects, now also in Jira Service Management

If you’ve been working in Jira Cloud instances for some time, you’ll already be familiar with the different types of projects: team-managed and company-managed. These used to be known as Next Gen or Classic.

Until now, team-managed projects were only available in Jira Software and Jira Work Management products. These types of projects were designed so that any user, without needing to know how to administer a Jira instance, could create, customise and use them with their team. As their name suggests, they are team projects: created by the team, managed by the team and therefore, without any connection with the rest of the company’s projects. All the configuration that is done in these projects (extremely simple) stays in these projects, without interfering in any other project, nor in the general administration of the instance. They can be very useful for small, temporary teams or even isolated projects with a specific duration. In case you need to be able to move forward without Jira administration knowledge, they can also be a very good solution.

Atlassian is working to incorporate this feature now also in Jira Service Management projects. And we have tested it to tell you all the details and evaluate how worthwhile it is for this kind of projects.

If you also want to try this functionality, which is currently in Beta, you have to make a request to include this option in your instance and that’s it. It can also be enabled from <your site name>.

The main characteristics of these projects, with respect to company-managed projects are:

• STRUCTURE:
  • In a more visual way we can see how these types of projects are formed:

• There are no schemas of any kind involved and all the configuration is carried out in a more autonomous way, which simplifies this configuration.
• The maintenance of the project is done directly by the team and not by the administrators of the instance.

• ROLES AND PERMISSIONS:
  • Access to the project can only be of two types: private (only people added to the project can see it) or open (anyone in the instance can see it).
  • Permission management is done directly through the project roles.
  • Instead of having a permissions scheme, we have the possibility of creating new roles and including the permissions that these roles must have.
  • In the same section where the role permissions are managed, users and groups can be added.
  • This is a very quick way of managing users, roles and permissions all at once and in the same place.

• REQUEST TYPES:
  • From this section is where you will be able to create new fields and select, just by dragging the element, where it is going to be included: in the portal or only in the agent’s part to include the information that will only be treated internally.
  • You can also edit the workflow, create new request types, set mandatory fields and default values from this section.
  • The workflow creation is done from a much simpler and simplified editor.
  • In the workflow, post functions, conditions and validations have been removed, which in this type of project are called Rules. They have little variety of rules which limits quite a lot what can be done in the flow (g. restrict transitions to certain people, states or values of a field, automatic assignment or automatic editing of a field). You will probably have to use automations rules to compensate for this.
  • In contrast to company-managed projects where we find several schemas to configure and add to the project to define a request type, in team-managed we have this in one place.

• PORTAL:
  • The visual appearance of the portal is identical to that of a company-managed A user entering the portal will not see any difference between two portals that coexist in the help centre and are of different project types.
  • The appearance and access to the portal can be configured in the same way as for a company-managed Customer permissions are also configurable from within the project.
  • You can create Forms, add languages, translations, satisfaction surveys, Confluence knowledge base just like in company-managed.

• NOTIFICATIONS:
  • The notifications that customers or clients receive are the same as those of a company-managed project and are configured from the same project.
  • The internal notifications, which would be received by Jira agents or users, do have some differences compared to company-managed projects (e.g. not being able to select a user or group specified in a field to be notified, e.g. not being able to select an individual user).

• OTHER FUNCTIONALITIES:
  • Automation and SLA: there are no changes in this regard, they work the same as in company-managed
  • Queues: there is no difference in the configuration of the queues either, even columns or filters can be added with the custom fields of the request types.
  • Filters, JQL: in the advanced search for incidents we can also add columns or filter by fields that are specific to this project.

Before venturing to select a project of this style, you have to take into account the following limitations:

• Workflows and statuses can be copied between request types, but not between different projects. Remember that whatever happens in a team project, stays in the team.
• The rules enabled for workflows are quite limited, so you may have to rely on automation rules if you want to extend the features.
• In the request type configuration, you will not be able to choose which fields are editable and which are not.
• If you regret after a while working with this type of project and you want to change to one managed by the company, you will have to create another one and move everything. There is no natural migration to do this.
• If you also have Assets, and there are fields that share information, you will not be able to use them in this type of project.
• You cannot include the ITSM template for the moment.

After this analysis, our conclusion would be the following:

After having tested all the team-managed project types that can be created: for Jira Software, Jira Work Management and Jira Service Management, the latter are really the most similar to company-managed projects. They keep many functionalities intact and even improve and facilitate the configuration of the project itself by unifying several configurations in the same menu.

On a technical level, what convinces us the least is not being able to select the fields that will be editable, as there is no option or screens as such. And the limitations of the workflow, there are very few actions available right now.

Of course it is a very good option and totally valid for a team that can work with the cash functionality and also want to be completely autonomous, without having any dependence on an instance administrator. If you need a larger configuration or to evolve this initial project, then you will have to migrate to a company-managed project in the future.