Multiple Projects versus a Single Project in Jira Service Management

[#1]

One of the most common questions that we get from our larger clients is whether they should combine all of their Help Desk teams into a single project or have multiple projects. If you just want the TL;DR - the answer is almost always implement a project for each team. 

Before I lay out the reasons that having multiple projects is preferable, lets look at why some clients want to have a single service desk. The most common concern is that multiple projects leads to fragmentation and administration overhead as each project becomes specialized, doing their own thing. The thinking is that by forcing everyone into a single project, it will be much easier to enforce a single organization-wide approach to service desk management.

This concern is quite valid. We have been called into plenty of clients where they have allowed each project to "do their own thing" and the results are not pretty. There has been a fair amount of cost, both financial and cultural, in pulling everyone back into a coherent implementation model. 

The answer to this concern, though, is not to have a single project but to have a single set of schemes that are only modified through a centralized review process. When a team finds that they need to operate differently from the rest of the organization, let them make their  case and allow the Change Approval Board to determine whether the cost is worth the change. What may happen is that other teams recognize that the change is not a specialization but an overall improvement that everyone should adopt. The right answer to fragmentation is not to lean Jira but to implement a business process that introduces a thoughtful approach to Jira administration.

I promised my arguments in favor of multiple projects. 

Lets start by laying out some standard assumptions about how these different teams typically work:

1. Each team works largely independently of the others
2. There are occasions when a ticket opened for one team creates work for other teams
3. Access to tickets needs to be restricted to members of the specific work team
4. There is often a business requirement to have all users access a single portal regardless of which group they are submitting a ticket to
5. There is a often a business requirement that all groups utilize the same issue types and workflows to simplify administration
6. It is inevitable that there will be unavoidable specializations for certain groups
7. Each group tends to have their own email inbox for ticketing and communications (e.g. ithelp@xyz.com, hrhelp@xyz.com, financehelp@xyz.com)

Arguments in favor of multiple projects:

• Queues:
• When there is a single project, there tends to be a profusion of queues, one or two for each team. With multiple projects, each team will have their own set of queues, eliminating the need for a list of “team” queues that are of no value to other teams.
• Queues can then be focused on what the agent needs to see – typically: My Tickets, Unassigned Tickets, Recently Closed Tickets, etc.
• Shared Tickets
• When Team A needs Team B to perform some work, it fits the workflow model better if Team B has a linked issue rather than a subtask in Team A’s ticket. This resolves the problem that some of Team B’s workload is contained in Issues while others are contained in Subtasks. This way Team B’s workload is all represented by their own set of issues, not combined into issues that are associated with Team A.
• Issue Security:
• Issue security is more natural in a multi-project approach. While it is possible to use Issue Security to specialize the ticket access, it is more administration overhead when Jira provides a natural Permission scheme approach that can be shared across multiple projects.
• Portal:
• Jira implements a single Help Center, which is the landing page for all tickets. From there, the customer can select the group and then drill down to the specific request type
• Recent and Popular request types percolate to the top level.
• Request Types:
• Fewer request groups and request types on the project portal
• Having multiple projects gives you another level of hierarchy that can reduce the clutter on the list of Request Types
• SLAs:
• It will be easier to manage group-level SLAs if each team has their own project.
• Reports:
• It is easier to design reports specific to the team if the tickets in the project are specific to that group
• Performance:
• There will be improved performance if Jira isn’t looking through all of the tickets in the system when search a specific project.
• Incoming Emails:
• Each project can have its own incoming email address dedicated for its own emails. This will reduce the overhead of having to set up specialized mail handlers to handle the different email addresses.
• Each project would utilize the JSD email handler rather than needing to use a plugin like Email This Issue to “reimplement” the JSD email handling.
• Specialization:
• Eventually (if not immediately), there will be some requirement for specialization that will have valid and supported business reasons. Having the teams in their own projects will support this specialization

There you have it - a lengthy list of reasons that I argue for multiple projects.

Are there arguments that I have missed? Do you think that there are compelling reasons to pull all service desk teams into a single project? 

[John Staines]

Only comment is that at the Service Desk level, it makes more sense that the customer level reuests are in 1 project - eg Support, Incident, Service Request (ie L1). the L2 groups  indeed make sense to have linked projects

[Demis Estabridis]

I definitely agree with your approach @C_ Derek Fields

Nevertheless, I think it's problematic when the same user is part of more than one team and therefore has access to an equal number of projects. What is their MAIN view?

Queues (at least in Jira Service Management Cloud) have already a fixed filter for the current project. There is no way to change that (at least that I know). This restricts that within one project queue a user can see in one single view all his/her assigned tickets among different projects.

Can you suggest a solution to this case, different from the ones I have in mind?

• Using the dashboard and a filter to show a list (not very user friendly for becoming THE main view of an agent) 
• A marketplace app

Thanks!

[C_ Derek Fields]

@Demis Estabridis The problem of agents belonging to more than one team is real. Your two options are the only ones that I am aware of.

For one of my clients with that kind of issue, we use Cross-Project Queues to allow agents who belong to multiple helpdesks to see all of their issues.

We also encourage the use of individual dashboards in addition to queues as a way for an individual agents to quickly see everything of importance to them. An individualized dashboard becomes the main view for agents for whom the basic queues aren't sufficient. It takes some additional training, but they find that the expanded capabilities of a dashboard to provide a highly customized view that meets their unique needs is preferable to queues.

[Demis Estabridis]

Hi @C_ Derek Fields , thanks for your quick reply.

What you said here called my attention:

"For one of my clients with that kind of issue, we use Cross-Project Queues to allow agents who belong to multiple helpdesks to see all of their issues."

Was that on Server or Datacenter? I am using Cloud version and could not achieve that. For each project, the queues have a fixed filter I cannot change.

When editing a queue configuration:

In Jira Software I can do that, just by creating the filter exactly as I wanted. In Jira Service Management Cloud, I simply can't!

Thanks!

[C_ Derek Fields]

Take a look at Queues for Jira Service Management | Atlassian Marketplace - It runs on Cloud as well as DC.

[Malinga Goonetilleke]

Hi @C_ Derek Fields

Thank you for your post. We currently have multiple projects across multiple support teams/product areas, but are considering a single ‘Support’ project with a ‘Product Area’ field (which we can automate based on the issue details that we receive from ServiceNow - the platform we currently integrate Jira with) used to differentiate issues. Please see my comments in normal text for each of your arguments (in bold) below. Would be great to hear your thoughts.

• Queues:
  • When there is a single project, there tends to be a profusion of queues, one or two for each team. With multiple projects, each team will have their own set of queues, eliminating the need for a list of “team” queues that are of no value to other teams.
  • Queues can then be focused on what the agent needs to see – typically: My Tickets, Unassigned Tickets, Recently Closed Tickets, etc.

MG: With a single project and ‘Product Area’ field, could queues not be managed through filters and dashboards?

• Shared Tickets
  • When Team A needs Team B to perform some work, it fits the workflow model better if Team B has a linked issue rather than a subtask in Team A’s ticket. This resolves the problem that some of Team B’s workload is contained in Issues while others are contained in Subtasks. This way Team B’s workload is all represented by their own set of issues, not combined into issues that are associated with Team A.

MG: Instead of sub-tasks, we can clone, resetting the cloned issue’s Product Area to the other one that is involved, and these cloned issues will be linked to the original. This way Product Areas will still have their own set of issues. Could this be a suitable solution?

• Issue Security:
  • Issue security is more natural in a multi-project approach. While it is possible to use Issue Security to specialize the ticket access, it is more administration overhead when Jira provides a natural Permission scheme approach that can be shared across multiple projects.

MG: If the structure and hierarchy is consistent across Product Areas, then could we not set permissions at a role level and make exceptions on a case-by-case basis? But agree that variable team structures would mean more administrative overhead.

• Portal:
  • Jira implements a single Help Center, which is the landing page for all tickets. From there, the customer can select the group and then drill down to the specific request type
  • Recent and Popular request types percolate to the top level.

 MG: We use ServiceNow for customers, so this is not a requirement.

• Request Types:
  • Fewer request groups and request types on the project portal
  • Having multiple projects gives you another level of hierarchy that can reduce the clutter on the list of Request Types

MG: This is not applicable to us as of now.

• SLAs:
  • It will be easier to manage group-level SLAs if each team has their own project.

MG: SLAs are consistent across our teams. However, even if this is not the case, could this not be managed through filtering and the ‘Product Area’ field?

• Reports:
  • It is easier to design reports specific to the team if the tickets in the project are specific to that group

MG: Again, could this not be managed through filtering and the ‘Product Area’ field?

• Performance:
  • There will be improved performance if Jira isn’t looking through all of the tickets in the system when search a specific project.

MG: What type of search are you referring to? Doesn’t Jira already search through all tickets of all projects when you use the search function? If it is in relation to filters, then wouldn't filtering with respect to the 'Product Area' field have similar performance impacts in comparison to filtering with respect to projects?

• Incoming Emails:
  • Each project can have its own incoming email address dedicated for its own emails. This will reduce the overhead of having to set up specialized mail handlers to handle the different email addresses.
  • Each project would utilize the JSD email handler rather than needing to use a plugin like Email This Issue to “reimplement” the JSD email handling.

MG: Not too versed on this but perhaps the mail handlers is an acceptable compromise.

• Specialization:
  • Eventually (if not immediately), there will be some requirement for specialization that will have valid and supported business reasons. Having the teams in their own projects will support this specialization

MG: Agreed. However, as of now, our processes are mostly standard across Product Areas. Perhaps specialization needs can be accommodated within a single project in smart ways that does not impact other Product Areas, but agree that options can be fewer.

Overall, it still seems to me that a single project is more advantageous overall from an administrative point of view. It would also make it easier to implement standard process improvements, including those that involve integrations. Please let me know your thoughts. Thanks.

[C_ Derek Fields]

@Malinga Goonetilleke 

Welcome to the Community! Thank you for your lengthy and thoughtful response to my original post. I have returned the favor by answer each of your points. I have removed my original statement and prefaced my response with my initials (CDF) in bold

Thank you for your post. We currently have multiple projects across multiple support teams/product areas, but are considering a single ‘Support’ project with a ‘Product Area’ field (which we can automate based on the issue details that we receive from ServiceNow - the platform we currently integrate Jira with) used to differentiate issues. Please see my comments in normal text for each of your arguments (in bold) below. Would be great to hear your thoughts.

• Queues:

MG: With a single project and ‘Product Area’ field, could queues not be managed through filters and dashboards?

CDF: Queues can't be shown or hidden on a single project. While you can use Dashboards and Filters to create customized lists of tickets, you lose the functionality of queues, which is quite powerful for agents working all day on responding to and closing tickets. If you put all of your products into a single Project, you will likely end up with a proliferation of queues that are meaningless and don't help the agent to focus on what is most important.

As I read further down in your responses, it appears that you are using Jira Software, not Jira Service Management, so the entire discussion of queues is irrelevant.

• Shared Tickets

MG: Instead of sub-tasks, we can clone, resetting the cloned issue’s Product Area to the other one that is involved, and these cloned issues will be linked to the original. This way Product Areas will still have their own set of issues. Could this be a suitable solution?

CDF: Using cloning as part of your process suggests a problem with the process itself. It is more work to clone a ticket and you end up with information that isn't that useful to the second ticket. Ticket data and workflows should be focused on the needs of the agents who are responsible for closing the ticket. In addition, unless everyone uses the same workflow, you will end up with a lot of new Issue Types to allow each of the teams to run their work differently.

If you are using Jira Software, you are probably using Boards. Boards are more naturally attuned to a one-to-one Board-Project relationship. While it is absolutely possible to have multiple boards for a single project, this can get complicated quickly and creates more administrative overhead. 

• Issue Security:

MG: If the structure and hierarchy is consistent across Product Areas, then could we not set permissions at a role level and make exceptions on a case-by-case basis? But agree that variable team structures would mean more administrative overhead.

CDF: You will end up with a lot of different roles geared towards specific teams. If you want to secure access or functionality to specific team members for certain ticket types, you will need to use Issue Security to support it.

• Portal:

 MG: We use ServiceNow for customers, so this is not a requirement.

CDF: Sorry to hear that you use ServiceNow. Using JSM would give you more integration between the customer view and the internal view. 

• Request Types:

MG: This is not applicable to us as of now.

CDF: Understood

• SLAs:

MG: SLAs are consistent across our teams. However, even if this is not the case, could this not be managed through filtering and the ‘Product Area’ field?

CDF: SLAs are only relevant for Jira Service Management. Jira Software doesn't provide SLA functionality

• Reports:

MG: Again, could this not be managed through filtering and the ‘Product Area’ field?

CDF: Yes, but it is more effort

• Performance:

MG: What type of search are you referring to? Doesn’t Jira already search through all tickets of all projects when you use the search function? If it is in relation to filters, then wouldn't filtering with respect to the 'Product Area' field have similar performance impacts in comparison to filtering with respect to projects?

CDF: Jira has a sophisticated indexing system. If you specify a specific project, it will reduce the number of issues that it searches. Filtering on a large, single project will be slower than filtering on a single small project.

• Incoming Emails:
  • Each project can have its own incoming email address dedicated for its own emails. This will reduce the overhead of having to set up specialized mail handlers to handle the different email addresses.
  • Each project would utilize the JSD email handler rather than needing to use a plugin like Email This Issue to “reimplement” the JSD email handling.

MG: Not too versed on this but perhaps the mail handlers is an acceptable compromise.

CDF: This argument applies to JSM, not JSW. 

• Specialization:

MG: Agreed. However, as of now, our processes are mostly standard across Product Areas. Perhaps specialization needs can be accommodated within a single project in smart ways that does not impact other Product Areas, but agree that options can be fewer.

CDF: I completely agree with your general argument that you can implement everything that you need in a single project. Jira is incredibly flexible and a creative admin can solve problems in many different ways. My point is not that you CAN'T but that you SHOULDN'T. As I have pointed out, there are a lot of benefits to having multiple small projects over a single large project.

With respect to Jira Software, which what you seem to be using, it is much more natural for a team to work in its own project than to share a project with multiple teams. This provides each team with more autonomy and ability for team-level specialization. With the additional of Automation for Jira, each team can take more control of project-level automations without affecting other teams.

You mention that you think that a single project would reduce administrative overhead. In my experience, it actually increases it because of the need to implement special fields like a "Product" field to separate issues into different teams when the same thing can be implemented naturally using separate projects. As different teams request specializations to support their team needs, the admins need to create unnatural implementations like cloning to support those needs.

I am interested in your experience with Jira. Does it really help you to put all of your teams into a single project? What benefits have you realized?

[Malinga Goonetilleke]

Thank you @C_ Derek Fields for the detailed response. Currently, we have multiple projects across the different support teams/product areas, and we haven't yet decided on moving towards a single ‘Support’ project.

[Wyatt Best]

@C_ Derek Fields, thank you for this excellent post. I'm evaluating JSM for an MSP-type scenario and wondering if we should create one project per client organization.

Jira implements a single Help Center, which is the landing page for all tickets. From there, the customer can select the group and then drill down to the specific request type

Wouldn't this expose our customer list to the public? It's not unthinkable, but it does sound kinda awkward.

[C_ Derek Fields]

@Wyatt Best Welcome to the community. Your customers will only see the portals/projects to which to you give them access. We have several clients who implement what you want. We set up a project for each of their customers. Within that project, we restrict access only to users who are explicitly given access to that project. When the end-user comes to the Help Center, they only see the project(s) that they have been authorized to see. They won't see any other projects or customers.

I hope that helps.

[Wyatt Best]

@C_ Derek Fields, thank you, that is helpful!

[Christian Beaulieu]

@C_ Derek Fields I would also add Auditing as a reason for using multiple projects. Keeping track of data based on departments and changes made here and there will be more easily reference-able and logged to some degree in Audit Logs and on the Jira Issue History. Good from a scalability perspective