Workflow and ticket/task visibility

One problem I frequently run into while using RT is the issue of
"workflow". There are “priority” levels, but when you have a task that
has multiple people involved, it would be useful to have multiple ticket
owners where when one task is completed, it’s automatically punted to
the next person to complete (the key being visibility).

Yes, you can just re-assign the ticket - but sometimes that’s not
politically pleasant (office politics).

A generic example: I’m asked to upgrade a server software component
(product) that is used internally for which I have no other involvement;
dev people are responsible for testing and Q/A of the install. I get a
ticket to perform the update, I report this update as being completed,
but never receive a response or approval that they found the work
acceptable. So, I just close the ticket.

This creates several problems, some of which are connected to the
absence of a workflow process.

Anyway, I wonder how others in differently-sized organizations handle
this type of issue within the RT framework.

We are now testing a ‘kanban’ system internally, to see if that will
help with some of these processes.

Thanks…

I designed a workflow for server installation while at the Stanford
Linear Accelerator (SLAC), which I contributed to the RT Wiki:
WorkFlow - Request Tracker Wiki.
It consists of a master ticket for the tasks, child tickets assigned
automatically to the responsible groups for subtasks, and
updating of the parent ticket as the subtasks are completed.
A saved search gave a dashboard of all outstanding tasks
and where they stood in the process. Is that the sort of thing
you are looking for?
-Chuck
Chuck Boeheim [::] CIT [::] Systems Services
Cheap hardware isn’tOn Mar 23, 2010, at 7:10 PM, Forrest Aldrich wrote:

One problem I frequently run into while using RT is the issue of
“workflow”. There are “priority” levels, but when you have a task that
has multiple people involved, it would be useful to have multiple ticket
owners where when one task is completed, it’s automatically punted to
the next person to complete (the key being visibility).

Yes, you can just re-assign the ticket - but sometimes that’s not
politically pleasant (office politics).

A generic example: I’m asked to upgrade a server software component
(product) that is used internally for which I have no other involvement;
dev people are responsible for testing and Q/A of the install. I get a
ticket to perform the update, I report this update as being completed,
but never receive a response or approval that they found the work
acceptable. So, I just close the ticket.

This creates several problems, some of which are connected to the
absence of a workflow process.

Anyway, I wonder how others in differently-sized organizations handle
this type of issue within the RT framework.

We are now testing a ‘kanban’ system internally, to see if that will
help with some of these processes.

Thanks…

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com