The Context List concept is probably the most recognizable feature of GTD. If a friend, family member, or coworker possesses file folders (or just about anything for that matter) bearing nicely-printed labels such as @Calls or @Shopping, it is almost certain that this person uses GTD. As simple as they seem, contexts represent aspects of personal lifestyle and can be as diverse as the people defining them. Is it any wonder that contexts spark the hottest debates in online GTD circles.
NOTE: Before spending a lot of time on next action contexts, be sure to understand how the focus of GTD is really on commitments.
A “context” list is simply a list of physical next actions that share some unique prerequisite or constraint. All that is needed for one to complete any or all of the actions on a context list is for one to choose to place oneself into that context with all the necessary resources available. The context in which an action may (or must) take place is determined early, when the action is first identified as the “next” one. A textbook example is @Calls (or @Phone), the list of actions that can be performed when one has access to a phone and the time to use it. Of course, this list will probably consist exclusively of phone calls to be made, but it is quite easy to see that the @Internet context could encompass a more diverse set of actions such as doing research, paying bills, writing emails, etc. My definition is a bit more explicit than Allen’s, but I believe that many of the common problems people have with defining contexts (see below) could be attributed to the lack of understanding that contexts must be properly bounded, that contraints are an overriding factor in their establishment.
Some Assembly Required
David Allen suggests a list of contexts in the book, and this is a good starting point, but it is not logical to assume that this list will be a perfect fit for everyone. Believe it or not, there are purists out there that try to operate using only the prescribed contexts. Times change and while people in society operate in generally the same way, people have different styles. Technology changes too. The specialized context “@Email” is different than “@Internet”, which could more properly be renamed “@WWW”, but why not “@Facebook”, “@Blog”, and “@Ebay”? Then again, is this specialization really needed? The answer is, whatever works best given a set of constraints that govern when, where, and how something should or must be done. IMHO, this is one of the most fun aspects of GTD, and yet, the most discouraging one as well.
A lot of people have posted their difficulties in using contexts and many have given up trying to use them (and sometimes GTD) altogether. There are several common issues that seem to resurface, and I’ve managed to experience every one of these in my own GTD implementation, so I can relate. This is not an exhaustive list and it may grow over time.
List Size. Many people complain that their lists get too big to manage. When they enter the context, there are too many things to evaluate, so nothing actually gets done. If lists are too few, then (obviously) each list will gather more entries given the same number of actions. This could also be an indicator that they need to place themselves into that context more often or for longer periods of time so that they can actually get more done.
Overcustomization. This is the opposite problem from the one above. Too many specialized lists will become a burden on all levels, when processing and organizing new things to do, when finding something to do in the moment, and when conducting the weekly review. The result is subconscious resistance to the system overall. Such constructs have traditionally been called “pigeonholes”. For example, as mentioned above, does one really need an “@Ebay” context list just to accumulate the list of things to consider buying from there? If I had this context list defined, am I really going to think about looking at when I’m at the computer? Or only when I have to make some other, more urgent purchase and I happen to remember to look at it? For how many other sites should/must I define context lists? There are several better ways to handle this information. The simplest would be to do away with the specialized list and add the actions to the more general @Computer or similar list, but I personally think doing this adds noise. Instead, keep a shopping list in reference and make it a habit to review it before finalizing any purchase (at a minimum) to see if anything should be added to the cart. Add a tickler reminder to review it periodically, say every two weeks; though, using the list itself as the reminder is not the best idea, since it should be easily accessible whenever random new items must be added.
Overlap. Consider the following contexts: @Desktop-Online, @Laptop-Online, @Laptop-Offline, @Office-Online…etc. These contexts were designed to avoid overlap. While it may be legit to have a task that has to be done with special software that is installed only on the laptop which also requires Internet access, this level of customization is prohibitive. In the book, Allen discusses setting up identical work spaces in various locations, at work and at home for example, and about having a mobile workspace as well. This uniformity will ensure that the necessary tools are always available, and thus, eliminate the need to specialize contexts in this manner. This may mean paying for mobile broadband access for that laptop, as if that were a bad thing.
Project Focus. Deferring an action until I’m “@Working on Project X” is not appropriate. For starters, “@Working on Project X” does not indicate one thing about the environment in which the work must take place. It’s also not efficient, because a shifting gears to make a phone call and then again to do something else, all while “@Working on Project X”, actually works against the GTD mechanism. The whole purpose for using contexts is to group similar tasks. Besides reliance on common resources (constraints), humans tend to work faster and with more consistency when doing repititious actions. Don’t misunderstand me — setting aside a block of time to focus on Project X is not a bad thing, and the quality of the outcomes for each action may actually improve if creative juices are flowing around a project, but that doesn’t mean the context is appropriate. In my experience, using a digitized system that allows me to assign each task to a project folder as well as a context is highly useful, because I can crank through the actions in times of focus (via the folder) or while in context (@Phone). They are just two different views into the same database. I’m not sure how one would accomplish this using a paper-based system without having to create multiple copies of the same action reminder to be stored in different places.
@Anywhere. “Anywhere” is a code name for “No Context”. Avoid it. Besides, “think about” is the only action I know of that can be done literally anywhere.
Non-Context Attributes. Priority, energy level, and other such attributes are not contexts. Like the aforementioned project folder concept, these are other criteria for selecting what to do in the moment. Given high levels of energy or an action with a very high priority, one will be motivated to change their context, immediately if necessary, to get that action done.
So, what do good contexts look like? What makes them work? If I had to sum it up in one single answer, it is the proximity of the contexts to reality that makes the difference. This proximity is based on constraints. I don’t want to recommend specific contexts here. Instead, I’d rather present the attributes of good and useful contexts based on my own experimentation. The list below — only two factors — is a reduction of a much longer list, distilled over the last few years.
Access. Contexts are only useful if they are accessible, that is to say that you can and do put yourself into them, preferably with some regularity. Since you define your own contexts, constraints are completely self-imposed. You have to make yourself available to get things done. In his writing, Allen often finds himself in this context or that. He happens to be running errands and wants a list of places to go and things to buy, or he happens to have an extra thrity minutes for phone calls because a meeting was cancelled. Not me. When I have calls to make, I need to go make them. I usually have to make the time, not wait until I discover it. Sometimes I have to drop what I’m doing and force myself into @Phone at 8:30 AM on a weekday, because the calls on the list are important, or someone is waiting (read: nagging me) for information that I must obtain during the call, or the list itself is just getting too long. Some contexts are more natural than others or are easy to enter because they “just happen” routinely, such as @InboundCommute. In contrast, a context that is so contrived or obscure that it is difficult or impossible to enter it (frequently or at all) is not useful, and it would be better to schedule time for such actions on the calendar instead. In the same vein, some contexts entered frequently or even routinely are just not necessary, such as @BathroomSink, @DentistChair, and @Asleep.
Resources. Pens, paper, the computer, the Internet, reference books, people, and above all, time. These are hard constraints. I can only discuss this topic @Manager or that topic @Wife. I can type this @Computer, but I have to research that @Internet. If I have made my workspaces (reasonably) identical, the same action can be done @Home, @Work, @Library, or even @Car; in this case there is no difference in the hard constraints, so why have three or four different context lists? Location is a pretty hard constraint if you let it be. When you know that you are allowed to move between contexts and not just wait for them to happen, drawing boundries between them based on resource constrints becomes much easier. If you have to decide to put an action on one of two lists, and the lists have four out of five resources in common, then you just wasted time and effort. Are these contexts really different? The answer is in the constraints. Adding gear or changing some other factor can loosen the constraints and the two contexts are now one. Defining distinctly-different contexts based on constraints and allowing only a little overlap if any at all will make it very easy to determine which context you are (or could be) in at the moment.
The following articles and posts, in no particular order, helped me understand contexts along the way. Some influenced my thinking more than others.
GTD: indentifying your contexts by Dragos Roua
Getting Things Done: A Guide To Next-Action Lists by Dan Fletcher
Setting up GTD Contexts… by David O’Hara
Customizing GTD Contexts by Help Everybody Everyday (link changes)
Hint: Ordering GTD-Contexts by Rolf F. Katzenberger
What is (not) a GTD context? by Rolf F. Katzenberger
Designing GTD Contexts by Bruce Keener
Using GTD Contexts Propperly BY Daniel Pataki (dead; available on Wayback Machine)
Why GTD Contexts Are More Work Than They’re Worth (For Me) by Charlie Gilkey
Simply GTD: Do You Really Need Contexts? by Nathan Borror
Context Simplification post on Toodledo forum
Back to GTD: Simplify Your Contexts by Merlin Mann
Using Renaissance Soul Focal Points as GTD Contexts post on The David Allen Company forum.
Toodledo and GTD by Ike O’Ramba