User Group Follow-up (Dec 8, 2020) - Reporting to Executives

Hi - here is thee info for the Document Report we talked about for reporting on "assets". Just to clarify, we tend to only proof assets so that is why this works for us.

Prompt: Project >> Portfolio ID

Fields:

• Document Name
• Current Version >> Version
• Current Version >> Active Proof Stages
• Current Version >> Entry Date
• Owner Name

Groupings:

group.0.displayname=PM

group.0.valuefield=project:owner:name

group.0.valueformat=HTML

group.1.displayname=Project

group.1.valuefield=project:name

group.1.valueformat=HTML

textmode=true

Filter:

• Current Version >> Proof ID is Not Blank
• (Also have other filters based if someone wants the whole portfolio or a certain status or something)

Hi - I also mentioned in my group a User Activity report I use for new deployments. Just so they can see who is doing stuff in the system. It is a Note report where the grouping is by Owner Name and then by Audit Type.

Thanks Kristin -- great session!

As discussed, for those interested in leveraging the Done Right At Workfront team's goodies to clean up their own environments...

• join and set up a connection to your Workfront environment (see video)
• go to Packages
• click the DR@WF Cleanup Tools connect to your Workfront environment
• run the solution
• start cleaning up!

There's also a blog post and a video of it all in action (featuring @Shawn Loutensock‚ and me), too.

Ah: and along the same lines as Anthony’s suggestion, I invite you to deploy The Scoop while you are at it, too.

I hope these are of use, and am interested to hear how you make out!

Regards,

Doug

@Kristin Farwell‚ I really like the use of change orders for campaigns and this isn't something that we use yet at my company but would love to track! How exactly do you track it? Is it a request at the programme level that requires an approval?

Hi Ashley - I believe Christopher said they have one request queue for input, but then they move the issue to the project afterwards so that it is tied to the project.

I'm thinking of potentially using this idea as well. Although for me, the issue would be on the project to begin with, but that is because we are already using Workfront in a way that every project is a mini-request queue so my people are used to that.

Hi - that's correct.

We have a request queue that is for Change Requests. Second and Third drop down in request queue is Portfolio and Program - which allows us to report for these areas.

The Change Request form has options for reason including things like Strategy Shift, Scope Change, Missing Information, Inventory Update, etc. As well as if content is live or not.

It's made a big impact to report on this all up and by portfolio!

Hope that helped

Christopher

Thanks for the tag, Kristin, and nice timing Ashley,

After the User Group call yesterday, this was one of the topics I then discussed in more detail with @Eileen Womelsdorf‚ and @Mark Hahn‚ during a queue setup best practices session we'd previously scheduled, and suggest:

• starting with a single queue (as I also recall Christopher said) is wise when Request Queue are a new concept for a set of users: it keeps it simple, ensures a single point of entry for consistency/review/redirection, and can be modified quickly and easily (e.g. changes to the Request custom form) on that "one spot"
• similarly, less is more on the custom forms: ask for only what you really need at that point in time to assess/route correctly, and avoid planning work (or collecting extra data) that might not happen; that said, a dropdown of "With whom [on our Request traffic team] have you discussed this Request" is an excellent question to ask right up front, for awareness/context/affinity/efficiency
• unless the nature of the requests are both well defined and well understood by Requestors, consider using Custom Forms (which are more flexible and visible) than Queue Topics (which can be hunt-and-peck frustrating) and routing rules (which can too easily send a misclassified request to then languish on the wrong desk), noting that you can then leverage the latter two features once processes evolve
• optionally, gradually introduce form logic to "reveal" additional questions about the Requests, at the appropriate time in the workflow to (again) only present to the user the data needed at that point (and to keep them from stressing out or getting lost if too much is presented upon opening the request form)
• if these requests might be converted into Projects or Tasks, keep 1:1 forms in synch at those object levels to preserve all custom data "as it was on the request" at time of conversion
• as folks get comfortable with submitting requests (or as Anthony mentioned, if they are already comfortable), consider moving from a general request queue to either multiple general request queues (but ensuring the top level topics are not so similar that they cause confusion), or -- even better -- moving them down to the Project level (Anthony's "mini-request queue" idea) for context

I'm sure there are others with great suggestions, and encourage folks to submit them here, too.

Regards,

Doug

@Kristin Farwell‚, can you share the link to the time tracking webinar you mentioned during this session? Thanks!