My daily task list review often leaves me less than motivated to « do » my tasks. Not because I lack motivation, but mainly because I have not been diligent enough in correctly writing my tasks … I suffer from lack of task clarity. Luckily, there’s a remedy for that, and even a way to supercharge your task definition. But let’s examine a couple of common errors when writing tasks first, to understand what is underlying the problem.
Common errors when writing tasks
Error 1 – Confusing stuff capture with task processing
One of the more common errors occurs when we confuse stuff capture with task processing. These are fundamentally different activities.
Stuff capturing occurs when we get stuff – not yet treated to become tasks, hence stuff – out of our head and into a task bucket. Such a task bucket can be anything, from a piece of paper – David Allen speaks a lot about that approach – to the inbox of a full fledged piece of dedicated task management software, such as Things or OmniFocus.
Task processing is the treatment of this stuff to make it a task worth executing. I’ll describe how I do that below, but it’s important to understand there is a significant difference between the two activities.
Stuff being captured does not make it a task. When we start auto-censoring incoming stuff because we want to capture and process at the same time, we risk dropping stuff along the way and we will not be complete in our treatment. We know this at an intuitive level, and we will therefore no longer full trust our capture system, which makes it no longer relevant.
Error 2 – Task processing is not task execution
A second error, quite common as well, is to start the task execution during task processing. Of course it is quite enticing to think about doing the work while clearly defining the work, but the toolset is fundamentally different … it leads to lists of stuff captured not being properly processed, because we jump into execution all the time … but task processing, or task clarification is all about clarifying the task to both judge whether it is a task worthy of doing and defining how to best approach it, including the context. Switching back and forth between processing and executing makes for fuzzy task lists lacking a clear definition.
Error 3 – Right task execution or more busy-ness therapy
Which brings us to the third error in task list development and execution … when tasks are not clearly defined, we may be doing work that is not worth doing when we jump into task execution. We need to make sure that the task is aligned with our role, our vision and our mission, in order for us to clearly know why we are doing what we are doing and what the end objective should be. In case the likely end result does not align with our mission and vision, we should question or reasons for doing the work.
What is a well defined task?
So, based on the above, can we define what a well defined task consists of? In my mind, I have 4 criteria for a well defined task. I’ll list them, then we’ll discuss each of them in a bit more detail:
A well defined task:
- Has an easy to execute task description
- Has a clear description of how to « do » the task
- Has a clear description of the context
- Has a clear description of the anticipated end state
Let’s examine these in a bit more detail:
Easy to execute task description
Reading the task should make it clear to you, the reader, what needs to be done. Most experts agree that such a description should be verb-led, with a limited number of verbs appropriate for the job. Merlin Mann referred to these as action verbs. You can find a list below.
Clear description of how to « do » the task
Quite often, it is not enough to know what to do, but also how to do it. This is why task management software has checklists within individual tasks. Often, defining tasks which have multiple smaller steps attached as projects is one step too far. Hence, tools like Trello, Planner and Things provide you with the capability to define a list of « things to do » within an individual tasks. This reduces the administrative overhead of creating a separate project while still allowing you to create some kind of list associated with a task.
What also helps is if you write the how to as a clarification for someone else, not just you. During the execution of the task everything you worked on during the clarification needs to assist in, not detract from task execution. Yes, task clarification is actual work, not just time you spend behind the screen goofing off.
Clear description of the context
Third, the context needs to be clear for the person executing the work. The context may change and a task may no longer be relevant once it gets to execution. A context also helps in prioritising tasks.
A good way to clarify the context is by asking yourself the typical journalistic questions: Who has to do what, where, by when and why?
Clear description of the anticipated end state
Finally, it pays to clearly describe what done look like. This is certainly the case for projects, but may apply for individual tasks as well. It comes down to making the difference between ending work when it is good enough or not. And in certain cases good enough is exactly that, good enough.
It is most certainly relevant for tasks you are performing for the very first time. Describing the anticipated end state makes it clear when to stop and will help feeding the how to ensure proper task execution.
Isn’t this too much work?
This may be too much work for clear, single or recurring tasks. In cases where you clearly know what to do, when and how to do it, it probably makes no sense to bother writing these tasks out in detail.
However, while it appears a lot of work this makes sense for more complex things you need to think about first. This is measure twice to cut once … you will have to think about these tasks now in order to make them less insurmountable during task execution in the future. This remains the most effective way to clarify and crush your list.
Ninja move
There is a ninja move, which is the use of TextExpander snippets. I have snippets for task definition and for context definition, with a choice list for the action verbs I use.
What works for me?
Which brings us to what works for me. Single tasks get dragged from my in-buckets, mainly email, to my task manager.
When defining projects, I use MindNode to mindmap my projects. MindNode allows for very easy import in Things, my task manager, where I use TexExpander to enhance and clarify my tasks.
Last tip
Don’t be afraid to kill tasks that no longer make sense in your task manager. I kill tasks in my inbox in Things all the time, if they don’t make any sense anymore during the clarification phase.
Exploring The Black Box 