Is there a better way to share issues and projects within teams than manually sharing?

[creativet283366]

Hello,

Our creative team has a request queue project where all of their work requests are submitted by users from other teams. These requests are assigned to creative team members who then review their requests to ensure all needed information is provided before creating a project. At project creation, the creative user makes the original requestor the project's sponsor, subscribe themself and the project sponsor to the project, and then shares the project with the original requestor's home team.

This process works with a suite of reports to provide each user visibility to all their sponsored projects along with any active projects shared with their home team. The problem is that this setup relies heavily on manually sharing and subscribing each project to ensure the reports are accurate.

Is there a better way for us to handle this process? We are considering creating request queues for each team, but there are concerns this could create too much maintenance as more teams are added.

I am interested to hear any suggestions or thoughts.

Thanks!

[Doug_Den_Hoed__AtAppStore]

Hi Ryan,

Although you didn't mention using Templates at time of Project Creation, there are some benefits that might simplify the resulting sharing that you could leverage, which I invite you to review in this primer.

Regards,

Doug

[Heather_Kulbacki]

Ryan,

Do you use Portfolios or Programs to put these projects into? Although it still requires a manual effort to include the Portfolio (and Program if you choose to use both) on a project while setting it up, it's much easier to see at a glance if that project is in a Portfolio than it is to see who it's been shared with.

The portfolio and program will show right in the breadcrumb above the project name instead of needing the extra clicks to set into the sharing menu. And if those are missing in the breadcrumb, the user might catch it quicker than if they forgot to share it.

If your portfolios and programs are shared with the appropriate teams those users will get inherited sharing.

[Doug_Den_Hoed__AtAppStore]

Excellent suggestion Heather, I would caution, however, that I learned last week that Sharing via this manner has sometimes failed to propagate as expected, and might therefor need some extra nudging to push through. Fortunately, such failures are rare, and obvious (eg “Hey: I can’t see my Project!”), so I’d still concur that this is an approach worth considering. Regards, Doug

[AlisonW]

Hi Ryan,

We do two things that have worked very well in our environment. One has to do with Access Levels and the other with Templates.

In all of our access levels, when someone creates a project, their manager is automatically given Manage access to that project and their company is given View access. This ensures that someone besides the sys admin can manage the project and that it has visibility. In our case, "company" is our IT department. This is done with the Set Sharing Defaults link under Edit on the Projects item in Access Level.

Then, when creating templates, we share projects with different groups based on the nature of the project being created.

Access level is a blunt instrument for basic visibility, template sharing can be very specific and defined. But once we started doing this, our issues of people not being able to at LEAST see projects was reduced to basically nothing.

Hope this helps!

Alison