Jira Service Management for multiple clients (with multiple projects for each client)

[Vasco Patarata]

Hi, Jira community,

Before anything, I am new to Jira, only use it as a customer in the IT support of my company.

We are starting to use Jira Service Management to implement a Client Service Desk in my company.

Starting on the considerations of our reality:

• We do projects on multiple clients (30+ and growing) - usually, we come back and do more projects with the same client.
• Our projects often end with deploying customized and specialized tools on the client-side (web applications, for instance).
• We then need to provide customer support to those tools, so we have lots of different support streams and a growing trend for the future.
• We currently perform support via ad-hoc communication with our clients.
• We do not have a specialized support team, each support stream can have its specific allocated team.

Based on these considerations we decided that it was time to implement a more structured and centralized support management system and we decided to try Jira Service Management as it was already being used internally.

To start with our implementation we opted to instantiate clients as Jira Service Management projects (using the Components feature to split our different projects with the same client inside the JSM project).

Our main question is how to manage all of these projects for different clients with a certain degree of standardization and centralized structure, but still allow customization for that specific client needs. Did you ever face this use case? How do you recommend handling it?

Our current view on this subject consists of the following points:

• We are creating a Jira Service Management Template with the main structure for support already built. Our idea was to replicate this structure as new clients with support needs arise.
• We know that new JSM projects can be created replicating the Template configuration. However, this option makes all the screens, issues, and workflow schemes shared across JSM projects. This implies that a change in a scheme would affect all the JSM projects, so we lose the possibility of customization inside each client.
• The other option is to create a different scheme for each client. However, in this case, we lose the possibility of making changes at the centralized level, to affect all the client's JSM projects, having to replicate the changes in each different scheme.

Is there a way of having a hybrid approach, with a centralized structure but project-specific customizations? Having full customization without any centralization will be a nightmare for managing when the number of clients grows and we need to make global changes to the structure of our support projects.

Thank you very much in advance for your help and hope to understand better what is the Jira way of handling this use case.

Best regards,

Vasco

[Andrea Novelo]

We have exactly the same issue. It's a nightmare and im looking for integration options. Most of  the solutions I have find are mainly for several Proyects but only across a specific client. 

I will let you know if I find something useful. 

Thank you. 

[Tom Rogers]

We use a single instance of Jira Cloud and set up each client as a project, then using components we can create a board for each sub project for that client. For example, we may work with Client X (Project) and run a website (component) and social media campaign (component). Then we setup two boards, one for website and one for social media. In the JQL filter we can then filter all the tickets by component. This displays them in the relevant kanban board under the client (project). This way you can view all tickets for a client and filter by sub project. Prety sure this isn't the best way to do this, but works for us. Hopefully that helps. 

You can also Clone tickets if you need templates of content to reuse and then move it into other projects.

[Matthew Flood]

Currently in the process of reviewing this exact topic.

@Vasco Patarata, I would be interested in understanding...

1. What you ultimately decided to implement?
2. How it is working out?
3. Any key insights you would consider important, given what you have learned from the experience

[Vasco Patarata]

Hello, @Matthew Flood

1. We ended up implementing a project based approach, where each project (even if it is on the same client) has its own JSM project. We ended up doing it this way because we can do projects with completely different teams, with no relationship, even if they are in the same client (this is especially true when we are talking about big clients such as multinational companies)

Also, our projects can consist of several small modules, more suited to the use of the "Components" feature so we can leverage it without using it artificially for projects inside a client.

We have a big number of projects to manage, but it was the only way it felt natural to organize. The trade-off we decided to have was having a very rigid structure so the big number of projects is manageable in terms of configurations and changes.

2. It is working out fine since we opted to use a very rigid structure with little possibility of customization between clients/projects, so we can use the same configuration schemes for all of them making the global changes easy to implement. Otherwise it would be a configuration nightmare.

I think it would be very useful to have an additional level of project grouping in Jira, where you could create Clients (who would share some configurations) and then JSM projects inside the Clients, making the organization much more natural and easy.

3.

--> Spend your energy in building a project structure that makes sense for your clients and for your business covering all the use cases (that should be listed before using the support teams knowledge)

--> Implement in one client, get feedback, improve and iterate

--> Close a satisfactory structure so you can extend it to all of the projects

--> Avoid at all costs having little different customizations for your different clients, otherwise it becomes very difficult to manage the whole set of configuration schemes and to perform global changes to your structure

IMPORTANT SIDE NOTE:

The Jira client portal is the main source of problems and complains by our clients, since the customization possibilities are very small and we can pass very little information to the customer through the portal.

A simple example is that it is not possible to show custom fields in the Portal or fields such as the Time Estimate or Worked Logged Hours. Being a company that truly believes in and is built on transparency, it seems ridiculous that such a simple use case cannot be achieved without using customized (and paid) Jira add-ons.

We had to build a different process around Jira to pass this detailed information to our clients without using the portal.