Embedded Request Queues

[AWoody]

I have recently discovered embedded request queues within projects by setting up the queue topics within the relevant template.

I currently have set up 3 options:

- upload new document

- update to brief

- request for additional work to project

The purpose of creating these is formalise the updates and ensure that they are routed to the relevant PM, rather than the extra info being randomly added in to updates or into the brief, without notifying people.

- When the new document option is requested, the document is place automatically into the documents section which can be manually placed in the relevant folder. I am happy with this.

- The request for additional work, depending on the status of the project, we could create this into a new project.

- But for the brief update, once the information is submitted - what do I do with it? I don't want to convert it to a task since it is likely that the information needs to be added into the original brief for the designer to reference when resourced. 

Does anyone use the embedded request queue process for similar requests and how do you manage the new information?

Thank you!

[KatherineLa]

We leverage that feature pretty heavily across our projects and templates. It's also a great way to wind up with trackable metrics for how often some of the extra asks are happening, which would be impossible out of update threads. Nothing really says the data has to GO anywhere, it can simply live as an ad-hoc request within the project and be closed out when completed. 

In my instance, I talk to users about the difference between 'Planned Work' (tasks in the template) and 'Unplanned Work' (handled via the project request queue). That unplanned work can be anything really, help requests from Product, data requests from another team, trouble-tickets for a system issue etc. Basically work that would be needed from a person or team not otherwise directly involved in the project, that can't be meaningfully predicted as part of the project's formal schedule. Those tickets are opened and closed by the assignees and become part of the project overall history.