Best Jira Practices for tracking hardware bugs, repairs, mods, etc.

Question

My company currently uses Jira in our BUs with projects broken down at the team level for tracking and organizing work. Most of these teams support development of a single system, My team is more of a support role for lab testing of these various systems. Besides designing and maintaining our own various products, my team also maintains multiple labs, each with multiple systems that sometimes need repairs or modification. I had planned on setting up a single project with Epics for each system to help track bugs, repairs, and modifications. But after looking at the forums, I've seen multiple recommendations to create a separate project for each system. In our case, I would likely have to create 30+ projects just for the systems we maintain and possibly 40+ projects for systems maintained by other system level teams. 70+ projects seems like a lot of redundancy, For the use case that we were looking for (bug reporting, system repair, modification, etc), is there really an advantage to setting up multiple projects vs. a single project with every system broken down as a component or Epic?

Bryan Roesner · Answer

1. These are large scale computer environments, hardware, firmware, and software. Custom systems, lots of integration across multiple functions. My objectives are:

A. Provide a forum to report and track bugs, and schedule repairs. Its very easy to lose track of a bug because repairs need to be postponed due to testing schedules. If its not high priority, just a minor issue, these can be postponed for months or even years.

B. Provide a history of repairs and modifications. Often times, things are fixed on the fly and not documented well, or the documentation is lost and someone doesn't know why the fix is in place. Having a history of fixes, and common problems, accessible and searchable across multiple teams would break some of the silos of information that exist between groups.

2. Each systems can have dozens of components, but I don't want to track them down to the component level, just the system level. I would understand if I wanted to track each component, how a individual project for each system would benefit.

3. Yes, We are currently set up that the teams all have read access to other projects. I'm hoping that all the teams can access and report bugs in the systems. I also want them to be able to search a system to see past repairs, mods, etc.

Sachin Dhamale_o1c5zi · Answer

@Bryan Roesner

As per your requirement I can see you have multiple teams working on multiple system and that system might have bugs, need to modify and repair.

I have some question

1. Can you explain what exactly system is? Is it a software module?

2. How big each system will be? in terms of number of bugs, modify and repairs required for single system?

- If system is big and have more number of bugs, modify and repairs then its Epic will not be good option. Go with separate project.

3. Can other team able to see or access the system of other teams? do you have access restriction on each team in term of handling the system?

If you have access restriction on teams for systems then separate project will be good option. Because it will be better to manage the security and access level permissions.

Hope this will help you.

Let me know if you have any queries.