Making a list of next actions can be motivating, but then there’s the reality test. When it comes time to decide what to do next, every option on the list may look as unappealing as the others. While it’s unrealistic to assume that every task we need to do will be something we just can’t wait to do, it’s equally unrealistic that out of a dozen or more tasks, nothing on the list seems doable. There are a few systemic errors that people make that cause them to gradually become disengaged from their task management system.
The list isn’t reviewed regularly. In this case, it’s not the list that’s the problem, but the fact that the brain knows that the list won’t be examined on a just-in-time basis, forcing the brain to pick up the slack by holding onto the list in memory, defeating the purpose of writing the list down in the first place.
By regularly I mean whenever you’re in the physical context of the corresponding list — as opposed to reviewing the list mentally. When you’re at home, you don’t think about what to do next; you look at your @Home list. Looking at the appropriate list when it’s time to decide what to do next should be as automatic behavior as looking at a clock when wondering what time it is (notwithstanding those brave souls who’ve trained themselves to correctly guess the time).
The list isn’t sufficiently granular. This is where “next action” is actually a multiaction task, like “Purge book collection” instead of “Tag unneeded books.” Without first separating the books to purge from the books to keep, the tendency is to look at the book collection as a whole and resist following through on the purge. It would be more effective to put “Purge book collection” on project list — the list of successful outcomes — and track the more precise next action separately.
Defining next actions is an art, not a science. Some people would consider “Write article” a next action. I would never use “write” as a next action, since it congeals a number of preliminary tasks: reading a manual, calling someone for an interview, outlining the article, or drafting it. On the other hand, “Boot laptop” would be ridiculously minute. We’re looking for next actions that are sufficiently, not absolutely, granular. If you find that the project is still on your mind after defining a next action, reexamine the next action as you’ve defined it and see if it has an unidentified dependency.
The list contains legacy issues. One reason a next action might have been sitting on a list for weeks is that the reason for doing it no longer applies, or the context has changed. Circumstances can evolve so subtly that it can take an act of will to notice the drift. Maybe an increase in gas prices has made that road trip less appealing than it seemed a month ago. Maybe its becoming clearer that upgrading a piece of software that works perfectly fine is just creating activity for its own sake.
Once it becomes evident that the project or action is past its timing, don’t let it sit on your list. Save your project and action lists for genuine commitments that you’ll respect and honor. Just because you commit to something now doesn’t mean you’ll have reason to stay the course five minutes from now, especially given the rapid flow of information in most office environments.
The list contains considerations, not just commitments. If an action list contains things you’re still thinking about doing, you’ll start viewing the whole list as a menu of deliberations. The reason an action list contains more than one action is that it’s impossible to do more than one at the same time. But this list is for tasks you actually intend to do as soon as possible. Some people force this intentionality by limiting their list to two or three “most important” tasks, but this can lead to tracking “less important” tasks mentally. The best practice is to use your list to track everything, but to focus on the one thing you’ve picked from it at that moment.
There’s nothing wrong with deferring things or continuing to evaluate them, but designate their status appropriately so that the trusted system that you keep outside of your head is actually trustworthy. That might entail putting the item up for reexamination five weeks from now on your calendar or in your tickler file. Or it might mean putting it on a list called “Someday/Maybe,” “Incubate,” or “Pending” that you review weekly.
The list is overpopulated. Having 30 items on a list makes it difficult to conveniently scan through the entire list with complete attention. See if you can sense an upper limit of how many tasks you can look at without glazing over. If you find that you’re only looking at the first half of your list, then functionally that first half really is the list. This may involve deferring actions, delegating them, or reevaluating whether or not they need to be done at all. To have a an agile system, you need to be able to take things off of a list as rapidly as you put them on.
The written list competes with a mental list. For me, this was probably the most insidious bug in my list management. Even though my next actions were accurate and written down, my lifetime habit of thinking about what I need to “get done” each day instead of what I needed to do at that moment meant that I when I read the next action (the “do”), I was still thinking on a project level (“get done”). Since it’s only possible to do an action, not a project, I wasn’t taking the action list seriously.
Referring to “virtual” lists in your head is something you have to catch yourself in the act of doing, since our sense of what we need to get done each day is like a second skin. We need to make the choice to either operate from mental RAM or a trusted system, which means shedding that second skin. To keep a clear head, it’s better to err on the side of obsession at first and review you action list whenever you start to doubt that what you’re doing at the moment is the right choice. But this only works if your list is complete, not prioritized, in order to reaffirm that the actions you’re not doing are the ones you shouldn’t be doing.