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:
- Each team works largely independently of the others
- There are occasions when a ticket opened for one team creates work for other teams
- Access to tickets needs to be restricted to members of the specific work team
- There is often a business requirement to have all users access a single portal regardless of which group they are submitting a ticket to
- There is a often a business requirement that all groups utilize the same issue types and workflows to simplify administration
- It is inevitable that there will be unavoidable specializations for certain groups
- 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?
11 comments