Moving from single BIG JIRA Project to multiple JIRA Projects

[ambujp]

We are considering to move from single BIG JIRA Project (all teams using same workflow, ticket types etc) to Team vise JIRA Projects (where they will be given authority to change workflow which is aligned to their development flow). 

Anyone here experience with this kind of task. As you can imagine, this will have company wide impact, so I want to hear from experts and experienced guys out here. 

I am specially interested in how do we manage workflow changes, if teams want to use a template to start with and then want to tweak a bit for their usage. Or there are some team who might want to use common workflow to start with, but later they might want to change workflow to something else. 

[Ste Wright · Accepted solution]

Hi @ambujp 

I find in this instance it is useful to consider not just how teams will work, but also how you'll report on team progress as a whole.

There are a few options here (in Classic):

1. Simplified Workflow: Make each workflow a simplified workflow - allow Project/Board Admins access to modify the workflow from their board. Simplified workflows cannot have screens, transitional properties or transition limitations (i.e all-to-all activated). Project/Board Admins can also add new statuses without a Jira Admin.
2. Project Admin Workflow: Create a unique workflow per project, so a Project Admin (with Extended Admin permissions) can manage it themselves. This will allow a Project Admin to add/remove statuses and transitions - but they cannot create new statuses. You can also (as a Jira Admin) add screens / transitional properties - such as the Resolution Screen - if you want common practices across all workflows.
3. Centralised Workflows: Just because each project has its own workflow, doesn't mean you can't have workflows shared across multiple projects. You could start all unique projects off with a standard workflow, and then provide new workflows / modifications based on team feedback.

I tend to float between (2) and (3) - depending on the size of the business (for companies with 1-3 teams Simplified can work fine).

The reasons for this are:

• Status Creation: It's easier to give users a set of statuses to choose from so mapping of common statuses can remain consistent. For example, I could have "Dev Progress" and "In Progress" being used interchangeably - but I haven't got users creating statuses like "In Progresssss" using Simplified Workflows. If a team believes a status is missing, they can contact a Jira Admin to discuss the options available or to create a new status.
• Reporting: Linked to the above, we can create reporting which assumes "In Progress" and "Dev Progress" are the same thing, supported by company-wide documentation which teams can use when adding/removing statuses. This ensures management receive that reporting - whilst teams have some flexibility in their workflows.
• Workflow Properties: Simplified Workflows can't have transitional properties. I think things like the resolution screen are too useful to have that - not all issues closed should end up in "Done", resolutions of "Won't Do" or "Cannot Reproduce" can be useful to show where work was completed vs incomplete.

If you do choose (2) or (3) - I'd start them off with a template and a small number of statuses. Easier to add to a list based on feedback, than try to remove from users at a later date.

Ste

[Leo Diaz _ DEISER]

Hi @ambujp !

As a complement to Stephen's message if you are working on an enterprise company chose the Centralised Workflows option and in this case, those are my considerations:

1. If you are working on Server o Data Center use any app to delegate some actions like create project based on any template. If you are working on Cloud you can use Next-Gen projects
2. Publish on Confluence or somewhere your templates and create an internal process for ask to your Jira Administrators to change the template to another template

In any case, if you elevate your project concept to Jira project leve, I recomend you using Profields in order to give Status, Priority or any property to the project and track your projects just like you would with the issues