Tuesday, September 6, 2011

Keep it simple: Ticket workflow

A lot of tracking systems have very complex ticket workflows.

These are often designed to prevent mistakes, but I've found that they often add too many steps to the process, which people eventually ignore.

With PMRobot, we decided to go a different direction, and limit ticket states to:
  1. Open - There is work remaining
  2. Resolved - The person who did the work believes it is completed
  3. Closed - The person who submitted the ticket confirms it is completed
  4. Blocked - Work cannot continue due to an external factor (used sparingly)
There are a few common states we decided to leave out since we didn't feel they added sufficient value. Here's why:

New: This is an an open, unassigned ticket. Why add an extra step?

Accepted: This isn't much different than an open, assigned ticket. Again, we don't see a lot of value in adding this extra step.

In progress: This is a useful state to have, but often isn't used correctly. People often mark ticket in progress and then forget about them. Instead, we tend to use time logs and auto-scrum to track what is currently being worked on.

Reopened: This doesn't seem to add much value over the 'open' state. We track and display the number of times a ticket has been reopened, but don't feel it requires a separate state.

What about your process? Do you use states I haven't listed here? Tell us about your experience with ticket workflow.


  1. What are all the things you are using the states for?

    - Are they used solely as an indicator of the current progress of a request?

    - Do the states and the times spent in them need to be used for gathering any metrics about things like lead-time, cycle-time, work-in-process?

    - Do they get used to help quantitatively observe and manage trends (good and bad) ...

    - and figure out what kinds of activities should be focused on most for optimization or removal? ...

    - or for giving more information/visibility to senior management about cause/effect?

    It really all depends on what the organization using the tracking system needs, and what they need it for. They should certainly keep states to a minimum, but they may also have more needs than are met by the (possibly oversimplified) list above too.

  2. Hi Brad,

    I agree there needs to be a balance, but I've also found that at the beginning of projects, there is an eagerness to track a lot of things. Then, as the project progresses, and deadlines start looming, all of the little "extras" become less important than getting the actual work done.

    We've tried to focus on keeping the PM overhead as low as possible and letting people focus on their work.