Service Desk Project Organization

[Jodi Chase]

Greetings!

We are new to Jira Service Desk, have been using Jira for software development project management for a few months and are ready to start rolling out some help desks. Our department supports a number of other department's at our University with three main areas - Floor Plans & GIS, Application Support (purchased applications) and Web Development (both websites and custom-built applications).  I head up the Web Development side and that is what I'm trying to create SD projects for.

I am struggling to find the best way to organize our Service Desks. We could create one SD project for each application, or create one SD project for all of our applications.  I see pros and cons to doing it each way. The team is leaning towards one giant SD project with lots of groups (group per app). We have 8-10 web apps we support and another 6 (and growing) public websites. In addition, we do mobile device management and SharePoint Online support.

Our support team (on the web dev side) is small, currently there are only 3 of us. We feel that going to 10+ different service desk projects to look at queues would be annoying and would rather it was all in one. Are there drawbacks to organizing it this way?  Thanks for any advice!

[Jack Brickey]

There is a lot to consider when setting up JSD. However, I would suggest one guiding rule. Align projects to agents. If you have 3 agents and they collectively work on issues from various areas then create one project. If another group of agents work on disparate issues then create a project for them.

Generally I would create multiple projects: Web Dev, IT, Facilities, etc. They will all appear in the same portal but the user can select which 'project' and request type they want. The reason I would go this route is the following:

• it is very possible that you will want to have different workflows under the same issue type name, e.g. Task.
• you can keep things clean and have different project admins and not worry about stepping on each other's toes or debating the schemes, screens, etc.
• components will remain cleaner
• queues will be more straightforward and you won't mix agents into one project where they all see the other project queues

hope that helps?

[Ginny Williams]

Hi Jodi,

We migrated from Service Now to JIRA Service Desk last year and decided to take both approaches, based on synergy, reporting and workflows.

For all IT teams, we decided to use a single Service Desk project and create separate queues based on teams and regions - so NOC, Windows, Application Support, APAC, NA, EU, Network, etc. all have their own queues.  Email sent to the general service desk address goes into the default queue and our Level I team does initial triage or moves it into a specific Level II queue.  Each team (Windows, Network, Application Support) also have their own email addresses, and email sent directly to them creates an issue in their queue.  This configuration also allows us to report on teams with the same goal - support our end users and customers.

In Phase 2 we will implement different Service Desk project for other workflows - Purchasing, HR, and Facilities are under consideration.

Finally, development teams use JIRA Software projects, not Service Desk, so they can take advantage of the built-in Agile features.  This might be useful for your Web Dev team.

I hope this helps!

Giny

[Brian Mertens]

Hi Ginny,

Thank you for sharing your approach.  This is helpful as we implement JIRA Service Desk at our organization.

I have a follow-up question about your comment, "[e]ach team (Windows, Network, Application Support) also have their own email addresses, and email sent directly to them creates an issue in their queue."  My understanding is that each Service Desk project can only have one intake email address configured.  So how are you creating separate issues in different queues within the same project using multiple email addresses?

Thanks!

Brian