Does anyone not use a request queue?

[MelanieM1]

My company wants to remove request queues because they feel it wastes time to have to convert requests to projects.  Teams will just meet and build the project during kickoff calls.  I am wondering if anyone else is working like this, and if so, how do you manage it?  

[KellieGardner]

We have several teams that don't use request queues. They only kick off new projects and it works fine. I would only say use a request queue if they need to keep a log of "pending" requests that aren't ready to be projects yet. 

[Kiersten_K]

Hello,

We bypass request queues and have project managers create projects utilizing a project template. 

A project manager will select the appropriate project template for their marketing channel. Once they select the template, we have them fill out the project brief, provide the Planned Completion date and supply any supporting documents.

Once the project manager is ready to kickoff the project, they will change the status to Current.

Once the status is Current, our traffic operations team will review the timeline and make the appropriate creative assignments and do quick review of the brief.

Once the traffic team is done with their step, the creative team will begin the work. Throughout the project, the traffic team will work with the project manager and creative team to update any timelines if there are any roadblocks or project issues.

We have been doing this for the last 4.5 years and have not run into any issues.

Please direct message me if you want to connect further.

Thanks!

[RandyRoberts]

We don't use queues to request projects, but thats just the tip of the iceberg.

We use queues to request Workfront support, process change requests and scope changes, request article permissions, stock art and video buys, payment for guest apearances on video and communications, spend approvals from Finance, approvals on internal and non-billable projects, request new vendors, clients and users, and a ton more. Request queues are a HUGE part of what makes Workfront a great product. Don't ignore the power of asking for something!

[Kiersten_K]

Similar to Randy we do use requests for the following:

- Existing User Configuration Change

- New Report/Dashboard

- I need help with Workfront

- New Workfront Idea

- Print Production Requests

- DAM Issues

[KristenS_WF]

Our department handles a mixture of project types, and they get into WF through various methods:

• Our creative services work and other ad hoc jobs are submitted through a request queue; a portion of our Ops team then converts the requests to projects, assigns users to job roles, etc. 
• Large-scale learning initiatives/certificate programs are assigned to a dedicated PM within Ops; that person meets with the project team to determine needs/specifics and then creates the WF projects with the appropriate workflows (project creation has been largely manual thus far, but we will likely start using kickstarts for initiatives containing a high volume of similar projects).
• Learning products included in our annual plan (which traditionally get updated every year and number in the hundreds) are bulk-uploaded through a kickstart.  These projects use set workflows that are templated.  We also use reporting and Fusion to make bulk updates to these projects (e.g., add cross-project predecessors, make task assignments, etc.).

In all cases, it's the Ops team members creating the projects.  It's easier to have a dedicated group of staff who knows WF reasonably well handle this work (rather than have the individual product owners or pipeline teams worry about this).

[skyehansen]

Can I ask what you mean by "manage it"? What is it that queues allows you to manage that you think might be lost from the point of view of creating projects only?

[MelanieM1]

Sure.  I'm just concerned there will be less order.  The queues help house all the requests and the requests are worked on in the order they are submitted. A typical PM deals with multiple Requesters and the Requesters have multiple assets/deliverables.  Currently, our teams use the request queue to know what to convert next. 

Since we are moving away from centralized workflow and teams will be working in cohorts, I'm just curious how does it look when you're not relying on a request queue any longer, but all requests are now initiated in a meeting/kickoff call.  

[skyehansen]

All "requests" are now actually projects that are being initiated in the meeting/kickoff call. Teams would know what came up first based on the entry date of the project (whichever project got created first). Instead of being categorized by what queue or queue topic they came from, the team's projects could be living in a set of programs or portfolios -- or there could be metadata (custom fields) stored on the project custom form that would indicate the same sort of data that would have been indicated by a request queue.

Reports would become more meaningful. Project reports would display or be ordered by the entry date of each project, as well as have columns containing any custom fields that give added richness to a project (for example, if you used to have 5 queues, maybe you now have 5 "project types" and this is one of your custom fields). Your reports could filter on particular fields, or group by the same field, to give a sense of which cohort is assigned to a project, what type of project it is, and so on.

We use requests and queues as a way to remove the need for a meeting/kickoff call -- just fill out the form instead. The form also forces that all the information be given. We also use requests as a way to store "ad hoc" -- unplanned work, or a way to store work that only takes one person 15 minutes to do. Requests don't need to be used for everything, so it's just as well that you're listening to your users and giving some perspective to whether they need to be used at all.

[MelanieM1]

Thank you for your feedback.  You're right, reports are going to be crucial.  I'm going to recommend that we:

1. Keep request queues for smaller scale projects that don't require a kickoff meeting and Workfront related issues.  (Ad hoc projects)

2. Bypass request queues for large scale projects.  (Programs)  However, teams need to have it planned out, so PMs know what to expect and what's coming down the pipeline.

3. Need dedicated users to convert projects.  Should avoid having any and everyone creating projects.