Balancing between team-managed and company-managed projects

[Sam Nadarajan]

Hello! 

I've been getting more comfortable with team-managed projects - especially for Jira Work Management, that I am looking to expand their use within our company. Right now I'm limiting the scope of team-managed projects to smaller initiatives that do not require much oversight and/or configuration, and depending on how that goes, looking to expand to other use cases as well.

I feel comfortable with the best practices surrounding when to each type of project - or at least what to think about before making a decision. My questions for the group here -

• Have you done something similar at your company?
• How did the adoption go? 
• Any hard lines in the sand that you would draw?

Before I feel comfortable expanding team-managed project use, I do want to improve the overall Jira knowledge at the company - which will require more training and education, so that's a hard limit that I won't be compromising on. But I'm open to other strategies and your experiences if you have been or are going through something similar!

[Rebecca Hylek]

Hi Samuel,

Our organization has made the decision to not expand to team-managed projects at this time. 

Although we love the idea and flexibility of team-managed, we're still in a major clean-up phase and did not want people creating custom fields, workflows, etc. until we have that under control.

Looking to the future, we hope to be able to allow this flexibility for situations like you describe, i.e. small groups/teams that do not require much oversight however it won't happen anytime soon.

We do have steps in place today for smaller teams to request Jira Work Management projects which has gone over very well.  They're still company-managed and we've created options based on the must common requests.  Our small, non-software development teams love them!

Looking forward to other comments on this topic! 

[Sam Nadarajan]

Keep me posted if anything changes and I'll do the same! But yea a couple of concerns that I've noticed:

• Not enough people at the company understand how Jira works or how it's managed...yet
• Teams keep asking if there's a way to manage more of their own configurations at the project level - when they keep asking me to manage configurations that they are capable of doing right now
• One person didn't want to initially configure their team-managed project because of the sheer amount of fields they would have to create (most of them didn't need to be created)

I'm running a very tight pilot right now and I hope I'm not coming across as grumbling - I just realize that my work is cut out for me. There is value in our organization to have team-managed projects at smaller scales to reduce admin workload but also empower teams to reach greater levels of ownership - so I figured I'd start the process now with the hope of being in a much better place in like 2-3 years. And I do believe in the incredible amount of value that team-managed projects have!

[Derek Adkins]

I've opened up team managed projects to some of our other non engineering departments, and they love it.  From a jira admin perspective, it does create some challenges... one that I've noticed is that they are starting to write their own automation rules.  And because they're not from a technical background, the rules are inefficient, or firing a the wrong times etc. 

So, as long as you're happy to jump into their projects every few weeks, and review the workflows and automations, and help cleanup some mistakes and config, then it's fine.

The config of workflows and screens and fields is SOOO much easier.  BUT, there are limitations.  And if you want the same fields across multiple projects, you have to configure it all a second time. So it's annoying in that regard.

Permissions are also limited.  Especially on projects where you want to hide certain issues within the project from certain groups.  Very granular kind of thing.  

[Sam Nadarajan]

Good ideas on the periodical reviews of projects - never would have thought the automation rules would pose an issue! I'll keep this in mind.

Have your teams using team-managed projects gotten better at managing them with your periodic reviews?

[Lauren Allen]

From a training perspective, I would recommend that anyone who is going to be responsible for team managed projects do some training so they understand the impacts of certain decisions, like when to create custom fields, why they should avoid text fields, how to design workflows and so on. 

Having well informed people administering team managed projects will make your life much easier down the track.

[Sam Nadarajan]

My training so far has been pretty brief:

JWM-specific

• Summary tab
• Different views (List, Board, Calendar, Timeline)
• Project Pages
• Forms

Team-Managed

• Specifying project access
• Creating issue types
• Creating Custom Fields (and searching for existing ones)
• Maintaining workflows
• Automation Rules

I'll probably go deeper into custom field maintenance - thanks for the tip!

[Karin van Driel]

Hi,
We are avoiding Team-Managed projects for our Technology teams and for any teams that require standardisation for reporting upwards. Also bearing in mind that Advanced Roadmaps functionality cannot be used for Team-Managed projects and we rely on this for planning our technology initiatives. 

We are using Team-Managed projects for work management within teams, for work that doesn't require management reporting. 

Some of the ways we help teams who are in Company Managed projects control some of their own direction:

