How to set ut jira projects for multiple project managers and multiple teams with different workflows

Question

I work at a relatively small tech company. We have a cloud team, an embedded/electronics team, and a PLC team. We do projects towards several customers which are regarded as separate projects.

I try to puzzle out how to best create a jira environment which works for everyone.

So far I see it like this. Create a new jira project for each customer project. This is where the project manager lives. Work a lot with epics etc to get the overview of the project. It can contain both tasks for embedded team and cloud team, or perhaps plc team. This would be great for the project manager so that he can get a limited view of his work.

Then create 3 separate jira projects for developers: cloud, embedded and PLC. Create the specific tasks for customer projects here but make sure to link all work to epics in jira customer projects.

Is there another way of doing it? I thought of only creating projects for cloud, embedded and PLC and then use labels to link to a customer project. But that would then make it harder for the PMs to keep the project together in one place. Where to put the epics that span over the teams/disciplines?

TLDR: What I want is:

Project managers can see and plan his project in 1 space
Developer teams can see their work in 1 place (the board containing tasks from several projects)
Teams can have their own workflows
Prepare for expansion (more teams in the future).

Is there a "best practice" regarding this? All tips are welcome

So I am responsible for setting up the task management system and I chose Jira since I have some experience with it from previous dev jobs.

My first move was to set up the environment for the cloud team since they are the largest group of people. Set up several different projects and called them "Customer x cloud", "customer y cloud" etc. Then had a "Planning project" that hosted the board and filtered on all the different projects. So the teams can have their board and see which tasks are most prioritized etc.

But now Embedded and PLC also needs to enter the stage. I dont want to create another set of projects named "Customer x PLC", "Customer X embedded" cause alot of work and alot of projects. But I also don't want to simply create "Embedded" project and "PLC" project because I believe that the project managers won't be able to find/manage their work/sprints together with other PMs.

Another option would be to use "Plans" but I don't find it very intuitive working with multiple projects to be fair.

Any input is greatly appreciated.

Answer 1

I am not sure about "best practices", but here is one way you can set it up.

• You create a Jira project per customer project. This will hold all the tickets, on all the levels, that are related to that customer's project.
• The Jira projects have a loosely defined workflow. The states that a ticket can be in are defined (according to the most elaborate workflow used by any of the teams), but there are no restrictions on which transitions are allowed. This makes the developers responsible for following the workflow that they agreed upon within their team/discipline. It would help if common stages in the various workflows have the same name.
• You use the Component, Labels, Team, etc. fields in Jira to indicate which discipline and/or team the ticket relates to.
• For each team you create a board based on a filter query that selects the tickets relevant to that team from multiple Jira projects. These boards should have columns according to the workflow stages used by that team to assist them in following the workflow.

Answer 2

In Jira, you can create custom issue types and assign different workflows to them in the same Jira project. So, you can;

1. Create projects for projects
2. Define custom issue types for different team tasks
3. Define workflows that align with the teams' process
4. Assign workflows with the corresponding issue types (https://support.atlassian.com/jira-service-management-cloud/docs/create-a-new-workflow-for-an-existing-issue-type/)

This will help your issues stay structured in a project and multiple teams can interact with their issues with their process.