Defining the Scope of a Jira Project

[toddparson]

Hi I work in a centralized corporate support role for the IT departments across several BU's in my company. We're looking to expose our Jira helpdesk so it can be used by any of the areas in other BU's. To that end, we'll likely have a Jira administrator for each team and within that team, there may be certain issues that get routed to a subset of the team and other issues that get routed to another subset.

For example, my team supports products X, Y, and Z for all the IT areas at my company. 2 people support X, 3 people support Y, and then there's some overlap for supporting product Z. Another BU would like to be added to our Jira instance and they have a team that supports frontend issues and a another team that supports backend issues.

What would be the best approach to setting up Jira Projects with this support model in mind? Should I create a project for every subset of people supporting the same thing (i.e. one project for Product X and another project for Product Y) or should I create a project for every IT team (i.e. one project for BU #1 and another project for BU #2)? I was originally planning on the latter but when I started thinking about it, some of these concerns came up: What happens if support for a product switches teams? How do we manage the workflow for an issue with a product that can only be handled by a few team members? Additionally, the version concept in Jira cannot be leveraged since versions are tied to projects (Version 1.0 would apply to all products in the project, regardless of their version/release schedule)

On the flip side, I didn't know if there was a Jira project limit, if too many projects would cause confusion for people submitting tickets as well as administrators, etc.

Long story short, I was wondering how most enterprises define their projects in Jira. Do you usually tie a project to a product/application or do you usually tie it to a support team?

Thanks in advance!

[Dieter]

I'd suggest to create one support project since that way your customers have a single point of contact. The different products can be represented by components. there exist some plugins to make sure your customer can select just one product. If you choose components you can create nice two diemsional statistics with the product being one axis. Now talking a out the drawback of a single project, which is security. This can be solved using one security level per project. E.g the security level for your product x would consist of a group representing your team and some other users. There are a lot of possible options definimg the product responsibility using security levels. You could even dynamically add users and groups to the product security level by including a user custom field in the security level. The security level of course must dynamically set in the create transition depending on the selected component (product).e.g. I do that using groovy. You should exclude the component field from any edit screen. If you want to allow your supporters to change the product this must be done in a transition which of course should run the same logic as the create transition. This is just a sketch of how we address support projects. Please let me know the way you chose.

[toddparson]

Radu, I'm not sure I follow your advice. I'm interested in how projects are typically aligned with support teams and products. Does each product/tool that's supported get its own Jira project or does each support team (that supports one or more products/tools) get its own Jira project? For example, should I setup a RAD project, a ClearCase project, and a WebSphere project or should I set up a Developer Tool Support project (for RAD/ClearCase issues) and a Runtime project (for WebSphere issues)? I think the former makes more sense so you can define different workflows, switch products/tools between teams, and purge issues related to old versions of a product but when you start factoring in several tools across several support teams, it seems like it could get pretty hairy.

[Radu Dumitriu]

I've seen this question before. The term "project" is external to Jira, it is something that belongs to the outside world, and I do not understand why people are having trouble internalizing this simple fact.

Obviously you have "Support for X", "Support for Y", etc.