Making a request from within a project - how do you handle this?

How many legacy projects do you need to add the request queue to? I believe I have a solution, but it is a bit of a manual entry.

You can duplicate your new project template with the request queue built in and then remove all the extra data:

• tasks
• custom data
• permissions
• anything not related to request queues

You can then use that blank template as a sort of "request queue patch" template. When you attach it to an existing project you will get all the topics, routing rules added to the project (but be careful, you should only do this once or you will end up with duplicate topics in your request queues). I have done this before but only on a "on-demand" basis (or you can train Planners to attach it themselves).

Exactly - the duplicate queue topics are what kills me. Also, adding the queue to about 12 templates is rough, and then every time someone wants to add another topic, updating them all is a killer. I'm struggling with this from a time management view. It's all do-able, just so time consuming.

Hi Jill,

First:

Can you provide a link to the Innovation Lab entry for "more easily attachable request queues" so I can make sure I've upvoted? ;-)

Second:

Our solution to this issue is all requests, even scope creep and addendums, always go through the master request queue. Then the request can be converted to a task on an existing project. The upcoming feature to allow custom forms to be shared across objects will make this a tad less clunky and allow better data capture (since we decided not to duplicate project custom forms to task custom forms).

This method was opted for because all our admins are part-time and we have to choose simplification and standardization over ultra-customizing. We can only realistically maintain so much and anything with high maintenance needs couldn't be used.

I had the presence of mind to see the issue of embedding request queues in invividual templates and projects as a huge maintenance issue while we were working with WF on the initial deployment. So we just created one project that serves as our sole request queue. From there, planning teams are required to convert to projects and tasks and needed.

Even this became an issue with requesters (too tedious) so our next step is instead of dozens of requesters, we are going to put 3–4 points of contact in front of WF. Requesters consult with those folks, and only those 3–4 people put in requests.

Here is the innovation lab: https://one.workfront.com/s/idea/0870z000000PSKOAA4/detail

Converting a request to a task in a project is an interesting idea, I will ponder on that. Thanks!

Hi Jill, Kevin, and Connor,

I'm interested in scoping out how and when me might add Queue Topics, Topic Groups, and/or Routing Rules to our Sync Template solution during our April 1 Template Maintenance Workshop, so if you'd like to join me to do so, invite you to Register.

Regards,

Doug

Hi Jill - we're also using embedded request queues in project templates to keep related work together, and I share your pain as it's quite a manual process to make any changes across multiple request queues and multiple project templates. :) Just to throw a related idea to the group: Idea: Abiity to bulk-edit request queues in project templates (workfront.com). I am also interested in Doug's Sync solution. As Connor mentions above, we also have a blank template as a "request queue patch" template that project owners can attach to their projects as needed, but it does take repeated user communication and training.