Company or team project when working with same codebase and/or regulatory requirements

Question

Hi,

Looking for some advice/best practices on a project setup.

We recently moved to Jira cloud with no real plan on the setup, and it ended up with most teams creating “team-based” variants, due to its ease of use etc.

Some things we need to consider is the following:

* Most teams work on the same codebase
* We need to follow regulations and have decided to make use of custom fields and rules to avoid too much external documentation (All teams are affected by the regulations)
* We use Zephyr for test case management.
* The release is synced between all the teams for the same codebase.
* Sub-companies that are moving to our Jira would in some cases also need to follow said regulations and setup

Right now, it seems that company structure is the way to go. From my understanding you can create a global configuration that the projects can use, and instead use several boards within the projects for the same codebase, while allowing flexibility on the team’s respective board’s workflow?

But since we are new to Team-based projects, is there something we are missing or can we achieve the same results as company type?

My gut feeling is that it will be very hard to maintain due to custom fields, and that zephyr test are not gathered in one place?

Thank you

Christoffer

Ste Wright · Accepted Answer

Hi @Christoffer Freij

Your gut feeling is correct - from what you've described, Company-managed Projects are the way to go.

Whilst I appreciate Team-managed Projects are great for their simple setup and ease of customisation - I think these are great for single, isolated teams/projects that don't need any specific governance.

Once you need that governance and cross-team management - I'd use Company-managed so you can allow custom fields/screens, statuses/workflows, etc to be shared across multiple teams, significantly reducing administrative burden - alongside central management of code repositories, Zephyr, etc.

It's not just keeping the fields accurate - it's also the fact that...

* Fields, statuses, etc in Team-managed Projects are all treated as separate fields overall - so using them in JQL, APIs, etc, could become overly complex
* You cannot stop Project Admins making changes - even if you set the standard centrally
* To update the Workflows, Screens, etc - you'd need to update each Project one at a time

Company-managed Projects shouldn't stop you offering teams some flexibility though - for example...

* Boards: Each team can have their own board, where they set the filters, colours, etc.
* Project: You could still have each team own their own Project, so they have control over components, releases, etc.
* Flexible Configuration: Platform Governance could be implemented to decide what teams can or cannot change - for example, certain fields might need to be on every screen, but perhaps the team can then decide what other custom fields they get to have?

Let us know what you think!

Ste