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.

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

  1. Pingback: Tweets that mention Priorities Don’t Deliver – The Only Thing That Matters Is Agreeing On A Delivery Date | Conversations about Commitments --

  2. John Strickland

    David’s observations are spot on. I might add that commitments become even more reliable when the requester helps make sure the commitment is sound, rather than simply pushing for the answer they want to hear. It is not at all uncommon for people to commit to a date without really making sure they can deliver. This is especially true when there are multiple commitments on the table. It is very common to visualize they can meet any of the promised dates, but not consider the cumulative effect of trying to meet them all. In other words “I can do any of these things, but I can do all of these things”. A good customer of the commitment conversation asks questions to make sure that the promiser has the resources, authorization and other factors to deliver upon the request.

  3. John,

    I concur. Your comment spurred some further thoughts.

    The process of forging the original agreement is VERY important, and it has several key aspects and subtle ingredients. As we have said, first the requester ASKS. But, to be precise, what they ask for is a commitment, a firm delivery date. Asking for a firm commitment encourages the performer to do three things: (1) Check to see exactly what are the expectations of the requester. The performer seeks to understand and refine the quality and expectations of the request. This leads to better requests. (2) Check to see what other commitments the performer has already made that could impinge on their delivery date (i.e. your point). (3) The performer shares more details about the resources, dependencies, availabilities, and concerns they need to address in order to solidify their commitment. This informs the requester and promotes joint problem solving from the start. In other words, the whole quality of the negotiation dialog between the requester and performer has taken a big step up and both parties now take a share of the accountability for a successful outcome. The whole notion of a NEGOTIATED COMMITMENT is key.

    Lastly, to your point about the performer overbooking themselves, wouldn’t it be great if the performer had a working list of all the commitments they’ve already made that they could reference at a glance. Please pardon the plug, but that’s exactly one of the features of our software application.

    Good dialog here. Thanks for the comment.


Leave a Reply