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; } } }

JPD as company-managed

Florian Royer_oqzjti

Just want to know if there is any chance to have a Company-managed kind in JPD instead of only team-managed?

We love the product, but we need to structure it, and be able to deploy in an "industrialized" way.

Our goal is to use it with our customers for the implementation of the products with them.

Thanks

Accepted answers

All comments

Gary Spross_o1iwv6

I completely agree with you Florian.

JPD seems great, but having it setup in a Team-managed style is almost a deal breaker. We need to have greater control and flexibility, but with it being "Team-managed" a lot of configuration ability is just not available.

Curt Holley

I tend to agree, though certainly it is the Team managed element that makes it so flexible.

But like any Team managed project, they can wreak havoc in the environment around field names, workflows and automation rules.

It would be ideal to have both available.

That said, if they (Atlassian) made some of the JPD fields (ones that can do averages etc.) available as custom fields, then they could potentially be deployed into any kind of Jira project, not just JPD. Which might be why this isn't a likely option, in the short term.

Rohan Swami

@Florian Royer @Curt Holley @Gary Spross For now, it's not on our roadmap to have Company-managed projects. As you've pointed out, the flexibility of Team-managed projects is hugely beneficial to our users which is why we've started with Team-managed initially. That said, we are aiming to support projects with shared fields so that you have some consistency across projects. Would that help?

@Florian Royer How would Company-managed help in your use case?
@Gary Spross what's the use case you're looking to address and specific configuration you'd like to have available?

Florian Royer_oqzjti

Hi @Rohan Swami ,

Thank you for your reply.

In our case, we would like to leverage JPD for the implementation we do for each of our customers.

Each customer would have its own project then.

But not having company-managed, means that we must redefine the Workflow each time we create a new project.

And also Team-managed don't include some features like Issue Security Level, for example, when we have an idea that we don't want to share with the customer yet because the progress is not good enough.

Also, as we have ~200 customers right now, it would be almost impossible to administrate ~200 projects JPD at a time. Company-managed configuration allows to clearly identify and change parameters at the configuration level.

In team-managed, it means we need to do the config manually each time:

Configuration of Workflow
Configuration of screens
Configuration of permissions
Re-configure the different boards and views (those are specific to JPD, but we could imagine having a kind of company-managed configuration)

As a workaround, maybe you can set up a kind of "wizard" configurator that would copy all these configurations from one project to another, and when changed in one project, have the ability to copy the change in another project (a bit similar to issue layouts in JIRA Software).

Also, those pain points of team-managed projects, are the reasons why we prefer company-managed:

No issue with security levels
No integrations with Advanced roadmap (and this, I think is really important as the JPD is supposed to be above the delivery projects)
No global automation => have to copy each time the automation in the new projects, and when there is a problem, then recopy all the automation...

Again, we love this new product, but IMO, it's too early to start to commercialize it as it is using only 10% of JIRA powerful features.

I hope it helps. don't hesitate if you want more information, we can definitely organize a zoom meeting

Best regards

Rohan Swami

Thanks so much for that context, Florian. It's really helpful for us as we try and prioritise where to improve the product. I'm sure we'll be in touch in the future when we get around to addressing this area of the product.

Gary Spross_o1iwv6

Hey @Rohan Swami!

We steer clear of Team-managed projects for a plethora of reasons, the main one being proper configuration control. @Florian Royer touched on most of the reasons we would like JPD projects to be able to be setup as Company-managed. Proper, controlled, configuration.

Also, we utilize analytics tools to determine specific metrics. If we plan to incorporate the JPD projects we will utilize with these tools, we would need consistency in the data being captured and the progression of the work. Team-managed projects make it very difficult to ensure any consistency.

Thanks!

J P_tty6su

I want to echo the need for JPD as a company-managed project type for all the reasons @Florian Royer listed. We have the same issues.

Due to legacy configuration incongruencies, acquisitions + Atlassian migrations different product & engineering approaches, and several other issues... our Jira project configuration and overall structure is all over the place.

Within our Product Team, We have 7 product groups. Over the past year, we have made significant progress with aligning our Product Groups around a standardized Jira Software + Jira Plans structure [but still have a long way to go].

JPD is a game changer. There is a lot of internal excitement in pockets of our teams, and we are experimenting with several POCs. However, the lack of company-managed oversight creates significant adoption barriers and yet another confusing free-for-all that iterates more chaotic inconsistencies into our delivery process.

I regularly reference and pass around this wonderful article from @Tanguy Crusson ... The relationship between Jira Product Discovery, Jira Software, and Advanced Roadmaps

At our scale and within our context, having all PMs, across the widely varied products + groups in one JPD project just isn't feasible or digestible.

The best we have come up with so far is to maintain a Confluence document with fields + field types + values... and then manually setup each project accordingly... and people inevitable start adding + modifying fields & values.

JPD is so exciting... thank you for your work Atlassian crew! I just wanted to add my vote and voice into this conversation.