management metrics: "queue depth days"

In the manage by numbers world...

One useful measure that people take on (or have forced upon them) is management of work in progress. At every step along the way in a multi-step effort, you have something not quite done, and a level of continuous improvement involves managing and monitoring that inventory of partly done work.

If, for instance, you were looking at an inbox, you'd measure the integral of the depth of the unanswered mail queue, so that productivity is in a sum of outstanding work measured over time. End the day with 100 unanswered messages 100 days in a row, and your queue-depth-day is 10000 (eek).

There are of course three ways to attack this problem (at least, but bear with me)

1. Reduce the size of the current queue, so that there's less to deal with right now;
2. Reduce the influx into the queue, so that there's less to deal with every day;
3. Increase the speed at which things are removed from the queue, so they don't stay so long.

The inbox zero mantra pulls from all of these, but you really need to understand the impact of all three to attack this. One time heroic measures to empty the inbox are necessary, because you can't create a bunch of lasting improvement if there's a big overhang of undone work nagging at you. Slowing down flows inbound helps reduce the rate of queue depth growth, but doesn't clear the queue. And working faster to acknowledge email just creates more email!

Classic solutions to this whole system is to move communications out of queued systems into either real time systems (IM, chat, voice) or into asynchronous multiplayer games (blogs, wikis). The hard core communications people completely shut down their email system and go entirely to the other extremes; the other hard core communications people treat their email inbox AS IF IT WERE IM and always answer and file everything instantly.

The queue depth could be anything, really; it could be outstanding phone calls to make, emails to answer, people standing in line in your retail operation, customers waiting impatiently for a call back to solve their time critical problem, or forms needing to be filled out. Just know that in any system where you can get stuff coming in faster than you can get rid of it queues will form, and at worst they back up to the point where other people can see that you're not on top of everything.

Comments

[Mom]

In the "real world", not every request in the queue has the same value. Some have higher priority. Just my 2 cents - I enjoy reading your blog.

[Edward]

oh absolutely agreed that some get priority over others; there's some other measure of "time to respond" that gets different treatment depending on the message.

an observation though is that if you have 150 things to sort through, it's easier to miss the priority ones, vs. if that same queue only has 30 or 10 in it.

[Edward]

a micro-observation 20 days later:

it's useful to pull things out of queues into shared edit places, so that everyone working on the thing can deal with it asynchronously instead of all getting stuck waiting for each other.

today's exercise was to dequeue some pending correspondence and take it to a wiki.

[Edward Vielmetti]

an illustration of this problem, quoting Susan Crawford:

http://scrawford.net/blog/mr-martin/1219/

So I’m a little lost in email these days - I fell behind a month ago, and since then it’s been like those game shows where people fight to stay on their feet as large objects roll inexorably towards them. They have to jump over these things, or swim under them, or whatever, but the large objects always seem to win. That’s me and email right now.