Linking projects

[Mauro Cortesi]

Hi there..

I'm new on Jira....trying to discover how to implement it with the less regret in the future...

For now, I'm stuck with this...

Is there any way to link a project to another project?

Something like parent->child....

We've projects of different products, with diferent issues, versions, etc.......but they can be related to each other.

The only I look for is to know for a project, if it's related to another...... or for a particular project, get a list of his associated.

First thought was create as many components as 'child projects', still have associated issues (to a component)....but lose the release versions for that components/projects......right?

Is there a limit for number of projects?, components?

Thanks,

[Richard Cross]

The best way to do this is via Portfolio for Jira, which is now built-in to Jira and called "Advanced Roadmaps". 

https://www.atlassian.com/software/jira/features/roadmaps

This allows you to organise your projects into a Plan, and those Plans into a Program.

The advice from Atlassian is to create another project in your plan to hold cross-project "Initiatives" that (in the Plan), serve as a hierarchy above Epics.

[Blair Rodgers]

I also need to be able to link projects, one master project, with many smaller projects that must have separate Jira numbers (prefix), project names but ultimately have a way of linking back to show full view of the entire project and the progress of all of it's mini projects below.

An umbrella project of sorts, with many smaller projects that make up the whole. Lots of moving parts

[Tarun Sapra]

There is no limit on project and components. In JIRA you can't link projects, thus the best approach is to have components for smaller initiatives, and create a board (Scrum/kanban) wherein you fetch issues from multiple components. 

What do you mean by "but lose the release versions for that components/projects......right?"

As you can have per component boards and make releases exclusively for issues pertaining to that board.

[Nic Brough -Adaptavist-]

Project categories can help you group your projects together, but there's no real "link"

[Stacey Ward]

Hi @Nic Brough -Adaptavist- , is there any update since 2016 on @Blair Rodgers comment below? 

Any other community leaders to assist? 

Thanks! 

[Blair Rodgers]

Hummmm, not ideal. For instance, I’m currently on a project that has 18 seperate mini (For lack of a better word) projects that all run concurrently and not having the ability to make one master and multiple mini projects that link back to the master, it gets very messy and I cannot report easily on the progress of each part of the entire project.

[Nic Brough -Adaptavist-]

Nope.  Atlassian expect you to do project -> sub-project with components

[jbedar]

Hi @Nic Brough -Adaptavist- It is now June 2021 - got anything new for us? 

The fact that Initiative (seen defined as a program, i.e. collection of related projects, in Jira documentation) is not visible as a hierarchy option from the start is a flaw in the design.  The fact that you cannot inherently communicate or assign/share/move tasks or other issue types between projects (regardless of type - as it seems only service desk projects can do this) is a HUGE FLAW IMO and all of this adds up to why I see Jira as a ticket management software - NOT a project management software.  Too many disconnects or need for custom dev / configuration.  Surfacing this as I am hopeful that someone may be able to direct me to a good source of set-up / configuration guidance so that I can manipulate the environment / tool to achieve what our organization needs.

[Nic Brough -Adaptavist-]

You are mixing up "project management" with "project portfolio management" there.

Initiatives are a layer above projects, and cross-project.  That's why things like Jira Align, Advanced Roadmaps (bit clue in its previous name of "Portfolio"), Big Picture, Aha!, and and and .... are there.

Also, Jira, at its heart is an issue tracker, not a ticketing system ("ticketing" systems are a sub-set of that type of software - all ticketing systems are issue trackers, but most issue trackers are not ticketing systems)

I'm confuddled by this statement:

"The fact that you cannot inherently communicate or assign/share/move tasks or other issue types between projects (regardless of type - as it seems only service desk projects can do this)"

Service Desk projects can only do it because the underlying Jira project can do it.  In the background SD projects are using functions ALL types of project have.

Anyway, you've not really defined what your organisation needs here, but as you've talked a lot about PPM functions, I'd guess that's what you're looking for.  I'd certainly start with a look at Advanced Roadmaps and Big-Picture as a starter.   Plus, if you're willing to do a bit more of the construction yourself, or the layers of PPM aren't quite right for you, a look at Structure would be good.   (Aha! and Jira Align I mentioned before are probably heavier in weight - they can go right the way up through many layers - dev/PM, PPM, Delivery, Enterprise, right the way up to Organisational agility)

[jbedar]

Clarifying - If I have I have a cross-team engagement project - created as a business project - requiring multiple teams to engage (which they manage on their individual team project / board) - inevitably the 'ticket' is copied, cloned, moved to their board where they manage it - the communication line / visibility from the submitter is broken.  

I'm not mixing up anything IMO - as a PMP, my opinion is that the majority of (default OOTB) objects called projects are not actual projects by definition (unique, beginning / end - I'm focused on the non-dev / agile efforts within our organization). I understand (I think) that I am trying to workaround the tools structure to 'form a PM tool'. 

I need to have a umbrella Initiative / Program that houses the related project. 

Trying to break this down so it makes sense / clarify below.

Scenario 1 | Engineering is not a project - its a program with Epics (projects like build a server, network segmentation, etc.) under the top-level initiative.  I have basically created this scenario under plans.  I am relatively new to Jira on the admin side, but seemingly not intuitive, still learning there - the biggest issue we face is broken communication / visibility (lose the submitter visibility) and other than creating a service desk project for each team / entity, I don't see another way to 'link' projects, issues, etc., with multiple teams engaged. 

Scenario 2 | We have a GRC / compliance tool that will 'auto' create about 800 tickets a year - all 'planned' to land on a specific InfoSec 'project / board' - many pieces of that will need to be addressed by multiple teams w/ multiple boards - I need to understand how to 'link' various projects & project types.