• Letting them know about Automation - some teams have been excited to use this to create standardised sub-tasks and additional templated information they wish to capture by adding a template in the description field.
• Layouts - we configure a standard screen, but minimise the required fields to just those we must have for reporting and to drive any automations. Teams can otherwise create their own layout.
• I ensure that if someone asks me to do something that they have the ability to do themselves as a Project Admin, that I explain the steps to them, so they do it themselves, rather than me taking care of it. I create a Knowledge Document in Confluence where needed and point people at that.

As some others have mentioned, we are also in the process of a major clean-up following multiple migrations, one of which was a migration from an older Server instance to Cloud. We don't have any full-time admins and are working on building a team of part-time admins, so having teams who do not need the rigor of a Company Managed project using Team-Managed projects going forward would help us greatly. I'm hoping to soon be at a stage where we have a well defined standard for projects that require Company Managed projects, which will then require minimal overhead and to be able to then have Team-Managed projects for those one off scenarios that don't require standardisation.

As an organisation we have access to LinkedIn Learning and I have been pointing users at some of the excellent training available there, to get familiar with the additional functionality available in our new Cloud instance as well. This has been very helpful. 

Finding a balance between minimising Jira Admin involvement and not creating the Wild West in our Jira instance is challenging, but I'm hopeful we are making progress!

[Rebecca Hylek]

Hi Karin, it sounds like we're working in similar environments. 

We migrated to the Cloud last year and unfortunately, our on-prem instance truly was the "Wild West".  We recently established a dedicated team to support Jira, Jira Align, and Confluence and it's made a tremendous difference. 

As part of our clean-up efforts, we had to sort out the next-gen projects that were no longer in use or created by people who had left the organization.  Although some of these projects were very creative, we had literally hundreds of custom fields (who knew there were so many ways to say something is "closed") and the number of workflows was staggering.

Finding time for the clean-up hasn't been easy but we're definitely making progress and starting to see the benefits.  Our project teams are happier with standardized workflows and screens, less customization and the onboarding/training we provide has been well received.  We also point them to LinkedIn Learning as well as the free classes offered by Atlassian.  Posting a monthly newsletter and tip of the week is another way we're sharing knowledge about Jira across the organization and our business partners love it!

Overall, taking our time to plan properly has also reduced the amount of requests for support by about 40% which is amazing!  Going forward, we'll work with some of our stronger project leads and begin a "train the trainer" approach which will also help with reducing our daily Admin tasks.

Good luck with your journey!  

[Sam Nadarajan]

It's interesting to see part of this discussion stems from a recent/ongoing migration - which of course is a great opportunity to do an audit and optimize where possible. I'm somewhat in a similar boat as well (migration won't happen till later this year) so I'm keeping a closer eye on past neglected items. Terms such as the "Wild West" and "standardization" have also been true here at my company so finding that balance is not straightforward but somewhat possible.

I haven't heard comments saying that team-managed is just not a good idea - which is encouraging and is different from some of the earlier perceptions I was exposed to. I'm also hearing (and encouraged for the validation) that team-managed is probably more limited than what the average user may come to believe. 

Leaning heavily on training seems to be the key here - I'm glad to see the investments in that area to stabilize a large system (this should be true for any system of course). I've been pushing the local ACE here to help with the knowledge but it's been a harder lift.

The monthly newsletter is an excellent idea - especially if I can keep it company-focused and relevant to our way of doing work. I've thought about it for a while - just need to free up some bandwidth to do it.

[Haddon Fisher]

I personally see the potential for admin-savings, but I haven't seen it pay out in practice, mostly because:

• Administering Jira (even the small piece TMP gives you) still requires a lot of special knowledge. I find that my TMP admins are still asking me a lot of questions.
• The superficial similarities between CMP and TMP create such a cognitive dissonance for users AND admins that it actually INCREASES admin work in some situations. For example, I've spent a lot of time trying to figure out how to enable something in a TMP that exists in a CMP only to find out it simply doesn't exist, or functions differently enough under the hood as to make it functionally unusable. Because this is on Cloud, it also changes (occasionally silently) so there's an additional need to monitor this over time as well.

I think they're moving in a good direction and we might get to a place eventually where this is no longer true, but as it stands (and given Atlassian's traditional pace) I am not holding my breath.