best way to reduce number of projects

[Dennis Celen]

we are new to Jira and since we started using it, people made projects for every task category. 

we want to lower the number of projects. so we have a better overview. 

The idea is to start with the following projects and use subcategories or something else so we can still categorize sub issues. today all these items have their own project. Or is it also possible to have more board for each project?

• Marketing & Communication
  • Content creation
  • Events & Seminars
  • Marketing Campaigns
  • Marketing KPI's & Analytics
• Finance
  • ...
  • ...
  • ...
• Business Development
  • ...
  • ...
  • ...
• IT
  • ....
  • ...
• Procurement
  • ...
  • ...
• HR
  • ...
• Operations
  
  • ...
  • ...

[Ste Wright]

Hi @Dennis Celen 

It looks like you're structuring Jira Projects as departments and/or teams, is that correct?

---

Projects

If you've not already decided, you should also decide what Project types to choose.

• Team-managed vs Company-managed: The main differences between these two types are...
  • Team-managed Projects are administered by that specific team - who have full control over workflows, issue types, fields, etc, in isolation from all other teams.
  • Company-managed Projects are designed for teams who are collaborating - with shared configuration, more advanced customisation, the ability to have multiple Boards (in Jira Software), etc.
• Work Management vs Software: There's also two types of Project template to choose from - the main differences here are...
  • Work Management templates are designed for "business teams" - and are simpler to setup and use. They come with several unique views, including a calendar view, and a list view - and have one single Board.
  • Software templates are targeted at "development teams", but a lot of business teams use them as well. They offer some additional features, like releases, and have more customisable Boards - including the native ability to have more than one per Project
    • They also offer the ability to have Kanban/Scrum Boards, so if you are using Agile methodologies, this might be a good option for you.

Note: See this help page for more information on Company-managed vs Team-managed: https://support.atlassian.com/jira-software-cloud/docs/what-are-team-managed-and-company-managed-projects/

---

Once you've made a decision on your Project structures - there's other categorisation options you can utilise for the types of work each department does.

---

Issue Types

Issue Types differentiate different types of work.

A key decision will be, should...

• Each sub-category in a department be an Issue Type?
• Or, should you use a common set of Issue Types, which represent types of work - eg. Epics, Tasks, Stories, Risks, etc

Issue Types are used in multiple other parts of Project configuration - for example, you can have different Workflows, Screens, Field Configurations, etc per Issue Type.

See more information on this help page: https://support.atlassian.com/jira-cloud-administration/docs/what-are-issue-types/

---

Identification Options

If you decide to go with a common set of Issue Types (which a lot of teams do, to make it simple to report on later) - there's several other options to identify the type of work:

• Components: If you're using a Company-managed Project, you can create a set of Components per Project. These are sub-categories which you can set against each Issue - and unlike Labels, the options available in the field can be limited by the Project Admin.
• Labels: These are a more free-form of categorisation. Labels are global, so once one is created it can be used across all Projects. Users are free to create/add as many Labels as they like to Issues they can edit.
• Custom Fields: You can also add additional fields to your Projects. With a whole range of field types available, you could add one most suitable to your need - for example for work types, you might create a Select List (drop-down field).

For more information, see:

• Components - https://support.atlassian.com/jira-software-cloud/docs/organize-work-with-components/
• Custom Fields...
  • Company-managed - https://support.atlassian.com/jira-cloud-administration/docs/create-a-custom-field/
  • Team-managed - https://support.atlassian.com/jira-software-cloud/docs/customize-an-issues-fields-in-team-managed-projects/

---

Boards

Whilst it's technically possible to create multiple Boards for any Project type/template, it's only native behaviour for one Project type - Jira Software Company-managed Projects.

Boards in Jira Software are visualisations of Issue Search Filters - so can show one Project or multiple, or a smaller segment of Issues from within a Project, etc.

If you intend to have multiple Boards per Project, I'd recommend using the Jira Software Company-managed Project type.

See more on Boards here: https://support.atlassian.com/jira-software-cloud/docs/what-is-a-jira-software-board/

---

Learning

I'd recommend reviewing some of the guides/support pages to help you get you started. Atlassian's documentation is very detailed/rich, and will help you on your journey to setting up your Projects.

Check out...

• Jira Software:
  • Getting Started: https://www.atlassian.com/software/jira/guides/getting-started/overview
  • Support Pages: https://support.atlassian.com/jira-software-cloud/
• Jira Work Management:
  • Getting Started: https://support.atlassian.com/jira-work-management/docs/get-started-with-jira-work-management/
  • Support Pages: https://support.atlassian.com/jira-work-management/
• Atlassian University: Review learning options on Atlassian University - for example, there are a set of free courses, learning paths, and courses (like Get Started with Jira), which might be useful to you!

---

Hopefully this is enough to get you started - if you have any further questions, let us know!

Ste

[Walter Buggenhout]

Hi @Dennis Celen and welcome to the Community!

It is great to see that shortly after you started using Jira you're also starting to ask yourself questions. Not only about how the tool works, but how it may best support how your company or organisation is trying to do its work. The tool(s) should support your organisation and not the other way around.

@Ste Wright has offered a ton of useful information and resources. I support every single one of those references, but would also like to add one or two additional thoughts:

• it is great to start figuring out how you best structure your projects. At the same time, don't let reducing the number of projects be a goal that stands on its own. While you can add multiple boards to a project, a more common approach is to add multiple projects to a single board. This is done with company managed projects using a filter as the source for your board.
• Jira works best if you organise it around teams. While these may be departments, they can just as well be project, application or even cross-departmental teams - as long as they are a group of people working together on a common body of work.
• Assuming you have a development team working on different applications, it may be a good idea to have separate projects per application (as it might make sense to manage the application's versions and components separately), but set up a single scrum board where you can plan and track the work of your team.
• It is very important to consider that a board and a project in Jira are different things. A board has a lot of features that support the way of working for your team (choice of methodology: scrum or kanban, reporting (such as your team velocity), ...) while a project is the place where you store issues with a common context (maybe a team, an application, a customer or even an actual, real life project).
• When you want to start using Jira as a foundational part of the way you work at your company, a good recommendation is also to limit the number of administrators (or people who can create projects) in your environment. Make sure the ones who fill that role properly familiarise themselves with the tool and best practices.

There is no black or white answer or a prescription that says how you should do this. Starting to think from a team perspective is definitely going in the right direction and I sincerely hope going down that track will help you land on that sweet spot you're trying to find.

In case you do get stuck, you're in an area where typically a solution partner may be of great value. Working for one myself, I know from daily experience how they can help you bridge that gap between the way you would like to work and the capabilities of the Atlassian toolset.

Hope this helps and all the best!

[Dennis Celen]

hi all 

I will take a look in to this . thanks

Dennis