text: But seriously - many people overthink and overplan their actions...
  That's another good reason to just have a simple divider etc between actionable and not-yet-actionable (dependent) and play it by ear.
  It's another personal-preference thing. I find it much easier to remember which projects are interrelated than to remember to keep all threads of a multi-thread project going. I prefer the structure that prevents, "Ack! I forgot to call Jane, and now she's gone on that vacation!" as opposed to preventing, "Um, which project was I calling Jane about? Let's check the notes..." Having "Call Jane" as the sole action of an entire project is more likely to have that effect--for me.
  Of course, if I found myself checking the notes several times a day, that preference would probably flip. Usually the project name is enough to remind me what it's for.
  That doesn't mean that I don't appreciate the flexibility of being able to have multiple actions, but for projects with any sequential nature (as opposed to things like shopping lists or lists of books or lists of ideas or my various single-action lists) I try not to use that feature much.
  Multilevel nesting doesn't help me--the structures that I form in my head tend to go many-to-many rather than parent-child, so I'd rather just view the projects flat, sorted into a single level of folders for major areas. (Even then, projects across different folders are often related to each other, but that happens less often, so the folders are worthwhile for me.)
  But the list of projects doesn't get too big for me any more, because I regularly move out projects that I realize are not going to progress in the next several weeks--I dump them in source material instead. If several sibling threads for a project *could* be active, but I know that I'm not likely to work on some, I'm likely to move those out.
  [QUOTE=Gardener;112468]I'd rather just view the projects flat, sorted into a single level of folders for major areas./QUOTE]
  Exactly what I do, too! (In my current app, Doit, the level above projects is called goals, but I assume your folders do the same job )
  I need my manual workaround for having as many next actions as I want in each project and be able to "hide" the rest.
  When I used to find myself frequently having to scrap next actions related to particular projects because those NAs turned out to be incorrect, it was almost always because I overplanned. For me part of project planning is clarifying what are true next actions versus ideas that need more time in the oven. The latter go in project support.
  I have lots of projects that involve subprojects. There's nothing wrong with listing them as separate projects but I don't bother because usually accomplishing the subprojects alone won't mean much unless the ultimate project is achieved. I find it easier to keep my eyes on the prize if I keep the subprojects with the main project. There are use cases for doing it either way, I'm sure.
  I find it easy enough to keep future actions (by which I mean actions that are clarified but are dependent on other things happening first) and ideas about possible actions (those that need more time in the proverbial oven) in the body of the digital note representing the project in my digital organizer. I'm not looking to argue with anyone. Those are just my two cents.
  Folke and Gardener, I am curious: what's the advantage in your view of keeping these things as discrete task items in your organizers versus just having them in the notes of a project? I guess I'm just not seeing it.
  I often forget to write down the "climb down" action and end up stuck at the top of the ladder or frustrated after several unsuccessful ladder folding attempts... I didn't realize you are a cat. I'm impressed. Your spelling, grammar and syntax are better than my cats'.
  Don't laugh. One of my cats recorded a macro on my girlfriend's computer and on a subsequent occasion managed to print airline tickets.
  Different projects I guess. I've got projects that got planned 40 years ago by other people that I'm only just now finishing. Very rarely do my projects change much if the initial planning is done properly. I know my view of projects (things that can and sometimes do span decades or even several lifetimes) is a far outlier in terms of GTD practice. I do have many of the smaller more typical GTD projects but it's also pretty common for projects to be several years at least before they are finished. That's partly why I never have subprojects. I really like having at least some things i can check off as DONE once in a while.
  Like I said, there are use cases for either approach. Mine works for me but I wouldn't call my way anything other than a personal preference. If I had projects like yours I might prefer your approach.
  It is just a matter of personal preference, of course, but this is why I prefer to keep the dependent actions as tasks (or even projects) within my list tool:
  I simply do not have external project support material for all my projects. It would seem alien to use, say, MS Word or a fountain pen to list the dependent actions and have to create an external storage place to keep them in.
  Similarly, it would seem a bit unpractical to enter them as text within the app's project comments. The list tool is made specifically for keeping tasks (it has Contexts and all the other typical features), and I prefer to enter them as such right from the start and have it all as well prepared as I need to at the current stage, and evolve it gradually as it draws nearer.
  Keeping them visible within the app's project, together with the now active tasks but visually distinct, all viewable as a whole, is what brings convenience and trust to the overall and longer-term planning (reviewing). I have no other tool for that, and I like to review my thoughts and plans. I like to have it all in one single place with one single set of uniform functionality and I need to know that it is "complete" enough to be trusted both in the long term and in the short term and anything in between. I like to put in, already at the time it first occurs to me, placeholders for things that I am anxious now that I might overlook in the future, no matter how distant or tentative they may be or how broad the strokes are - for example, entire future large projects represented as just a single someday/maybe task initially, which I will clarify and break down later when I get closer to it. This potential for combined long-term-high-level planning and short-term action is what is ultimately driving me to use an app and to keep looking for better ones. I am not sure I would even bother with an app (and the inevitable rigidity of apps) if all I wanted was to just keep a few weeks' worth of next actions listed. Does that make sense?
  Last edited by Folke; 01-21-2014, 08:34 AM.
  I tend to complicate the definition of "the prize" to the extent that this won't work for me.
  A thought exercise, from the hobby realm. Starting with a sewing project:
  - Make red cotton shirt with square piped neckline.
  I've never done a square piped neckline, or the facing that it will require. I need to test those techniques with samples before I make the real garment. So this could be seen as a project with subprojects:
  -- Make a sample of a piped square-cornered edge
  -- Make a sample of a square-cornered interfaced neckline facing
  But, actually, I'm doing this project in large part *because* I want to learn new sewing techniques such as piped edges. So I could flip the project and subproject, ending with two projects that share a subproject:
  - Learn to pipe a square-cornered edge
  -- Make red cotton shirt with square piped neckline.
  - Learn to make a square-cornered interfaced neckline facing
  Or maybe the project is the pattern, one that I chose and altered specifically to be a canvas for new sewing techniques:
  - Fit and test the "canvas" shirt pattern.
  -- Make first test, a red cotton shirt with square piped neckline.
  Or maybe the project is the skills as a group:
  - Learn new sewing techniques
  -- Fit and test the "canvas" shirt pattern.
  --- Make first test, a red cotton shirt with square piped neckline.
  Why am I learning sewing techniques? Because I'm learning sewing. Why am I learning sewing? Because I want a more personalized wardrobe than I can buy in ready-to-wear AND because I want a creative outlet AND because I want an area of learning in my life that is physical and visual instead of the abstract learning that I usually experience.
  Why am I making a red cotton shirt? To learn sewing techniques AND because I need more shirts. Why do I need more shirts? To improve my wardrobe, making a second line to an already-mentioned goal. Oh, and right now I have a goal to create a travel wadrobe, so my current sewing projects should be very low-bulk and all kind of go together. Unless some other priority outweighs that.
  And that tangled set of motivations and dependencies just keeps going. It's too much for my action lists to reflect, and a "pick the most important one" decision annoys me while failing to clarify for me. So I make all of that my project support material's problem, and my action lists just tell me what to do. I may create projects to ensure that the lists reflect the support material:
  - Plan next sewing project
  -- Look at the skills list and wardrobe list.
  But once I've evaluated my goals for this specific next project, and perhaps written them down in case I want to refer to them again, and chosen a project, then I just put the naked project, and the parallel projects that it sprouts, in my system:
  - Make a piped-edge sample
  - Make a sample of a square-cornered faced neckline
  These three projects aren't parallel from beginning to end--I obviously can't finish the neckline of the shirt until I learn the skills required for the neckline. But they're parallel for a while, so I may choose to have them all in my active lists.
  There is none for me--I'm not arguing for that practice. If you keep them in a note attached to the project, you're keeping them a little closer than I do. The only reason I ever did keep many future actions with the project was because OmniFocus supported it so beautifully that I didn't question it for a while. (That's not OmniFocus's fault--the fact that it supports a particular use pattern doesn't mean that I need to follow it.)
  I don't see any definite harm in keeping a list of possible actions in the project, especially if they're clearly non-actionable, but it wouldn't work for me. The more items in OmniFocus, even if they're theoretically items that I can ignore most of the time, the less easily I interact with it. I don't know why, and it's not true for everybody, but it is true of me.
  I used to think that keeping lists in OmniFocus, just plain lists (like "books to read" or "perfumes to sniff") wouldn't cause any trouble, but, no, they distract me. So everything non-actionable is out. OmniFocus was a handy place to store lists like that, but now I enter them as actions: "Add blah to Books to Read list." That means that those lists are no longer handy on my phone. I want to do something about getting a Mac-to-phone syncable list manager, but even before I do that, the reduced clutter in OmniFocus is worth it for me.
  The only reason I ever did keep many future actions with the project was because OmniFocus supported it so beautifully that I didn't question it for a while.
  I suppose you are referring to the one-at-a-time auto-sequential mode which places a new action - the next in line - on your next list as soon as the previous one is completed? Yes, that feature seems immensely popular. I had that feature available in Nirvana, and played with it briefly, but decided against using it at all because it only allowed me to have exactly one next action per project. And it was too fiddly for my taste to keep switching the project between sequential and parallel depending on how many next actions I has at the moment. So I chose a manual workaround which "hid" all the subsequent actions from the active lists (Next, Waiting, Someday, tickler aka Scheduled etc), but which allowed me to review them within the project itself.
  I used to think that keeping lists in OmniFocus, just plain lists (like "books to read" or "perfumes to sniff") wouldn't cause any trouble, but, no, they distract me.
  Same here. I do not keep those in my GTD app either. Those are just neutral possibilities of no consequence (e.g. "wines worth trying", "interesting novels" etc.). These cause no stress whatsoever. If I do them it is fine. If I do not do them it is also fine. (Or try some other wines or books instead; also fine). I am not anxious either way about these things and hav no need for them in the GTD app. They only get in the way. Hypothesis
  It is apparent that we are all very different when it comes to what we want to be in (or closely linked to) our GTD app. Some people (e.g. bcmyers2112) want reference info and emails closely linked. Some people (e.g myself) want subsequent project actions preferably within the app itself. Some people (e.g. Gardener) want neither. Could it be that these preferences all boil down to what we are anxious about? For example, if someone is in fear of not being able to find the reference info (e.g. email) when dealing with a task, it is natural to want to keep such info closely linked to the tasks. Or if someone is in fear of not making the right overall prioritizations ("work balance") for a lack of overview of the upcoming challenges in each project, it is natural to want to keep significant not-yet-actionable tasks/challenges for each project in the app (for convenient review purposes; but outside of the daily lists).
  Could it be that these preferences all boil down to what we are anxious about?
  Speaking for myself: no. The email-to-Evernote feature is just a convenience. I use it because it's available and it saves me a few seconds here, a couple of minutes there. I could live without it.
  And in my case, with hoarders in the family, I'm anxious to avoid a precedent of keeping a lot of stuff (even electronic stuff) nearby so that it's "where I can see it". I like to put things away so they're out of sight until I want them. Yes, it's entirely possible. Comment
  NO! It's INSANITY! INSANITY!!!
  Actually, yes. It makes perfect sense. Probably not how I'd do it but it makes sense. Thanks.
  Maybe. I think it more boils down to your personal life experience, what you have had happen based on how you interact with your tasks and goals.
  I have been going back through some older posts and have found some great discussions! I found this discussion particularly interesting because with my app we've taken a lot of time to think about this problem, so it's a very interesting discussion to me. In our model we have leaned towards giving people the ability to keep their project reference and support materials right in the app and closely associated with the projects and actions they are working on. Because we utilize an outline style interface, people can easily hide this information until they need it and it's setup in a way that this information never shows in your next action list.
  However, in reading this thread it seems that some people want to keep their support materials separate from their tasks management system. I'm trying to get to the core reason(s) for this. There seems to be many possible reasons. Is it because people fear that keeping the support materials with the projects and next actions would be too distracting? Or because they like the system they keep their support materials in better? Or maybe because David Allen says he does it that way? Other reasons?
  For those of you that like to keep your support materials separate, can you tell me why you do it that way?