Back at the beginning of September, I wrote about my transition from an electronic to a paper system: http://www.davidco.com/forum/showthread.php?t=5803
Like everyone else's, my system evolves, and a few people have asked for updates on the transition. Since I just finished my monthly (and weekly) review, I thought this was as good a time as any for a few comments.
In general, paper is working well for me. I was especially happy to have it over the last two weeks: I switched from a PC to a Mac, which resulted in a period of limbo while I figured out what Mac software I wanted to use, installed it, moved data over, and so forth. Having a paper system helped me contain the disruption. If you have an electronic system, you might want to plan how to deal with service outages in advance.
One of the most dramatic changes I made was using projects as contexts. That turns out to not be such a great idea, for two reasons. First, I found that my project NA lists were filling up with "stuff," such as subprojects and project plans, not immediately doable NAs. My brain wants to put everything related to a project in one place, whether it's a true NA or not.
Second, the premise turned out to be false. My premise was that I work on projects in big chunks, so scattering NAs for the same project across several context lists didn't make sense. Yet it often turns out that, just as I can move several projects forward by spending an hour making phone calls, I can move several projects forward by sitting down with Google for an hour. Having all my research questions in one place is just as helpful as having all my phone calls in one place. Conversely, once I'm focused on a project, the fact that all the NAs might *not* be right in front of me isn't really a problem. If I've kept good project support notes, I can either work from those or, at worst, be reminded, "Oh, yeah, I needed to do some research on this," and flip to the appropriate context list.
The other reason for treating projects as contexts was the eternal "how do I link NAs and projects?" question. The answer, it turns out, is that I don't need to. If the NA is clearly stated, it's obvious which project it belongs to. Similarly, if the project plan is clear, I should be able to able to make progress without referring to my NA lists at all. Sure, working from one or the other alone might mean that an action gets done (or rendered obsolete) without being checked off, but who cares? That's what the Weekly Review is for. Sure, some projects may have particularly time-critical components, or steps that must be done in a particular order, but a trusted system should make those constraints obvious.
DA touched on this idea in the recent DA/Merlin Mann podcast, in which he was fairly unkind about people "whining" (his words) about ways to maintain the project-action link. He certainly didn't earn any points for diplomacy, but I'm coming to believe he was right. If you really need an explicit link, the real problem might be some other leak in your system.
Anyway, my new and improved paper system consists of the following:
DayTimer two-page per week desk size planning calendar, with tickler inserts and abbreviated project list.
Letter size Circa notebook, contains project lists, project plans, someday/maybe lists.
DayTimer two-page per day pocket size calendar, used as a time log and for portability.
Journal size Circa notebook, contains NA lists by context.
Current contexts are: @Brainstorm, @Computer (mostly administrative stuff, like database searches or installing new software), @Dragon (I use Dragon Naturally Speaking to capture drafts from paper), @Edit, @Email, @Errands, @Home (Non-office home tasks), @Office (desk needed, but not computer), @Online (online purchases, research questions), @Phone, @Plan, @Read and Review, @Write.
Addresses remain electronic. Calendar is primarily paper, though items with extensive electronic support materials -- like conference calls -- may have an electronic entry as well.
I hope this long description is helpful. I always learn from reading about other people's systems, so I thought I'd share.
Katherine
Like everyone else's, my system evolves, and a few people have asked for updates on the transition. Since I just finished my monthly (and weekly) review, I thought this was as good a time as any for a few comments.
In general, paper is working well for me. I was especially happy to have it over the last two weeks: I switched from a PC to a Mac, which resulted in a period of limbo while I figured out what Mac software I wanted to use, installed it, moved data over, and so forth. Having a paper system helped me contain the disruption. If you have an electronic system, you might want to plan how to deal with service outages in advance.
One of the most dramatic changes I made was using projects as contexts. That turns out to not be such a great idea, for two reasons. First, I found that my project NA lists were filling up with "stuff," such as subprojects and project plans, not immediately doable NAs. My brain wants to put everything related to a project in one place, whether it's a true NA or not.
Second, the premise turned out to be false. My premise was that I work on projects in big chunks, so scattering NAs for the same project across several context lists didn't make sense. Yet it often turns out that, just as I can move several projects forward by spending an hour making phone calls, I can move several projects forward by sitting down with Google for an hour. Having all my research questions in one place is just as helpful as having all my phone calls in one place. Conversely, once I'm focused on a project, the fact that all the NAs might *not* be right in front of me isn't really a problem. If I've kept good project support notes, I can either work from those or, at worst, be reminded, "Oh, yeah, I needed to do some research on this," and flip to the appropriate context list.
The other reason for treating projects as contexts was the eternal "how do I link NAs and projects?" question. The answer, it turns out, is that I don't need to. If the NA is clearly stated, it's obvious which project it belongs to. Similarly, if the project plan is clear, I should be able to able to make progress without referring to my NA lists at all. Sure, working from one or the other alone might mean that an action gets done (or rendered obsolete) without being checked off, but who cares? That's what the Weekly Review is for. Sure, some projects may have particularly time-critical components, or steps that must be done in a particular order, but a trusted system should make those constraints obvious.
DA touched on this idea in the recent DA/Merlin Mann podcast, in which he was fairly unkind about people "whining" (his words) about ways to maintain the project-action link. He certainly didn't earn any points for diplomacy, but I'm coming to believe he was right. If you really need an explicit link, the real problem might be some other leak in your system.
Anyway, my new and improved paper system consists of the following:
DayTimer two-page per week desk size planning calendar, with tickler inserts and abbreviated project list.
Letter size Circa notebook, contains project lists, project plans, someday/maybe lists.
DayTimer two-page per day pocket size calendar, used as a time log and for portability.
Journal size Circa notebook, contains NA lists by context.
Current contexts are: @Brainstorm, @Computer (mostly administrative stuff, like database searches or installing new software), @Dragon (I use Dragon Naturally Speaking to capture drafts from paper), @Edit, @Email, @Errands, @Home (Non-office home tasks), @Office (desk needed, but not computer), @Online (online purchases, research questions), @Phone, @Plan, @Read and Review, @Write.
Addresses remain electronic. Calendar is primarily paper, though items with extensive electronic support materials -- like conference calls -- may have an electronic entry as well.
I hope this long description is helpful. I always learn from reading about other people's systems, so I thought I'd share.
Katherine