Priorities Don’t Deliver – The Only Thing That Matters Is Agreeing On A Delivery Date

When someone delegates a task to someone else it’s common business practice for the requester to assign a priority (high, medium, low) to the task.  It’s done all the time, in email messages, task assignments, yearly goals, etc.  The priority is a signal from the boss that the “top” priorities are most important to him/her, and they are expected to be done ahead of others.

This practice has less value than we think.  Assigning priorities to task assignments does not drive better outcomes – i.e. does not assure that the right things get done at the right time.

What good is it to have low priority items that we know will never get done? They’re cluttering some list, but, if truth were told, they’ll never get done.  We’ve made a record of them, but we just don’t have the courage to delete them.  On the other hand, what good is it to have numerous high priority items, with more being added each week?  Before you have completed the list, another “top priority” item is added.  In the end, you can only work on one at a time.

In the final analysis, priorities don’t really drive delivery very much.  Due Date is the only thing that drives delivery.

So, when you want to get something done, don’t specify the priority, ASK the intended performer for a delivery date.  And I do mean ASK.

This practice is so much different than ASSIGNING a priority and a due date.  The actual conversation should be a REQUEST not an assignment.  You are ASKING a performer to execute some outcome and ASKING when they can commit to deliver it.  Delivery date is the only thing that really matters.  A high priority item that won’t be delivered when needed is useless.  And just adding a low priority item to a long list of tasks that will never get delivered is also useless.  Juggling several “high priority” items should not be left to the performer’s discretion.

Instead, make a clear REQUEST, and ASK your performer when they can deliver.  Sure, in making the request it’s good to communicate about the relative importance of the task, but just assigning a priority has only limited value in the decision-making of the performer as to what to do next.  In response to the REQUEST, the performer looks at what’s already on their plate, considers a series of factors (e.g. urgency, intuition, personal interest, political value, career advancement, difficulty of accomplishment, etc.) and responds with a proposed delivery date.  If their response is not soon enough, some negotiation of delivery date may be appropriate.  But in the end there is an AGREEMENT about a delivery date.  This is all that matters.

This practice seems so obvious, but it is surprisingly rare.  Instead, we persist in assigning work and giving out priorities.  It kind-of works, but it is very inefficient.  Let’s have better conversations and make clear agreements.  Requesters should drop the notion (or at least rely a lot less on it) of assigning their priority to the request, with the implicit assumption that high priority items get done first.  Instead, both parties would be better served by focusing on obtaining an agreed due date (regardless of what priority the requester or the performer may have in mind).

Next generation task management systems will focus on forging agreements around delivery dates, not on assigning priorities.