Need Help Wrapping My Mind Around Paper Based GTD

[andyphickman]

I cannot understand how GTD works in a paper-based system. Do you really not write your next actions for a particular project on the same piece of paper with that project name? How in the world do you view all the next actions for a particular project without have to selectively scan your "next actions" list and sift out all the other unrelated tasks?

The only way I can think of being able to view tasks by both context and project is by doing the following:
1. Capture stuff
2. (Clarify) While clarifying, realize that a particular "stuff" is a project
3. (Clarify) Write the name of that project on your "Projects" list
4. (Clarify) On another piece a paper, write the name of the project at the top and then use the remaining space on the paper to write related next actions. (these Project papers would be located after the "Projects" list
5. (Organize) Write those same next actions again on the appropriate context lists

Am I missing something? Normally, I would just shrug my shoulders and chalk it up to this system only working on a digital application, but David continually stresses that this system is too independent.

Any help would be greatly appreciated.

Thanks,

Andy

 

[mcogilvie]

I’ve never seriously tried paper, but I’ve slowly moved to a digital system where there is no explicit connection between next actions and projects. Foremost, one next action usually gives rise to another: you get the info you need, then you do whatever you needed the info for. There is a natural flow. If it is helpful, you can always put the reason for a next action after it on the same line. I use something like "Print completed staff evals ! Meet w staff" Finally, a lot of projects are linear, simple and require no real planning. Those that require more planning do not typically require sequences of next actions. Attempts at micro-organizing usually are for naught, because change happens.

 

[kelstarrising]

This Guide does a great job about how to apply GTD to a paper tool:
https://store.gettingthingsdone.com/Paper-Organizers-Setup-Guide-p/10460.htm

 

[mcogilvie]

This Guide does a great job about how to apply GTD to a paper tool:
https://store.gettingthingsdone.com/Paper-Organizers-Setup-Guide-p/10460.htm

They really are great. I remember the first time I read the Outlook setup guide. I wasn't using Outlook, but the clarity of the explanations was utterly illuminating.

I struggled for a long time with the leap of faith that you need to have next actions organized by context rather than by projects. There are apps like Omnifocus that do both, but I found there was a lot of drag there. I understood organizing by contexts intellectually, but it took me a long time to give up the gut feeling that I had lost control. The "Ready for Anything" book was a big help, but there was still an emotional barrier there.

 

[TesTeq]

I struggled for a long time with the leap of faith that you need to have next actions organized by context rather than by projects.

What do you think (@DavidAllen, @kelstarrising, @Longstreet) about keeping actions organized by projects and putting projects on context lists?
I know that it creates a mental barrier between context list browsing and doing actions, but...
In the plain vanilla GTD you've got:
- a preparation step: move actions from projects to context lists;
- an execution step: choose action from a context list and do it.
In the "project proxy" GTD I have:
- a preparation step: move active project names to context lists;
- an execution step: choose project from a context list, go to project reference file, get the appropriate next action and do it.

 

[mcogilvie]

What do you think (@DavidAllen, @kelstarrising, @Longstreet) about keeping actions organized by projects and putting projects on context lists?
I know that it creates a mental barrier between context list browsing and doing actions, but...
In the plain vanilla GTD you've got:
- a preparation step: move actions from projects to context lists;
- an execution step: choose action from a context list and do it.
In the "project proxy" GTD I have:
- a preparation step: move active project names to context lists;
- an execution step: choose project from a context list, go to project reference file, get the appropriate next action and do it.

Actually, I’ve tried something like this. In Things, you can give an area a context name. It can hold both projects and next actions. One feature is that you can prioritize projects by moving them within the area. However, projects with next actions in two or more contexts caused friction and uncertainty so I discontinued the experiment.

 

[treelike]

- an execution step: choose project from a context list, go to project reference file, get the appropriate next action and do it.

So you choose what project you want to move forward when you are in a particular context, rather than choosing what next action you feel like doing? Interesting.....

 

[TesTeq]

So you choose what project you want to move forward when you are in a particular context, rather than choosing what next action you feel like doing? Interesting.....

I am a very project oriented person. I prefer to change contexts according to the project needs than to change projects within a context. Probably that's inefficient but it allows me to focus on the successful outcome.

 

[kelstarrising]

What do you think (@kelstarrising about keeping actions organized by projects and putting projects on context lists?

If I'm understanding this thread correctly...

The best of both worlds would be to have both views--actions by context and actions by project. Tagging and views in a lot of apps will support that now. But to only sort by project will be more work. It's not how we naturally choose what to do. The criteria for choosing is:

Context
Time available
Resources/energy
Priority

 

[TesTeq]

The best of both worlds would be to have both views--actions by context and actions by project. Tagging and views in a lot of apps will support that now.

Multiple views and tagging are hardly doable with a paper GTD implementation.
I rarely crank widgets. For example I hate to make "batch phone calling" (@call). Why? Since each call usually belongs to a different project so I would have to rapidly switch my thinking from "a dentist appointment call" to "a blockchain sw development reporting call" to "a car service appointment call" to "an investment options call".
After "a blockchain sw development reporting call" I prefer to create a report and send it, not to call a car service station.

 

[Instigase]

I would suggest that you need to add the following to your workflow:
2a. (Clarify) Natural project planning - draft answers to the following:
2a.1 define your purpose and principles - why am i doing this?
2a.2 define what is the successful outcome
2a.3 brainstorm - how is the outcome achieved?
(2a.4) Organize and (2a.5)Next actions are alreday covered in your outline.

And yes you would naturally write all the sequential actions on the same page as you brainstorm. The organization phase would move the next action into the appropriate context list. the "actions in waiting" would remain in your project notes until your next review.

By doing this, my context lists dont seem so long and daunting.

As soon as I determine that this stuff is really a project I move in to the natural planning model. My answer to 2a.1 often aids the determination if I need to defer or delete that item. These steps are mode agnostic. I would even argue that using paper to do the natural planning model forces more discernment.

 

[mcogilvie]

I would suggest that you need to add the following to your workflow:
2a. (Clarify) Natural project planning - draft answers to the following:
2a.1 define your purpose and principles - why am i doing this?
2a.2 define what is the successful outcome
2a.3 brainstorm - how is the outcome achieved?
(2a.4) Organize and (2a.5)Next actions are alreday covered in your outline.

And yes you would naturally write all the sequential actions on the same page as you brainstorm. The organization phase would move the next action into the appropriate context list. the "actions in waiting" would remain in your project notes until your next review.

This is a good example of where practices differ. While I do use the natural planning model (typing 'npm' expands to 'Purpose: Successful Outcome: Brainstorm: Organize: Next Actions' when I type), I don't use it routinely as a formal tool. For many projects, purpose and outcome are clear, and there is one next action. I use the natural planning model only when I think it will help.

 

[Instigase]

This is a good example of where practices differ.... I don't use it routinely as a formal tool. .... I use the natural planning model only when I think it will help.

For me NPM is an important discernment tool. Employing NPM (with varying degrees of formality) to any item that can be construed as a project has allowed me to be more comfortable in saying no to a project, just by simply performing the first phase, 'Purpose' and doing a gut check against my Roles and Areas of Responsibility. If I'm in, NPM helps me focus and evaluate the next actions.

Of course implementations of GTD/NPM are as varied as each member here. I bring it up because as I read and learn, I find many discussions here are so focused on the first half of the book, the 5 phases, while there are very few discussions and possible solutions which include the 2nd half of the GTD book, such as NPM and vertical viewpoints (Areas of Responsibility)

 

[David Parker]

The way you describe handling Project Next Actions is, more or less, how I do it in my paper GTD system.

I have a form called Project Next Actions (one per active project). On this I put Next Actions as they occur to I me, going as far ahead as I want to. Sometimes I add Next Actions to this list when defining the Project, sometimes when the Project gets reviewed in my Weekly Review, or on the fly when the idea pops into my head.

In each of these cases, I may transfer the Next Action to a Context list. If I do then I highlight it so I know it's moved to a Context list.

 

[David Parker]

I should have added that I don't always create/use a Project Next Actions list for each project. Some Projects just appear on my Projects List and when I'm doing my Weekly Review I will consider whether each Project needs a Next Action and then I will add the Next Action to the appropriate Context.

I make no excuses for my mainly "analogue" GTD system. I was born in the analogue era (BC = Before Computers). But now in the AD (after digitisation) era my total system has digital elements. I use the Apple Calendar and Apple Mail for example, and my Reference system is in DEVONthink. As a Mac user, I also use OmniFocus as a digital backup and support system running alongside my paper system. It does sound like duplication, but in practice it's just a Project Support system.

 

[Jodie E. Francis]

Multiple views and tagging are hardly doable with a paper GTD implementation.
I rarely crank widgets. For example I hate to make "batch phone calling" (@call). Why? Since each call usually belongs to a different project so I would have to rapidly switch my thinking from "a dentist appointment call" to "a blockchain sw development reporting call" to "a car service appointment call" to "an investment options call".
After "a blockchain sw development reporting call" I prefer to create a report and send it, not to call a car service station.

Yes! This is an excellent example of why I struggle with vanilla GTD and am committed to a digital system so I can see my Next Actions primarily by Project and only occasionally by Context. Paper can't do this. I work according to Projects, ideally in time blocks, and I've finally accepted that this is how my brain works best. If I need to move Project X ahead, I will happily switch contexts as needed to do it, and will work that project until I have to stop (time or context limitation). Then note the Next Action (tagged with the applicable Context) as a bookmark/ place holder under that project, and move on.

The exceptions would be Errands (which I do batch) and "one and done" actions like calling for a dentist appointment. Those I will batch - which is why Contexts are still useful to me. Thanks for the clarification TesTeq!

 

[TesTeq]

Yes! This is an excellent example of why I struggle with vanilla GTD and am committed to a digital system so I can see my Next Actions primarily by Project and only occasionally by Context. Paper can't do this. I work according to Projects, ideally in time blocks, and I've finally accepted that this is how my brain works best. If I need to move Project X ahead, I will happily switch contexts as needed to do it, and will work that project until I have to stop (time or context limitation). Then note the Next Action (tagged with the applicable Context) as a bookmark/ place holder under that project, and move on.

The exceptions would be Errands (which I do batch) and "one and done" actions like calling for a dentist appointment. Those I will batch - which is why Contexts are still useful to me. Thanks for the clarification TesTeq!

Yes, yes, yes! Our brains seem to be compatible. I prefer to switch contexts to work on one Project than to switch Projects to work in one context! The exceptions? Errands, of course, and sometimes Agendas.