How to classify JIRA Projects

Question

JIRA is very open and that is great, but our company is trying to determine the best practices in how to classify JIRA projects. Should we categorize JIRA projects as individual software Products, such as a website or an application, or should we set up JIRA projects as if they were corporate Initiatives similar to traditional IT Projects.  We see pros and cons to both but I am curious as to how other companies handle this.  Setting up as a software product makes sense from keeping a backlog for a specific application and maintaining documentation for releases with the Fix Version/Affects Version. But setting up a JIRA Project as a corporate initiative that might span several software applications also makes sense to keep track of all the work/issues in one place.  Are there any recommendations on how to get the best of both worlds using JIRA projects?

unknown · Answer

One of the biggest JIRA instances that I support (1,300 different JIRA Projects with 17,000 active users daily) have used it for both.

Whenever there is a new project in this company (e.g. they need a new website specific for a product), they will create a JIRA project for it. Create Epics (High Level Requirements), software versions, Components (Database, UI, Security). We have created 2 set of schemes to support this kind setup, "Agile Scheme" and "SDLC Scheme" so they will have more flexibility.

For Tracking "Company Initiatives", we created a totally separate set of schemes called "General Scheme" on which we try to make it as "general as possible" so they can use it virtually for anything they like it to be (tracking cost avoidance, finances, expenses, status report, anything that can be displayed on a KANBAN).

So I guess my choice here is both of them.