What is the best practice for project creation, screen, scheme, wf ,...

[sc]

Dear all,

We are actually in charge of reviewing  our customer best practice in term of project under Jira. By project I mean all thing needed to create a project as best practice rule we need to explore and try to be stick :

For exemple we know that we must use ROLE instead of Group when we need to set permission. This is what we actually do.

But there is more that this like :

When we create a project, is it better to have all scheme, screen, WF, Fields to be unique for each project ?

We notice with the time that sharing scheem, WF, screen between project limit the change on a single project as it will affect the shared.

What are your rules to be efficient and in a best practice path ?

Any link whish summary all rules to follow ?

Thanks for sharing your experience in this

regards

[Scott Theus]

Hi @sc ,

There are no hard and fast rules, but I understand where you are coming from. Here's how I set mine up:

Let's say you have three main project types: HR/Payroll Systems, Supply Chain Systems, and Data Management Systems.  While these may have cross dependencies, each one has distinct workflows, issues, custom fields, etc. 

So, for each project type (or program/portfolio) you would set up the schemes that will be used in those particular projects. That should cover about 80% of the projects in each type. For those that are unique and need a bit more customization, create a copy of the standard schemes for that type and modify the copy. That way you are not impacting other projects that use the main schemes. 

For inter-dependencies between projects, you would create a filter that pulls in all issues in all statuses, then create a kanban or scrum board that maps all of the statuses to columns. You could even create individual columns for each status (assuming that each of the three project type's workflows have some statuses that are unique to them and some that are shared across one or both of the other types.) That wold allow you to see where bottlenecks are happening. 

Others may have additional ideas, but this tends to work best for me. 

-Scott

[sc]

Thanks for your reply scott.

So If I follow your experience you are saying that as long as the way of handling an issue type is the same in each project, then this means we can share a unique screen, field and scheme and share it between all projects,

correct ?

Next I do not understand the way to go what you describe below :
"For inter-dependencies between projects, you would create a filter that pulls in all issues in all statuses, then create a kanban or scrum board that maps all of the statuses to columns. You could even create individual columns for each status (assuming that each of the three project type's workflows have some statuses that are unique to them and some that are shared across one or both of the other types.) That wold allow you to see where bottlenecks are happening. "

In which way you can see bottle neck in that case sceanrio ? any illustration ?

regards