nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Create a separate Project for Initiatives or Not? What are the Pro's and Con's?

Melissa Thornton

I am configuring a proof of concept for possible purchase of Portfolio. Our functional teams are set up as JIRA projects. We have initiatives that cross projects but there is always one functional team/jira project that 'owns' the initiative.

My question is...

Is it better to set up a project just for the initiatives and link each team/projects work to it or would it be better to set the initiative up under the 'owning' teams project and link other work from there?

What are the pro's and con's for each of those options

Thank you for any assistance you can provide

Comments

mrcrandell.sw

The obvious pro for keep all levels in a single project is just that “ it’s all in one place/project”.

We have projects In our instance that have done it both ways. Some have even gone as far as having one project for initiatives, one project for Epics, and the multiple team level projects. One advantage that way is that you can give clients access to the initiative project and/or epic level so they can have some visibility/input at the top while keeping details around stories and tasks internal.

Ste Wright

Hi @Melissa Thornton

I think it depends on how your projects are used across the business - and how important access to Initiatives are.

As an example, I've run into several instances with this setup:

Program Teams which have Features and Initiatives above Epics
Each project is a different delivery team or...
Each project is a different product / product team

In these instances, we've used a separate project for Initiatives and Features to keep them contained. The project contains all Initiatives and Features across that slice of the business.

The benefits have been:

One project to contain all program-level work - rather than trying to decide which team "owns" a Feature or which product has the most involvement in an Initiative.
Permissions were limited to who can create or edit Initiatives / Features - given they are where our value and delivery intent is stored.
Components and other project-level settings were limited to ensure reporting was centred and simple.

That is the best practice suggested by Atlassian; but you could have them in one project if (for example), Initiatives were product-based and so were your projects. Just depends on how you and your teams work!

Ste

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

advanced-roadmaps