JPD as company-managed

[Florian Royer]

Hi

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

[Gary Spross]

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.

[J P]

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.

[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]

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:

1. Configuration of Workflow
2. Configuration of screens
3. Configuration of permissions
4. 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:

1. No issue with security levels
2. No integrations with Advanced roadmap (and this, I think is really important as the JPD is supposed to be above the delivery projects)
3. 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]

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!

[Rohan Swami]

@Gary Spross what sort of metrics are you looking at from JPD?

[Gary Spross]

Metrics such as:

• Investment Breakdown
  • What types of ideas are getting approved?
  • What expected value are the approved ideas bringing to the company?
• Allocations
  • What teams are involved in the approved ideas?
  • How many deliverables are generated by the approved ideas?
  • Which customers are requesting the majority of the created ideas?
• Engagement
  • What ideas are garnering the most activity?

I'm sure there will be more, but these are a few I can think of off the top of my head.

We would like to have multiple JPD projects to cover incoming ideas for different products, but w/ Team-managed, we're not able to have a consistently configured setup for the projects. Having to manually re-create everything every time we create a new project is an unnecessary time consumption.

[Rohan Swami]

Makes total sense - thanks for that context @Gary Spross 

[Billy Turner]

Agree with @Gary Spross . We avoid Team managed projects completely. If someone creates a team managed project and then asks to "fix" something in it, my first response is to migrate to a company managed project so that I have some control over it. Obviously in the case of JPD,  this is not possible. It will likely cause a lot of companies to use alternative products that they can more readily control including mine.

[Florian Royer]

Hi @Rohan Swami ,

Any updates on that matter?

I have 2 potential customers who'd like to implement JIRA on their own, and have been asking me the same exact question if they could control JPD projects within a company-managed way.

JIRA software and JSM propose the 2 configurations. If you like the flexibility of team-managed, fine. But propose to your customer to use the rigidity of company-managed, please. Having one doesn't mean we couldn't have the other.

Regards

[JB Higgins]

Hi @Rohan Swami

I will echo @Florian Royer and @Gary Spross in wanting to see JPD as a company-managed project, for the reasons stated above. To answer your use-case question for me, custom fields across projects is the most common use-case/barrier I come across with my clients using JPD. For example, they want to be able to carry over drop-down values from a JSM custom field into the same field in JPD.  If only that could be implemented or supported, that would go a long way toward more adoption from my clients.

[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.