But that means that when I'm at the phone and I run down my @ Phone list, I'm making a call related to project A, then one regarding Project B, then Project C, etc.

The problem is that every time that I have to switch from one project to another, I have to take out a file (both physically and in my head!) and switch over to its contents. Refocusing is a huge time waster! I have to stop thinking about Project A and refocus on Project B.

Wouldn't it be a lot easier to devote a solid block of time to just one Project (i.e. Project A)? Who cares that it involves work on a laptop, a phone call, and walking down the hall to talk with a colleague? Maybe I would have to delay some NAs until I'm back at the office or in front of a laptop, but I would get more done because I would be focused on one project.

But once you've gotten everything out of your head and onto paper, isn't switching between projects the biggest reason for lost productivity?

Why not just work from a project-oriented list of NAs rather than sort them by Phone, Computer, Desk, etc.?

Whatever works for you. For some people, it's easy to handle a bunch of phone calls all at once, whether they are related to the same project or not. For some, it's easier to stay focused on one project, even if it crosses several contexts.

The GTD idea of contexts fundamentally assumes that when you're in a given context, you won't necessarily have access to any other tools. Phone calls (for example) might be all you're able to do. Having all your phone calls together makes it easier to be productive during that time. If that assumption doesn't apply to your situation, then you may need to define your contexts differently.

Of course, there's also no rule that says you have to work off your context lists. You might start by going down your @phone list, make a call, and then decide there are a bunch of other things you need to do while you have the Project A folder out, some of which might not even be on your NA lists at all. The lists are just there to make sure things don't slip through the cracks.

Good luck,

Katherine

Comment

Just because it's a phone call doesn't mean it goes on the @Calls list. The kind of calls you are describing are likely the kind I would see in my @Office context. Mainly because I need my project files in front of me in order for the call to be meaningful.

So your lists might look like this:

@Office
Call Bob 555.5555 re: scope of work for project A
draft status report for project B and email to John

Your @Office calls probably require that you have your key project information at hand, and likely in mind when you make the call, thus it's best to work on these in a more focused context.

Your @Calls list is there so when you're waiting in line at the grocery store with your cell phone and your palm you can knock off a couple of items and move things forward.

You are right about one thing. When taken to extremes the GTD process can result in behaviors that are unproductive. Task Switching (between projects not contexts) can be very unproductive. GTD was not designed to be this way. The key is that these decisions must be made either when processing your inbox or when doing your weekly review. Sometimes these decisions are more difficult than they would seem.

Why not just work from a project-oriented list of NAs rather than sort them by Phone, Computer, Desk, etc.?

Thoughts?

Scott,

@Phone and others are really just examples. Contexts can be more than just resources. Resources lend themselves well as contexts if your projects are very similar in structure, so that batching of similar tasks (like phone calls) makes sense.

Consider contexts as intersections of resources, places, people etc. in your life that occur frequently - contexts give you a chance to get something done "there", repeatedly.

Trust your instinct: as you mentioned, if you see a fair amount of diversity among your projects, then using resources as contexts doesn't work that well. Resorting to old-style project-specific lists however completely defies GTD, because you can't find immediately what you could do right now. There are better alternatives - I've listed a lot of context types in my blog, under What is (not) a GTD context?.

Comment

David describes the 4 criteria model to help you decide what to do next:
Context
Time Available
Energy available
Priority

Context is just one of the criteria.

If you walk in your office in the morning and you have no meetings planned, no phone conferences and no deadlines then you have absolute freedom to decide what to do that day. It is perfectly ok to call customer A to discuss the scope of the project; then you use the input from your client to brainstorm on the project, ... If you want you can spend all day on that project. If you decide that that is the most important thing to do. In this case, you will hardly look at your context lists.
Also when you are on an all day off site meeting with a customer, you will hardly look at your context lists. Your focus will (should) be on that customer.

So, when to use context lists? I find them very useful for 2 reasons:
(1) to remember what to do next when I pick up a project again: what is the next step here: did I need to draft a report? Or do I need to download some data before I can start? Or do I need to call someone to get the data... In this case it is not the context, but the next action that is important.
(2) to make the best use of the small windows of opportunity: a phone conference ends early and you have 15 or 30 minutes to spare. Instead of running through all your projects to see if there is something that you might be doing in this time, you already have a complete list. And it is sorted by context: this helps you reduce the list of items to scan. If you are not in the office, you do not have to check the @office list. If you are on the road and the battery of your mobile just died, forget the @calls list.
The benefit is that you do not have to think about what you could do. You need to think about about what you can do. I find that that makes a big difference.

Summary: context lists are helpful, but not the only source for deciding what to do.

br,
beyerst

Comment

Wouldn't it be a lot easier to devote a solid block of time to just one Project (i.e. Project A)? Who cares that it involves work on a laptop, a phone call, and walking down the hall to talk with a colleague? Maybe I would have to delay some NAs until I'm back at the office or in front of a laptop, but I would get more done because I would be focused on one project.

Agreed. That's why I schedule my project related work. For these projects I have files, fotos, and other stuff. Having lists of the actions to do for these projects is the easied way to go, for me. Doesn't matter how you call these project-oriented list, eg. actions plans, or checklists, or whatever.

On the other hand I have tons of small mini-projects (I like to call them 'work packages') for which I don't have any files, only one email here and a written note there. Usually they don't make it on my projects list, because they get finished before the next weekly review. And during my daily reviews I simply scribble the next actions for those work packages into the two context lists (@work and @home) on tomorrow's page of my paper notebook and then do it tomorrow.

Comment

I can understand the benefit of working continuously on "Project A" when I'm in the right place, such as at home or in the office where there is a phone, laptop, and coworkers around me. But I can also see the benefit of just returning phone calls from all projects at once, because I'm in the car, on a train, I'm picking up the kids etc. and all I have is a phone.

Is the solution to list all my NAs in TWO contexts -- one for @Phone or @Laptop, and another under Project A, Project B, etc.?

Comment

Is the solution to list all my NAs in TWO contexts -- one for @Phone or @Laptop, and another under Project A, Project B, etc.?

I don't think so. Duplication makes the system harder to maintain.

I would say the solution is to have clear information in the project support materials, and to limit your NA lists to only immediately doable next actions. YMMV, but I find that when I have a block of time to devote to a project, I usually get the Next Action done pretty quickly and then find myself working on stuff that wasn't on my NA lists at all (because it wasn't doable), but is in the project plan. See discussions on this board about NA lists as bookmarks, rather than comprehensive To Do lists.

Comment

I find that @ context lists are most valuable as a tool of productivity and not the be-all and end-all of productivity. It helps to have a sense of your priorities and then to work your NAs according to that. Frequently I'll start with a context list but will then more likely work on a project and then back to a context list and to a project, etc. For example, I won't do all items on a particular context list because many NAs are best done when I'm at my most productive or least productive, or not during business hours but during after-hours, etc., etc.