Must Do, Should Do, Could Do
Friday, October 27, 2006 at 14:29 There's a well known method of prioritising which I refer to in my first book Get Everything Done and Still Have Time to Play, which consists of prioritising one's To Do list in terms of what must be done, what should be done, and what could be done. I pointed out in the book that this only makes sense in terms of a specific time period. It is very useful when for instance one knows one is going away on holiday at the end of the week. What must be done before then? What should be done? Another situation would be where one's plans have been upset by an emergency and one has much less time to get something organised than one was expecting. Listing everything and applying these questions can quickly restore a sense of control.
But I also made the point that as a method of prioritising it has its limitations, and therefore cannot be used all the time. This is because it is rare to get further than half way down the "should do" part of the list. Since there's a constant supply of new must dos and should dos, the could dos never get a look-in. This probably doesn't matter much with some of the items that find their way onto the list. But if I think of all the things I could do to improve my business and never do any of them, I'm not likely to get very far.
So I have tended to dismiss this method of prioritising apart from the strictly limited uses I mentioned in the first paragraph. But recently I have been having another look at it, to see whether it could be adapted to make it work better.
If time management is about managing our workflow - which is essentially about managing a queue, then this could be adapted in such a way as to make the queue work better. The aim of a well-managed queue is to ensure that everything in the queue gets dealt with within a reasonable time frame. With a badly managed queue or no queue at all some things in the queue get dealt with quicker than they deserve and some things much slower (or not at all).
It struck me that if we have a queue of tasks awaiting our attention, they fall naturally into three different classes:
Tasks that need dealing with quickly and cannot wait their turn in a long queue. These would correspond to the "immediate" and "same day" degrees of urgency in Do It Tomorrow. Pretty obviously these fall into the Must Do category, if we define the time period as today. They are the things which must be done today.
Tasks which should be done every day. I have quite a number of tasks that fall into that category. To be precise, my current list has 21 items on it. I should deal with my email at least once a day, I should clear my paperwork at least once a day, I should back-up my files at least once a day, I should make a blog entry at least once a day, and so on. The operative word is "should". They don't get done every day if time is short, but that's the aim. This type of recurring task obviously falls into the Should Do category.
The third type of task I have is all the myriad tasks which don't have to be done today, but it's necessary or advantageous that they get done sometime. They may or may not have definite deadlines. These are the sort of items which get put on to do lists and stay there for day after day, week after week, until they either get done because of the pressure of the deadline or they get crossed off the list in frustration. The one thing that unites these tasks is that they don't have to be done today.
Now if they don't have to be done today, what is the best order to do them in? This is where most systems of prioritising fall down. Whatever system of prioritising you apply to the tasks in the queue will result in some being done and some not being done. The purpose of a queue however is to ensure that everything in the queue gets dealt with. And what order do things get dealt with in a standard queue in order to achieve that result? In the order they join the queue of course.
So for the third category Could Do, the rule is to do the items in the order they appear on the list. If something gets so urgent that action can't wait, then all that has to be done is to transfer it to the Must Do category. But there's no need to do that before it's necessary.
So how have we improved this priority system so that it will work as a method of day-to-day prioritising? Rather than just have three undefined categories called must do, should do and could do, which are nothing more than subjective assessments, we have now carefully defined the contents of each group as follows:
MUST DO. Defined as tasks that MUST be actioned today. This means what it says. If the item could be actioned tomorrow instead of today without a significant downside, then it should not be in this category.
SHOULD DO. Reserved for recurring daily tasks only, i.e. tasks that should be done every day. (But note that tasks that MUST be done every day should be in the first category). Non-recurring tasks are not permitted to be in this category.
COULD DO. Everything else. These must be done in strict list order. If they become so urgent that they can't wait any longer then they are transferred to the MUST DO category.
In the main this system would adhere to the principles given in my book "Do It Tomorrow". The biggest difference would be the way that tasks are deal with. Instead of putting them in a Task Diary to be dealt with on a day-to-day basis, you would be putting them into an open list and dealing with them in strict order. However an open list in which the items are dealt with in strict list order doesn't suffer from many of the disadvantages of an open list in which the items can be selected in any order.
The danger of course is that the queue of items in the COULD DO list would grow and grow until it took weeks for any item to get actioned. So keeping the list under continuous review would be essential.
The system lacks some of the checks and balances of Do It Tomorrow, but might be attractive to someone who prefers a more open-ended system.
Reader Comments (8)
What I wanted to show in the article was how one could improve a "traditional" method of prioritising by applying Do It Tomorrow principles. Doing so has greatly improved it, and as it now stands it could be of interest to someone who wants a simpler system than Do It Tomorrow.
But it's important that you don't forget that you need to be able to catch up within a couple of days.
I suggest that the best way would be to break the project down into smaller tasks and schedule them forward, a few tasks at a time.