what are the pro and cons about dividing a projet into several JIRA projects ?

[ribas]

Using our precedent tool, we were used to have one database for one projet and we were able to have one attribute that was the "domain". This domain was used to "specialize" some values of list values of several attributes. (for instance the detected_in, concluded_in attributes that are versions attributes. but not only)

This way, in one database we were able to store différents workflow with minor differences. This was used to store different jobs tickets in the same database (board team, FPGA team, SW team, etc.). Each team had it's own specific values for some lists. Also we were able to use the domain to divide also the kind of delivery inside one job. For instance board team could work on board1, board2, board3 and we used the domain to segregate these deliveries.

Using JIRA it is not easy to do, we could do using scripts, etc.

So we are thinking about using differents JIRA projects for one projet. One JIRA project for FPGA team, one JIRA project for SW team, etc.

what are the pro and cons of such a division in several JIRA projects ? + is there a clever way to do this ?

Here is what we have in mind :

Several projets :

- better for the right management, more precise but could be painfull for administration if a lot of people need to have access in all jira projects.

- more difficult to update because if one attribute need to have its value list updated it need to be done in several jira project ?

- the list of project could become huge after several years for a user because for each projet it could be possible for a user to have access to 1,2,3 jira projects instead of one.

is there an impact for dashboard, report and KPI if the project is divided in several jira projects ? or is it completely transparent ?

[Deniz Oğuz - The Starware]

Hi,

Using multiple projects requires higher administrative effort of course. But it has higher flexibility if you need it. One huge downside of using a single project and using components to divide it into smaller parts is version management. In Jira, versions and components are independently created. That means any version becomes selectable for any component when creating issues. But in practice not every version can be valid for every component. For example, you may have hv-1.0.0 version which is only valid for your PCB component and not valid for firmware component. 

Our app, Configuration Management Toolkit provides features to force this separation and it contains a lot of other features which makes this kind of strict software configuration management easier. It has subprojects, subcomponents, bundles, component versions, version hierarchy features for managing a complex Jira project. You can check its user manual for more details. Even if you go with separate projects approach, our subprojects feature will help you to create JQLs depending on project hierarchy. 

[ribas]

thanks, if I use separated projet, will I have some difficulties to link ticket from one project to another ?

[ribas]

Thanks a lot, this is a very detailled answer we will have a discussion about it and I will come back for further questions are needed.

as far as we have understood, project component is not suitable for our need because there is no way to have different list value depending on the name of the component (except for the component version)

we need to look more about "labels"

[Deniz Oğuz - The Starware]

Project components are a lot useful than labels; I think. Anyone can create a labels. Soon you will have labels like FPGA, FFPGA, FPGA_V1 etc. People will create them as they want. Components have a fix name, a lead. Only project admin can create/edit/delete components. 

[ribas]

your great answer has been deleted, I don't know why... I add it again :

Dividing your workflow into multiple JIRA projects to cater to different teams (like FPGA, SW, Board Team, etc.) can be both beneficial and challenging depending on your organization's needs, scale, and how you manage these projects. Here's a breakdown of the pros and cons, along with some insight on how it could impact dashboards, reports, and KPIs, and suggestions for potentially smarter approaches:

Pros

1. Improved Access Control: Having separate projects allows for more granular access control and permissions, making it easier to manage who has access to what information. This can enhance security and ensure that team members only see the issues and workflows relevant to them.
2. Customized Workflows: Each team can have its own customized workflow that matches its specific process without interfering with other teams' workflows. This customization can lead to more efficient work processes tailored to the unique needs of each team.
3. Focused Reporting: Teams can generate reports that are specifically relevant to their projects, which can lead to more accurate and meaningful insights for each team's performance, challenges, and outcomes.

Cons

1. Increased Administration Overhead: Managing multiple projects means more setup time, more configurations to maintain, and potentially more complexity in managing user permissions across projects. This can become particularly cumbersome if there are frequent changes in teams or processes.
2. Difficulty in Cross-Team Collaboration: If tasks frequently require collaboration across teams, managing these interactions across multiple projects can be challenging. It may lead to communication gaps and make it harder to track the progress of interconnected tasks.
3. Duplication of Effort: Updating shared components, such as custom fields or workflows, needs to be done multiple times across projects. This can lead to inconsistencies if not managed carefully and increase the administrative burden.
4. Impact on Dashboards and Reporting: While JIRA does allow for cross-project dashboards and reporting, setting these up and maintaining them can be more complex when data is spread across multiple projects. It might require more advanced JQL (JIRA Query Language) skills or even external tools to aggregate data in a meaningful way.

Mitigating the Cons

• Use of Shared Configurations: Where possible, use shared configurations, like issue types, workflows, or custom fields, across projects to reduce the overhead in updating and maintaining them.
• Advanced Permissions Setup: Leverage JIRA's permission schemes to manage access at a granular level within a project. This can sometimes achieve the necessary access control without needing to split into multiple projects.
• Cross-Project Reporting Tools: Utilize JIRA’s cross-project reporting capabilities or third-party tools that can aggregate data from multiple projects for dashboards and KPIs. This can help maintain visibility across projects without compromising the benefits of having separate projects.
• Project Categories: Use project categories to organize projects in JIRA. This can help users navigate the potentially large number of projects more easily and find the projects relevant to them.

Clever Approaches

• Project Components or Labels: Consider using components or labels within a single JIRA project to differentiate between teams or domains. This approach can maintain some level of segregation without the drawbacks of multiple projects.
• Hybrid Model: For some organizations, a hybrid model works best, where a single project is used for overarching project management, but specialized tasks or workflows are managed in dedicated projects. This can strike a balance between unified oversight and specialized management.