Using Project Categories to keep Jira organized

[#1]

Howdy y'all.

I though I'd share what we did at one company to try to simplify and keep schemas organized. We used Project Category along with pre-defined simple standard naming convention to organize our work. Inherently, Project Category has no super powers except making it easier to search across multiple projects of the same sort/flavor. 

So firstly, we chose a descriptive name for our categories. For example, in the Customer Service part, we chose:

- Corp Customer Service Gold
- Corp Customer Service Silver
- Corp Customer Service Standard

And for internal, we have a few categories. For example:

- Corp Business Support
- Corp Cost Center Projects
- Corp Software Development

Then we decided that all schemas would have a prefix referring to the Project Category that particular schema was to be used for. As an example, if I was creating the schema for the Corp Customer Service Silver category, I would name them:

- Corp Customer Service Silver Issue Type Scheme
- Corp Customer Service Silver Workflow Scheme
   - Corp Customer Service Silver Incident Workflow
   - Corp Customer Service Silver Change & Release Workflow
- Corp Customer Service Silver Issue Type Screen Scheme
- Corp Customer Service Silver Field Configuration Scheme
   - Corp Customer Service Silver Incident Field Configuration
- etc.

This makes it a lot easier to see what Project Category my changes are going to affect. It also makes it much easier to apply the right schemas to the project, for example when a customer moves from a Silver status to a Gold status.

What this approach does also is helping the Jira admin place a new project. I.e. when a business unit asks for a new project, the Jira admin is right off the bat thinking where he/she is going to place this new project. This has also made it easier for the business units to talk "Jira jargon" with the Jira admins because they often say; "I need a project like this one" and the Jira admin can then verify the use case of the new project by looking at the Project Category of that referenced project.

This particular Jira instance has over 1850 projects and just about 1.5 million issues so it was important to keep things under control. This approach has worked very well even though it is not flawless :)

Hope this helps someone :)
KGM

[Sean]

Thanks for the Share it is so funny that this was on my mind also.

I just launched a new Jira Instance to test out ideas like this out in the cloud.

How have you managed to make project specific customization?

In example if a 'Corp Customer Service Silver Incident Workflow' need a new status?

I currently struggle with copy's of workflows and that gets messy quick.

With this next plan I was thinking of adding new Statuses, then making them available to only Project level groups ' Conditional validator' &  I hope this work, 'untested', but solid theory since similar things worked in the past.

[Dave Liao]

@Kristján Geir Mathiesen - thanks for sharing! I've been trying to find better ways to use Project Category to make my life (as an admin) easier, and the lives of my users.

Did you know that you can query Jira for issues by Project Category ("category")? That creates interesting reporting opportunities. 📈

Certain third-party Marketplace add-ons also let you filter projects by one or more Project Categories, which can help with discoverability of projects in your Jira instance.

[Kristján Geir Mathiesen]

@Dave Liao  Yes! We use the "category" in a lot of our queries. That is the added bonus of using Project Categories. For example, there are about 900 projects in the 'Corp Customer Service Silver' category and the help desk is just interested in certain types of issues (they don't care from which project). So we have an "Access" issue type and the access group monitors that one, etc.

The "category" JQL also comes in handy if you have a 3rd party plugin for SLA, when differentiating between SLA times. Good stuff!

[Kristján Geir Mathiesen]

@Sean  that is funny :) We must have been on the same wavelength...

As I said, this approach is not flawless. I should have added the third step/element in my article: discipline. It takes discipline to stick to this approach and often we have to say "No". The downside of this approach is that all incidents in Silver projects will be using the same 'Corp Customer Service Silver Incident Workflow'. If we change 'Corp Customer Service Silver Incident Workflow' , then that change will be reflected in all 900 projects. So we tend to discuss changes quite a bit and weigh the pros and cons.

Some changes can be shown only in certain projects though. For example, we have some transitions in connections with certain service. That service is only purchased by a handful of clients. So we conditioned the transition to a certain Project Role under 'Conditions'. Then we would populate that role for those handful of clients. Things like that. But Statuses are for sure harder.

My advice is to start small and lean. Try to get away with as few statuses as you can. If all else fails, add more later :)

HTH,
KGM

[Dave Liao]

@Kristján Geir Mathiesen - I love the idea of using project categories to help with cross-project reporting! ⚡ #jirahacks

[Taranjeet Singh]

@Kristján Geir Mathiesen Thank you for sharing this great idea and implementation specifics of using "Project Category" for organizing project types and their configuration schemes. For sure, it needs the additional element of "discipline" on part of t a Jira admin to maintain it without getting it messy. But it is definitely useful for reporting purposes as well.

[Kristján Geir Mathiesen]

Thank you, @Taranjeet Singh  True that! A great system is made out of:

• Process
• People
• Technology

The "people" element is often the hardest one to get in line/under control...

[Alshafaraz Gazi]

This is a beauty. For a novice admin like myself, it has been a learning curve to start with JIRA. My mission is to move my company's projects, service desk, customer support and so on to JIRA.

Just wanted to know the difference between the two workflows under the Workflow Scheme:

  - Corp Customer Service Silver Incident Workflow
   - Corp Customer Service Silver Change & Release Workflow

[Kristján Geir Mathiesen]

Thanks, @Alshafaraz Gazi  The Incident workflow is for things "that worked yesterday but doesn't work today" situations. The other is used for formal change, which needs reviewing and approval. HTH, KGM

[Alshafaraz Gazi]

Cool @Kristján Geir Mathiesen 

So different projects can only use these different workflows right.. Thanks..

[Kristján Geir Mathiesen]

Hi again @Alshafaraz Gazi 

Actually, you can map different workflows to different Issue Type. It is a one to one mapping. So if you have 4 workflows in your project, then you can have 4 different workflows, if you want to.

The Issue Type Scheme is where you decide how many Issue Types you have in your project.

HTH,
KGM

[Alshafaraz Gazi]

@Kristján Geir Mathiesen thanks mate.