My Latest Book

Product Details

Also available on,, and other Amazons and bookshops worldwide! 

To Think About . . .
Think big and act small. Leslie Koch
My Other Books

Product Details

Product Details

Product Details

Product Details

Click to order other recommended books.

Find Us on Facebook Badge

Search This Site
Latest Comments
« Scrybe: The new standard for personal organisers? | Main | Seven Way to Leave the Office Earlier »

Must Do, Should Do, Could Do

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)

How does this improve upon DIT?
October 28, 2006 at 22:29 | Unregistered CommenterSharky
It doesn't improve on Do It Tomorrow. It lacks several important aspects, most significantly the ability to tie one day's incoming work to one day's outgoing work.

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.
October 29, 2006 at 22:32 | Registered CommenterMark Forster
Great, thanks for the clarification. I was thinking maybe using the approach for executing my "will do" list. This way, if you didn't complete your tasks, you would still have finished the "must do's".
October 30, 2006 at 0:30 | Unregistered CommenterSharky
Yes, that would be a sensible way of dealing with the Will Do list, particularly on days in which you know that you are not going to have very much time available to action it.

But it's important that you don't forget that you need to be able to catch up within a couple of days.
October 30, 2006 at 11:02 | Registered CommenterMark Forster
Where does a large project with a distant deadline fit (the organisational type as defined in DIT)? A large project with many tasks could easily flood the "could do" queue if you followed a first in, first out policy. Would it be better in the "should do" queue, do a little of the project every day?
October 31, 2006 at 20:56 | Unregistered CommenterLeo
It's a good point you raise, Leo. Whatever system of time management one follows, it is important not to overwhelm the system with too many things at once.

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.

November 1, 2006 at 19:08 | Registered CommenterMark Forster
Reminds me of A&E triage - but for tasks.
November 1, 2006 at 21:31 | Unregistered CommenterDickie
A&E triage is a good analogy. After all time management is basically about managing a queue.
November 2, 2006 at 10:17 | Registered CommenterMark Forster

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.