Holding Project - Status?

[MirandaRa1]

Hi there, I have a couple of projects that are used as 'holding' projects. 2 workflows for agile teams, where the workers control their workflow intake: 1) A request queue routes into a holding project and a team - therefore the status on the request queue is 'Queue' and the routing is to the team and the holding project. Question - what is best practice on the status for the holding project - queue, current, or something else? Also, the routing isnt required on the holding project, when already routed thro the queue, right? The routing to projects is quite new to me, so I'm trying to work out the best practice. 2) A worker uses a holding project to direct tasks to his team and to store the tasks. He sets the assignment manually when adding the task through the msOutlook plugin. In this case, what is the best status? I have it set to 'queue' in this case, as I need the routing to work (albeit if only for issues and not for tasks). I believe, this is the right way to do this, but also then wondered if tasks should be added to a queue at all....? Any info really appreciated - ty! Miranda Rais GVC

[VicAl]

Hi Miranda, I think you're on the right track. I assume a status of Queue equates to Current? If not, you probably need it to (or just use Current). Otherwise staff won't see the tasks or issues. We use Current but use a naming standard to identify the project as a holding project. We call them XXX Team Project. The "Team Project" let's me know it's holding project (or bucket project). You only need the routing if you're routing it to another holding project (or if you want an automatic assignment). We have a queue project (which displays the Request queue) then we route it to a holding project. This keeps the queue settings apart form the issue settings. But it's not necessary. We were taught this way and I like the access separation. For #2 the first part is the same answer as above. Regarding having tasks versus issues it just depends on your use case. We use them both and define them as: · Issues = Break/fix items · Tasks = Planned work or requests We do this so we know we have to pay special attention to the issues (i.e. something is broken) and we can track and report on them to see how quickly we're fixing them etc. But you may not care. Just depends on how you'd like to view and report on things. Hope that helps.