Managing/tracking projects and multiple next steps

[Oogiem]

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.

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.

 

[Bill Myers]

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.

 

[Folke]

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.

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?

 

[Gardener]

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 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 red cotton shirt with square piped neckline.
-- 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
-- Make red cotton shirt with square piped neckline.

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.
--- Etc.

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.
---- Etc.

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 red cotton shirt with square piped neckline.
- 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.

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.

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.

 

[Folke]

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).

 

[Bill Myers]

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.

 

[Gardener]

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).

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.

 

[Bill Myers]

Does that make sense?

NO! It's INSANITY! INSANITY!!!

Actually, yes. It makes perfect sense. Probably not how I'd do it but it makes sense. Thanks.

 

[Oogiem]

Could it be that these preferences all boil down to what we are anxious about?

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.

 

[JamesT]

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?

 

[mcogilvie]

There are (at least) 3 places to keep project support material in a software list app:

1) attached to the project (most often as a note)
2) attached to a next action (most often as a note)
3) as a separate item (e.g. in context @plans or @ref)

1) means you have to refer to the project all the time. 2) means you risk losing plans if you check off a text when you should have updated it to the next task on the list. 3) just adds clutter and confusion. Yes, you can hide such items, and I know how to do it in e.g. Omnifocus and Things. I've tried it extensively, and I don't think it helps. My conclusion: project support materials beyond the minimal belong somewhere else.

 

[Folke]

I too avoid keeping project support material in my list app. I have better places to keep pdf brochures, Excel budgets, Word descriptions or good old printed material.

The main exception for me is future (planned/possible/dependent) actions, which I prefer to keep in my list app, if possible - assuming I can prevent them from showing up on my regular GTD lists (next/contexts, waiting etc). The reason why I like to have them in my app is that I can take a long-term look at each project whenever I want to, and I do not have to write the actions first in one place and then in the list app at some later stage. (With some apps you may even be able to partly automate the transition of such dependent future actions into active current actions, but often these mechanisms are not fully convenient or reliable.)

 

[JamesT]

There are (at least) 3 places to keep project support material in a software list app:

1) attached to the project (most often as a note)
2) attached to a next action (most often as a note)
3) as a separate item (e.g. in context @plans or @ref)

1) means you have to refer to the project all the time. 2) means you risk losing plans if you check off a text when you should have updated it to the next task on the list. 3) just adds clutter and confusion. Yes, you can hide such items, and I know how to do it in e.g. Omnifocus and Things. I've tried it extensively, and I don't think it helps. My conclusion: project support materials beyond the minimal belong somewhere else.

The fourth way of doing this in a task app, in my mind, and my favorite is to add a link to the location of the support material. This could be in the notes of the project or the task itself. Most all of my primary locations for backup materials seem to be online now. OneDrive, Evernote, dropbox, etc.

To me this seems like the best of both worlds. Quick access to my materials, plus getting to keep my support materials in "my favorite place for support materials".

 

[Oogiem]

For those of you that like to keep your support materials separate, can you tell me why you do it that way?

Because there is far more support material than I can easily look at and manage on my portable devices for most of my projects. Much of mine is both electronic and paper and it's easier to have a system including folders that matches so I can find stuff easily. So I may have a support folder in DEVONThink for electronic materials and a matching folder with paper materials for any given project. I like my lists to have short easily read items and actions. I also like to be able to see the project planning (sequence of future actions) at the same time I am looking at my support materials and that's harder when it's in one package.

 

[JamesT]

Because there is far more support material than I can easily look at and manage on my portable devices for most of my projects. Much of mine is both electronic and paper and it's easier to have a system including folders that matches so I can find stuff easily. So I may have a support folder in DEVONThink for electronic materials and a matching folder with paper materials for any given project. I like my lists to have short easily read items and actions. I also like to be able to see the project planning (sequence of future actions) at the same time I am looking at my support materials and that's harder when it's in one package.