Scenario 3 | Helpdesk service management project that requires the request to move to another board due to being determined to be an Epic (larger effort); Clarifying the how for both SD to SD efforts, which I understand will maintain the 'communication line / visibility' - but we are currently set up with mostly software / business projects so how do I connect SD to SW or Business projects (configure what service desk has in the other types, based on your comment)?

We 'inherited' our instance from a co. acquisition several years ago.  Not sure it was ever implemented / configured properly (IMO), so I am working to find best practices to renovate and groom to use the actual power of the tool.  I have been digging, watching videos and engaged in discussions w/ Partners (vetting).  Would love some direction to resources (white papers, implementation guides) that are considered 'best practice' by Atlassian.  Sorry for the confuddling, thanks for your response and look for your (or others) feedback.  

[Nic Brough -Adaptavist-]

Ok, I'm afraid that essay simply confirms that you're not quite understanding the difference between project management and project portfolio management.   In fact, your three points about what is and is not a project confirm it.  You're thinking of projects as entities at the wrong levels.  What you're looking at there is not project management.

But, there's nothing wrong with the way you're thinking, it's understandable, useful and a good way to look at things (and very clearly written up), it's purely that you're calling it "project management" when it isn't.

It's this that makes it clear - "I need to have a umbrella Initiative / Program that houses the related project. " - yep, that's not PM, that's PPM, which is not what (plain) Jira/SD/Software claims to be for.

[Dave Rosenlund]

From where I sit, I think Atlassian would assert Jira (and certainly Jira plus Advanced Roadmaps) can do everything you need it to, @jbedar.  But only you can decide that -- whatever you want to call things.

However, I agree with @Nic Brough -Adaptavist- with respect to what normally happens...  And you may not like it: Usually, people add something to Jira to help them manage "programs" (portfolios, projects of projects, whatever you want to call it). This is pretty much the norm in the SW industry.  I'd be hard-pressed to name a product that I use out-of-box/as-is.  My browsers, my phone, my computers, the enterprise software I use, all have plug-ins that extend the OOTB capabilities in ways I find useful.

As you say, it's 2021 and I don't think it's wise to wait around to Atlassian and change Jira's architecture to do things exactly as you expect. Get comfortable with the idea that you may wish to use one of the apps Nic mentions.

Full Disclosure: I work for the company that makes one of them — Structure for Jira — and (according to Atlassian) we have more than 10K active installations in the Jirasphere. People use it, or one of the others, to do what you describe.

-dave [ALM Works]

[jbedar]

@Dave Rosenlund @Nic Brough -Adaptavist- 

Yep, I have a running conflict with the use of the term projects / nomenclature assigned to certain things, working on that.  If I am hearing you correctly, PPM (IMO) is the same as Program Management, which is ultimately why I feel I can shape the tool to be what I need (management of project under and umbrella, not management of Epics, etc, under projects (Epic is a project? lol)...trying to connect the dots, find best practice, etc. Happy that you (both) were able to decipher what I'm after being a noob and all.  For about the last year, as a PM, I have been trying to adapt to shape it around what it can do and beyond. I discovered Deep Clone plug-in and with that I can label all cross project tickets (regardless of board) / clone them with full detail, receive auto updates from the original for tracking...but not scalable, easily implemented / adopted as a process, or even a clean way.  Interestingly, I have spoken with three Platinum-level partners and one of my first questions for each was - among ATL products is there another level to 'manage them all' - no mention of Align or anything else.  I'll check out your stuff, Dave.  Structure is one of my favorite words and what I feel is missing from our instance.  i.e. we have over 110 different workflow schemes for a 250 person co. where only 25% use Jira :). Thanks Nic.  Appreciate your input - had a trainer once upon a time that would say, "It just is. Don't argue it or research it.  It just is."  

[jbedar]

@Dave Rosenlund 

Tangent conversation re: your Plug-in

Perhaps you can enlighten me how the pricing works.  Simply put - is there a way to only be billed for 25 users?  Seems like the pricing ends up based on # of licensed users.  As mentioned, we only have about 25% of the co. using Jira at all and potentially would be a small subsection of that % who would use the plug-in at all. 

Thanks in advance.

JB

[Dave Rosenlund]

Hi, @jbedar.  All Atlassian Marketplace apps are required to license their apps according to the number of licensed users in the underlying Jira (or Confluence). The marketplace vendors factor this into their pricing according to the way their products are used. 

In other words, if we could license Structure for say, 25% of the licensed Jira users the price per user would be much higher (because we use a value-based pricing model). 

This is sometimes confusing for customers until they get used to the idea :( 

Unfortunately, in your case, only a percentage of users even use Jira.  I'm not aware of any way we can factor that in on a one-off basis.  Sorry. 

-dave [ALM Works]

[Richard Cross]

Hi @jbedar 

"Structure is one of my favorite words and what I feel is missing from our instance.  i.e. we have over 110 different workflow schemes for a 250 person co. where only 25% use Jira"

I wholeheartedly agree; "snowflake" projects come about as a result of a relaxed approach to Jira discipline.  

If you want to enforce common structure (which becomes rather essential to using add-ons that mange multiple projects such as Advanced Roadmaps), you need to enforce that all new projects are created from "shared configurations" (which are ordinary Jira projects that you designate as templates).

[jbedar]

I think I am going to quote you on that last statement for my internal documentation :).

If you want to enforce common structure (which becomes rather essential to using add-ons that manage multiple projects such as Advanced Roadmaps), you need to enforce that all new projects are created from "shared configurations" (which are ordinary Jira projects that you designate as templates).