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 @Derek Fields _RightStar_

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!

[Derek Fields _RightStar_]

@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 @Derek Fields _RightStar_ , 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!

[Derek Fields _RightStar_]

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

[Malinga Goonetilleke]

Hi @Derek Fields _RightStar_

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.

[Derek Fields _RightStar_]

@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 @Derek Fields _RightStar_ 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]

@Derek Fields _RightStar_, 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.

[Derek Fields _RightStar_]

@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]

@Derek Fields _RightStar_, 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

[Margaret McKnight]

@Derek Fields _RightStar_ @Christian Beaulieu   Please weigh in for me.  I am working with a team to help pull all of the work into one place that they do.  The standard for the company is JSM so that is our starting point. HOWEVER, this team needs to use JIRA differently.  There are inputs from various places that need to show up in JIRA.  First, a Salesforce form will be used to submit a change request which will autopopulate a JIRA ticket for triage.  Those will be grouped by 'segment', i.e. business line.  In addition, there is another group that already has their own JIRA project where they manage all of their change requests.  On top of that, there are Salesforce projects that are being done both internally and externally and which also need to be brought together.  My #1 question is this... Should the Projects be a project pulled into the board or a board pulled into the overall project.  Second, Would it be better to have the segments in their own project or is managing them in their own epic a better path?  The majority of the team are not versed in JIRA so we are building for the future here.  In addition, these will be Scrum Boards and I will need to educate them in the ceremonies/process.  You guys are experts..  I am green so really want best practice for building sustainable and repeatable practice here.

[Derek Fields _RightStar_]

@Margaret McKnight - I am not going to be able to be of a lot of help. What you have indicated in your note is quite complex with a lot of different variables that need to be fleshed out before I could recommend a specific approach. This is what my company, RightStar, does every day; we work with Jira users like yourself to recommend an approach that addresses all of the issues that you raised as well as some that you haven't. You are welcome to reach out to me directly through our website.

[Margaret McKnight]

Thanks Derek!  Appreciate it.  I will share this with my client and see if they would like to leverage a conversation.  

[Carla Norman]

It would be amazing if this article was updated to include the new views that are available. Great resourse, thank you!

[Andrew Zabrzeski]

Hi @Derek Fields _RightStar_! Sorry for necroing an old thread, hope you don't mind.

We're just dipping our toes in JSM and currently thinking on a best approach. You raise some great points, but since I'm a noob, I'd love if you could comment on what we're looking for.

We currently utilise FreshService as a single point of contact for 99% of user issues. We also have shared mailbox for all Facilities-related issues.

We'd like to have a single point of contact to cover 100% of use cases, with users being able to send an email to one helpdesk address, for that to get converted into a JSM ticket. It seems like the multi-project approach wouldn't allow that, right? Do you see this as a valid reason to set up a single-project JSM or do you see some methods of working around this limitation that would make a multi-project setup work?

[Derek Fields _RightStar_]

@Andrew Zabrzeski Welcome to the Community and to Atlassian. You are going to love it here.

If you are set on having a single email address for all support issues, then you are going to be restricted not only to a single project, but to a single Request Type for all incoming tickets. When JSM receives the email, it will create a ticket with the subject line as the Summary and the body as the email as the description. This means that someone has to read every email, decide what is being requested and then update or copy/paste the information into the appropriate fields so that the ticket can be worked and so that you can get valuable analytics from your service desk.

There are better ways to handle incoming tickets than a single email, but they do require some retraining of your customers:

• The optimal approach is to train them to use your portal to submit their tickets. This has several advantages:
  • You can ask for all of the information that you need to address their request by creating different forms for different types of requests that guide the user to give you what you need.
  • You can auto-assign or queue tickets by request type so that they go directly to the person or team who is most likely to be able to handle the request
  • You can deflect tickets by creating a Knowledge Base that may answer many frequently asked requests
  • The customer can share their tickets with others if they want.
  • ... There are many more advantages
• A second good way is to use the new Virtual Assistant integration with Teams or Slack. This is especially effective for internal service desks where the entire organization is on a shared collaboration platform.
• There are other options, but the last one that I will mention is that you can now associate multiple email addresses with a single Service Desk. This will allow you to create email addresses that associate tickets with a specific subject area. You might have "incident@...", "question@...", etc. This might help to better segregate the tickets. However, it breaks the one-email-to-rule-them-all rule that you stated above.

I hope that this gives you something to think on.

[Andrew Zabrzeski]

Hi @Derek Fields _RightStar_! Thank you for your reply!

The single inbound address is not a problem for us so far - everything you mentioned is either already implemented or will be implemented, but our goal is to always have that "backup" email address for our users.

Also, from personal experience, it's just impossible for our users to handle categorisation of some problems on their own. A user will raise a request for access to a system, but during investigation we'll find out that they already have that access, but logging in fails due to an outage - prompting a change from Service Request to Incident Issue type.

Knowing that this kind of back-and-forth will be necessary (and that it's typical in IT), we're perfectly fine with having that single point of contact email address. I'm assuming I can set up triggered automation tasks to change Issue Types without Agents having to click through all the settings.

My primary concern is with queues. In systems like FreshService or ServiceNow we can create separate queues for separate teams without issue, even making it impossible for some agents from accessing tickets not in their team (say: HR's on/offboarding tickets probably shouldn't be visible to other departments). I know this would be fairly easy to set up with separate projects, but then we lose the "single point of contact" functionality. Is there a way we could handle this separation within a single project?

[Derek Fields _RightStar_]

@Andrew Zabrzeski Setting up separate queues within a single project that are team-focused or subject-oriented is straightforward. A queue is nothing more than a filter of tickets that meet some criteria. If you want to segregate your queues by Request Type, then create a queue that contains a set of Request Types that represent the work for a specific team. Or you can use the Team field to assign the ticket to a team and then have a queue that filters on tickets for that team. 

With respect to making tickets private, you can do that by using Issue Security. In Issue Security, you define a security level that restricts access to tickets with that security level to a specific set of users. For example, you could have an HR security level that would restrict those tickets on to agents in the HR group. Configure issue security schemes | Atlassian Support.

I hope this helps.

[Andrew Zabrzeski]

Thank you, @Derek Fields _RightStar_, that's super helpful!