That is a great point Oogiem - I think in the case where I have a lot of info in another software tool, I'd still want to save some time by creating a link in my GTD system over to other software to bring it up quickly.

 

[mcogilvie]

The fourth way of doing this in a task app, in my mind, and my favorite is to add a link to the location of the support material. This could be in the notes of the project or the task itself. Most all of my primary locations for backup materials seem to be online now. OneDrive, Evernote, dropbox, etc. To me this seems like the best of both worlds. Quick access to my materials, plus getting to keep my support materials in "my favorite place for support materials".

Links are ok, but they are not robust. They are subject to changes in the OS and to the apps involved, and are almost always limited cross-platform. Furthermore, they need to be maintained and propagated just like any other information that would appear in the note field of a project or next action.

 

[Folke]

For me, links are good enough for the simple reason that I do not use them much and do not intend them to live long. In fact, I do not intend to keep anything in my list app after it is completed - and this is one of all the reasons why I do not like to keep much reference info in my list app (yes, I do sometimes paste a phone number etc into a task just to keep it handy etc, but that's just about it.)

I believe it is necessary to have a reference system that can be trusted (and easily accessed). Once we have such a reference system in place, the need to closely integrate or loosely link our reference material into the list app is quite minimal.

Some developers focus intently on reference integration, though, and there seems to be some demand for it. Zendone and IQTell are perhaps the most well-known examples of GTD apps that offer tight integration with Evernote (and almost every app supports links). And some people use Evernote for all of their task management it (for actions, too; these people do not even bother to get a specific "GTD" app just for their actions; they keep those as Evernote notes.) And many still use paper.

As I said earlier - and slightly closer to the title of this thread (about multiple next steps in a project) - I'd say my main use for including "reference" information ("project support" information) in my list app is upcoming actions, actions that are dependent, not yet possible, not yet "next" etc. I see no benefit in keeping those outside of the list app - why should I, but some people prefer that, I know. But in order to be able to keep them within the list app as I prefer it, it is necessary that I can keep them neatly isolated and distinguishable, not mixed up or confused with the current next and w/f actions etc. In most apps that I have used I have been able to find some workaround.

 

[JamesT]

The main exception for me is future (planned/possible/dependent) actions, which I prefer to keep in my list app, if possible - assuming I can prevent them from showing up on my regular GTD lists (next/contexts, waiting etc). The reason why I like to have them in my app is that I can take a long-term look at each project whenever I want to, and I do not have to write the actions first in one place and then in the list app at some later stage. (With some apps you may even be able to partly automate the transition of such dependent future actions into active current actions, but often these mechanisms are not fully convenient or reliable.)

I agree, and this is the primary use case we envisioned for GTDNext as well. Although we support other reference material, the most important thing for us to implement was the ability to plan out an entire project in the app if one so wished.

To do this without cluttering up your next action list is the trick. Again, using my own app as a reference point, we have solved this by only showing one action per project to appear next action list. Of course we allow people to override this and add individual tasks to the next action list as well. We also implemented unlimited levels of sub-projects which also helps with organizing in such a way as to not overwhelm.

I prefer (and I think many others may as well) to keep all my project actions in one place and not have to refer to another system or support materials. The problem for me has always been that when I do this I either A) Can't really plan things in a way that makes sense. In other words the software is too limited in it's planning abilities or B) The filtering ability of the app makes it difficult to see just my next actions. I'm forced to look at all the actions for the project.

 

[Oogiem]

I prefer (and I think many others may as well) to keep all my project actions in one place and not have to refer to another system or support materials.

Interesting, I will keep a few bits of support material in my app but generally I prefer NOT to have very much support material there. I don't do my planning in my list manager per se, I do my planning in my head and document it in my list manager. I also need to have a good filing system for support material because I have projects that can span decades or even across 2 or more lifetimes. Just dealing with a single project that took almost 30 years to complete meant there was a lot of paper support material to keep track of and no list manager can do it.

Then again I am an oddity, not many GTD folks have projects that cover such a long time span.