Ok, they don’t suck. But they don’t tell the whole story, because items on a to-do list rarely provide context.
For example, take a simple task, which can likely be found on many of your to-do lists, such as “Take out the garbage”. At face value, this seems like a very obvious request. But let’s assume someone is visiting, sees your list on the fridge and wants to lend a hand. Suddenly this seemingly simple task becomes more difficult to execute. Where is the garbage can? Is there more than one? Where does it need to be taken? What day is the garbage collected? What if the bag isn’t full? What about the raccoons?!
The difficulty with most items on to-do lists is that they’re really only meaningful to the person who wrote them. This is because they can fill in the gaps by looking at the task from their perspective, with their experience, and their past knowledge of the situation. As you’ve no doubt experienced, this causes problems when to-do lists are shared within a team, when revisiting an old list of your own, or worse of all, when a list is generated by an outside body, such as a client.This is not to say to-lists can’t serve a purpose — they just need a little help.
Firstly, you must look at a task as a step to completing a grander objective rather than being an objective itself. Secondly, you need to realize that to fully understand and satisfy an objective you both the steps to completion (tasks) and the context surrounding the objective. The task list provides one component of the objective — the What. The context provides additional components, such as the When, Where, Why and Who. Given the five W’s, the How can often have many answers and can be decided upon by whoever is working on the objective.
In a future post, I’ll discuss an all-inclusive way to specify objectives for easy interpretation and execution with a greatly diminished need for prior knowledge of the situation.
4 Comments to “Why To-do Lists Suck”
Is a 2 min conversation with the person who needs the work done too old fashioned? The problem with writing everything down is a) often more effort than benefit b) still easy to misinterpret c) you won’t think of everything that needs to be communicated.
The other issue is too many items on the list. Only so much can be done, yet we talk about stuff a mile long even if there is a chance we might not get to it for a long while, if at all.
One thing that is worth writing down is the expected result. So what does it mean for the garbage to be taken out? There one could state on what day, where it should go and at what time.
My experience is todo lists, and other means of specifying requirements work best as the start, not the end of the conversation. As long as the person doesn’t have 100 other tasks to juggle, and can do the job in the near future, then talk is indeed cheap and efficient.
Gerry: The problem with conversation has nothing to do with being old-fashioned. The ability to have a conversation assumes that the task creator is available when you need the information (or at all).
Also, in reality a two minute conversation costs more than than two minutes of productivity. Assuming it’s even possible to come to a resolution in two minutes, you can not discount that enabling a conversation often requires finding a mutually agreeable time to talk, exchanging pleasantries, as well as the non-trivial expense of interrupting your workflow. Then this cost is multiplied by the number of people required on the call. A two minute conversation can easily represent 10-15 minutes of combined lost productivity. If these conversations need to be had on a regular basis as you work through your list it becomes a major issue.
You are correct, having too much information too soon is not a good use of time (this is a time saving measure after all). However, not having the right information when it comes time to execute a task is extremely detrimental to productivity. Balance must be found.
Heh the formal meeting monster rears its ugly head. The more formal a conversation has to be, the more overhead incurred. Sometimes that cost is justified by saving precious execution time later, others times not.
Agreed there is a balance in there some where. Creating space for quick chats with low overhead, at the time when info is needed can be a huge productivity boost.
I’ve seen success with working agreements that state when people agree to work together. Clients agree to be available via direct conversation, either phone, Skype and/or a team chat room. Team members agree to work together during a fixed period of time.
Look forward to more of your thoughts. Wish I could notifications of comment replies…
No, I think Adam (not me
m the author, dummy) is writing not so much about the viability of the task list, but actually the semantic meaning of it and how it should really be structured. It seems like a lot of my programming life is spent writing computers and people what are, essentially, extremely fancy task lists.