In Getting Things Done methodology and most other personal productivity systems, dividing projects and large tasks into the smallest tasks divisible is considered a basic, fundamental concept. These systems tell us to divide a task into individual actions until we get close to a point where we can’t break things down into any further actions. The point is to focus the brain on something small enough to tackle right away. When we write up our task lists and throw in a fairly large task or project, we’re all prone to procrastinating on the task because they haven’t been defined closely enough and we’re unsure of where to start. This concept takes care of that problem and allows us to rapidly focus and begin working right away, as opposed to beginnning after lengthy, obtuse and inefficient thought processes in an attempt to digest the topic. However, it does have an ill side effect. Focusing in on individual actions can increase the mental distance between what we’re doing right now and what the end result is meant to be. When the end result, the goal, is obscured, motivation quickly falls because—subconsciously or not—there doesn’t seem to be a point to acting anymore. Of course, the benefits to breaking tasks down into actions outweigh the disadvantages. Firstly, the motivation drain caused by focusing on small actions is far less detrimental than the motivation drain caused by trying to focus on too large or “impossible” of a task. Don’t get me wrong and assume that it’s best to focus entirely on large tasks, because it’s not—if anything, focusing too small is best. But more importantly, it’s impossible to fix the problems with focusing on too large of an area without breaking it all down—once we’ve broken our projects down, the fixes for the resulting issues are actually pretty easy. After all, we started breaking things down to solve the problem with tasks that are too big.
Where Does the Problem Begin?
The problem doesn’t begin in the project planning phase. Most often, we’ll format them something like this: So, as you’re preparing the project itself you’re reminded of the end goal at all times because the name of the project’s right there at the top of the list, and obviously, because the project itself is what you’re thinking of—and specifically, which actions are required to move towards that end goal.
- Important action one
- Important action two
- Important action three The problem begins when you feed projects into your system and take actions from several projects to form a daily task list. The context of the list changes from individual projects and over to the general scope of things that need to be achieved in a day. The end result context is thus lost and here is where we can lose sight of the goal. We lose sight of the motivating factor, which is not just a factor in our own procrastination, but the quality of the end product as well. Most task management software with a Next viewpane works pretty well. In Things, the Next tasks for each project are grouped and listed under the project names themselves. You can see this in action here (I am not really organizing a shindig and nor am I writing a book on dung beetles):
But when you go to create your daily task list, everything changes. You lose the specific framing of each task and they form one amalgamated list. Now, you could use a similar format to the Things Next pane, but then you’d be restricting the order of the tasks and also using up more vertical space on the paper. In past articles on the topic, I’ve mentioned that while I don’t mind filling up horizontal space on my daily task lists, I like keeping a bit of vertical space so the page doesn’t fill up too much and become too confusing to work with. You don’t want to think about your task list much once it has been created; you just want it to guide your day. Having to read it closely line-by-line just because you’ve packed too much in there is thinking about it too much.
The Solution I’m Trialling
My solution, which I’ve been trialling for the past week, has been to add another vertical column and indicate the project an action belongs to just next to the task description itself. I try to abbreviate it and ensure that most of the focus of attention on each line remains with the task itself, but it’s important to make those abbreviations meaningful. You don’t want to find yourself going, “What did this code refer to again?” That defeats the whole point. It has been a week and I’ve found that I’m looking at each task more as a part of a whole leading to a goal rather than individual tasks that were preset during my weekly review. It feels a lot less like going through the daily motions of getting things done and more like working towards meaningful ends. I’m not actually working on anything more or less meaningful—it’s all in the way you think about these things—but it does seem to be helping with motivation. One can’t quantify this sort of thing, but it’s working for me. However, while I’ve found a method of framing tasks within projects that works, I’m not sure I’ve found the best, most efficient way to do this. It has only been through a week’s trial, after all! Do you do anything similar to keep yourself motivated about the end goal when projects start getting a little too action-oriented? I’d love to hear about your techniques and thoughts in the comments.
