Clarification about future projects and actions

[dusanv]

Hello everyone,

I am new to GTD and to this message board. I have read the GTD book (very inspiring read BTW) and I hold it that I have understood most of the methodology presented. Now, there are some things for which I do not fully comprehend how to fit into my world, and would appreciate some clarification/guidance from the more experienced. I apologize for the lengthy post, but I felt I needed to write it that way in order to make the points. Basically, there are 3 issues:

1) Where do I track projects that I cannot start right now, nor ASAP, but rather in the future when certain circumstances are met, such as when I have enough money or other resources, or when I am sure I can have enough time to embark on a very time-consuming project, or if the project is season-specific rather than day or month-specific? I must point out that "Someday/Maybe" kind of stuff doesn't feel right for such projects, as the projects are mandatory rather than "maybe" (surely I am aware that realities change, but I can say with much certainty now that I will/have to be doing certain projects in the foreseeable future). And I also need to be able to store some support material in advance for such projects regardless of their being inactive, such support material being plans, ideas or whatever project-related info I come along.

2) This is somewhat related to 1), but where do I track projects that are dependent upon completion of another project? I am talking about simple dependencies along the lines of "I'll start X as soon as I have completed Y", simple enough to not warrant complex vertical project planning, but that still need to be tracked somewhere outside of my mind. As in 1), "Someday/Maybe" doesn't feel right and there's also the support material issue.

3) I understand that I can have as many or as few next actions defined for a project as I feel comfortable with. Sometimes, however, I need to define a whole sequence of actions in advance. I suppose that writing a traditional enumerated to-do list can be a heresy to GTD, nevertheless I could write such a list and put it into the support material, no? Then again, frequent copying from the support material to relevant next action lists can be tedious, and this is particularly true for those actions listed that don't require much time. So am I missing something there?

Thank you for your responses,
Dusan

 

[TesTeq]

Answers for your questions.

1) Where do I track projects that I cannot start right now, nor ASAP, but rather in the future when certain circumstances are met, such as when I have enough money or other resources, or when I am sure I can have enough time to embark on a very time-consuming project, or if the project is season-specific rather than day or month-specific? I must point out that "Someday/Maybe" kind of stuff doesn't feel right for such projects, as the projects are mandatory rather than "maybe" (surely I am aware that realities change, but I can say with much certainty now that I will/have to be doing certain projects in the foreseeable future). And I also need to be able to store some support material in advance for such projects regardless of their being inactive, such support material being plans, ideas or whatever project-related info I come along.

Someday/Maybe. If not active then it is Someday/Maybe. You review Someday/Maybe list during Weekly Review so you can activate such project easily.

There is nothing wrong in having reference file for Someday/Maybe project.

2) This is somewhat related to 1), but where do I track projects that are dependent upon completion of another project? I am talking about simple dependencies along the lines of "I'll start X as soon as I have completed Y", simple enough to not warrant complex vertical project planning, but that still need to be tracked somewhere outside of my mind. As in 1), "Someday/Maybe" doesn't feel right and there's also the support material issue.

Someday/Maybe. You can write down the information about the project X in the project Y's reference file (and vice versa).

3) I understand that I can have as many or as few next actions defined for a project as I feel comfortable with. Sometimes, however, I need to define a whole sequence of actions in advance. I suppose that writing a traditional enumerated to-do list can be a heresy to GTD, nevertheless I could write such a list and put it into the support material, no? Then again, frequent copying from the support material to relevant next action lists can be tedious, and this is particularly true for those actions listed that don't require much time. So am I missing something there?

Writing a traditional enumerated action lists is not a heresy. The only advice is not to overplan. You put project plans in the project reference file. Don't make a project plan to detailed.

 

[lolajl]

I use OmniFocus (Mac only), and it allows me to put projects On Hold or Pending.

 

[CoffinDodger]

2) This is somewhat related to 1), but where do I track projects that are dependent upon completion of another project? I am talking about simple dependencies along the lines of "I'll start X as soon as I have completed Y", simple enough to not warrant complex vertical project planning, but that still need to be tracked somewhere outside of my mind. As in 1), "Someday/Maybe" doesn't feel right and there's also the support material issue.

If the projects are somewhat related, they may well form part of the same goal. In which case, express the goal and its successful outcome (probably as a 30,000 feet item). You could list the projects you know you will need to do to fulfill your goal as a checklist on the goal - that way when you've finished project 1 and next review the goal at a weekly review, you'll see a reminder to activate the next project.

 

[Cpu_Modern]

1) Where do I track projects that I cannot start right now, nor ASAP, but rather in the future when certain circumstances are met, such as

Put a reminder on your waiting for list. Or make another custom-designed list that you review during your Weekly Review.

Sometimes, however, I need to define a whole sequence of actions in advance. I suppose that writing a traditional enumerated to-do list can be a heresy to GTD, nevertheless I could write such a list and put it into the support material, no?

That is the standard procedure.

Then again, frequent copying from the support material to relevant next action lists can be tedious,

Keep in mind: you do not have to copy each an every NA. Once you started working on a given project, you don't just stop when the first NA is completed. Well, sometimes you do, but oftentimes you will go on and Do some more work on that particular project. (You can find more on this by searching this forum for "next actions as bookmarks".)

 

[Kim M]

Future projects and actions

Dusan wrote:

1) Where do I track projects that I cannot start right now, nor ASAP, but rather in the future when certain circumstances are met, such as when I have enough money or other resources, or when I am sure I can have enough time to embark on a very time-consuming project, or if the project is season-specific rather than day or month-specific? I must point out that "Someday/Maybe" kind of stuff doesn't feel right for such projects, as the projects are mandatory rather than "maybe" (surely I am aware that realities change, but I can say with much certainty now that I will/have to be doing certain projects in the foreseeable future). And I also need to be able to store some support material in advance for such projects regardless of their being inactive, such support material being plans, ideas or whatever project-related info I come along.

You may want to consider your project prerequisites (getting resources) to be part of your project. At the least, you will need to have next actions identified that will eliminate any roadblocks that are letting you defer a must-do project.

If a project is seasonal, place a reminder in your tickler file or calendar to get started on the project at an appropriate date.

Kim

 

[Roger]

It's probably fine to break up your projects into Active and Inactive baskets. It might be too tempting to neglect the Inactive projects, but if you review them at least occasionally you'll probably be fine.

The Next Action for Inactive projects may very well fit into Waiting For, if you're waiting for enough resources or a particular time or whatnot.

Project Planning: It's entirely GTD-compliant and a good idea -- Chapter 3 is all about project planning.

I like to put each action on its own piece of paper. Then it's easy to move from Project Support to Next Actions to Waiting For etc etc.

 

[dusanv]

Well, a lot of replies and good ideas! I thought there were standard procedures for accomplishing what I needed, however I realize how flexible GTD is (there can always be another way). As this eventually leads to YMMV, I'll respond to some of the ideas I think are adaptable to my situation (and this does not mean the other ideas presented here are not useful -- thanks everyone). At the end, I'll clarify my issue regarding actions (point 3 in the original post), and I realize that I should have made 2 posts for the sake of clarity, but as I said, I am still new to this forum. So here we go, in the order as posted:

Someday/Maybe. If not active then it is Someday/Maybe. You review Someday/Maybe list during Weekly Review so you can activate such project easily.

Sure, but somehow I think/feel that a mandatory (must-do) project should not go on Someday/Maybe list (could easily get mixed with wishlists or anything other of that sort). Still, if I had clear boundaries, and could subdivide Someday/Maybe into 2 or more lists, this could possibly work.

On the other hand, this

Put a reminder on your waiting for list. Or make another custom-designed list that you review during your Weekly Review.

and this

The Next Action for Inactive projects may very well fit into Waiting For, if you're waiting for enough resources or a particular time or whatnot.

have some common points, with the only issue being GTD-compliance of creating custom-designed lists of inactive projects and delegating projects to myself (as Waiting For is for delegated projects). I don't mean to imply that GTD is a law or an ISO standard, rather I'd like to know if such setup has worked for someone (especially Cpu_Modem and Rogers) as it does seem logical.

You may want to consider your project prerequisites (getting resources) to be part of your project. At the least, you will need to have next actions identified that will eliminate any roadblocks that are letting you defer a must-do project.

This might do for some projects. For others, however, there may be several (mutually unrelated) projects that are awaiting the same resources. So I can't make getting resources a part of each of those projects. Or do you suggest it is somehow doable?

Project Planning: It's entirely GTD-compliant and a good idea -- Chapter 3 is all about project planning.

I have read the Chapter 3 and 10, and, as per the author's suggestion, I recognize the need for more informal planning, which I think will suffice for most of my projects. I am looking to avoid formal project planning whenever possible, and surely am aware that it is sometimes necessary.

Now the actions issue:
I have noticed that a similar thread has been posted meanwhile, but regardless let me say that I am looking to speed up the process. If I had defined, say, a sequence of 30 actions for a project, only 1st of them would be a next action, so if I wanted to make an enumerated list, it would have to go in the support material as a project plan, and we agreed on that. Now, what bothers me is frequent rewriting from the project plan to NA list(s), and one of the GTD strengths is that it can help you save time. So is there a speed up -- like I pull out that "project plan" list, do items on it in order specified and cross them over, without redundant rewriting on NA list(s)? That's what I initially referred to as a "heresy". So is there perhaps a better and more GTD-compliant approach?

Dusan

 

[kewms]

This might do for some projects. For others, however, there may be several (mutually unrelated) projects that are awaiting the same resources. So I can't make getting resources a part of each of those projects. Or do you suggest it is somehow doable?

How about making obtaining the resources a project in and of itself? Then put the dependent projects in a list in the resource project's support materials. For example:

Resource Project: Obtain bank loan to fund facilities expansion.
* @Call loan officer, ask what documentation they will need.
* @Office brainstorm facilities expansion, estimate square footage and necessary equipment (Or else the bank loan might spawn a Write Business Plan sub-project, which would include this action.)

Time passes. You write the business plan. You apply for the loan. The bank loves you, you sign the documents, and money appears. So you pull from the project support materials your list of facilities expansion projects:
* Work with general contractor to design and build new plant.
* Work with recruiter to hire staff for new plant.
* Work with public relations team on rollout of new plant and related products.

Now the actions issue:
I have noticed that a similar thread has been posted meanwhile, but regardless let me say that I am looking to speed up the process. If I had defined, say, a sequence of 30 actions for a project, only 1st of them would be a next action, so if I wanted to make an enumerated list, it would have to go in the support material as a project plan, and we agreed on that. Now, what bothers me is frequent rewriting from the project plan to NA list(s), and one of the GTD strengths is that it can help you save time. So is there a speed up -- like I pull out that "project plan" list, do items on it in order specified and cross them over, without redundant rewriting on NA list(s)? That's what I initially referred to as a "heresy". So is there perhaps a better and more GTD-compliant approach?

Your speedup -- working directly from the project plan -- is completely GTD-compliant already. When you quit working on the project, just remember to note the new NA on your NA list.

Katherine

 

[David Cain]

somehow I think/feel that a mandatory (must-do) project should not go on Someday/Maybe list (could easily get mixed with wishlists or anything other of that sort). Still, if I had clear boundaries, and could subdivide Someday/Maybe into 2 or more lists, this could possibly work.

This was a sticking point for me, I didn't like putting important projects on a list with the word "maybe" in the title. But that's just what it's called. There's nothing wrong with putting must-do's on that list. Call it something else if you want (future considerations?)

I have divided my S/M list into four tiers:

1) to be reviewed weekly -- "Buy new runners"

2) to be reviewed monthly -- "Learn how to code CSS"

3) to be reviewed quarterly -- "Launch new blog"

4) to be reviewed yearly -- "Backpack in Asia, Start a freelancing business"

Whether it's a "for sure" or a "maybe" doesn't matter if you are going to be reviewing them regularly. A lot of the "maybes" will end up getting crossed off when you realize you are no longer really interested in them.

 

[TesTeq]

The best method of the Someday/Maybe list division.

I have divided my S/M list into four tiers:

1) to be reviewed weekly -- "Buy new runners"

2) to be reviewed monthly -- "Learn how to code CSS"

3) to be reviewed quarterly -- "Launch new blog"

4) to be reviewed yearly -- "Backpack in Asia, Start a freelancing business"

I think it is the best method of the Someday/Maybe list division.

 

[Oogiem]

1) Where do I track projects that I cannot start right now, nor ASAP, but rather in the future when certain circumstances are met

I have literally hundreds of this sort of project. I have all of them as "on hold' in my Omnifocus (OF) system. During weekly review and at major seasonal changes (equinoxes and solstices) I really go through these and see if the criteria for any have been met and of so then activate them.

2) This is somewhat related to 1), but where do I track projects that are dependent upon completion of another project?

Again I have lots of these. They also are on hold with a note in the project description of what they are waiting on whether it's a project or a tool or resource I don't have.

3) I understand that I can have as many or as few next actions defined for a project as I feel comfortable with. Sometimes, however, I need to define a whole sequence of actions in advance.

I also do this. By putting the actions in my lists but the project on hold, or set the project parameters to be tsequential I don't lose the thinking I already did but it also doesn't clutter my system.

Some of them are on paper as lists of actions or mini-projects but most are migrating into my main OF system.
A lot of what is in my reference file is actually support for projects that are on-hold or are future dreams.

What I noticed about your questions was the concern of the blurring of someday/maybe where that category includes the wishlists and dreams as well as hard projects you really have to or plan to get done.

What I've done is just include them all but put the ones I really want to make sure I do near the top of my lists. Other people have a separate section for blue sky maybe things. Try both approaches and see what works best for you.

Another is that you need to know how the tools you use help with the way you think. For me getting everything in one place turns out to be really critical. Also having an easy way to do a review of everything, from the far out maybe projects to the get done next season ones is really critical and most importantly I found I needed to be able to look at my project lists and action lists in several ways easily.

Don't get sucked in to testing every new tool but then again if the tool is holding you back make a project to research and discover the one that will work for you.

 

[Cpu_Modern]

rather I'd like to know if such setup has worked for someone (especially Cpu_Modem and Rogers) as it does seem logical.

It worked for me quite well. When I started out with GTD I did have a list of projects I would like to do but can't due to lack of money / time. Later I could move some of those projects onto my active list and complete some of them. But what really happened was this: after a while of GTD, some internal shifting started to happen, like the melting of glaciers at the end of an ice age. I just tossed many of the pipedreams on my Someday /Maybe list after looking at them again and again and realizing their true nature. I started to say "no" more often, or better yet, to just shut the fuck up and be a nice person without getting excited about all sorts of things. What I am trying to say is this: the world looks very different after taking GTD as per description for ~4 months or so. Not so dam complicated.

 

[dusanv]

After some experimenting and consulting the authoritative reference -- the GTD book, and after reviewing the posts again, let me present some of my comments and questions. On page 158, the book says (and I assume this falls under fair use):

If you make the large project your one listing on your "Projects" list, you'll want to keep a list of the subprojects and/or the project plan itself as "project support material" to be reviewed when you come to that major item. I would recommend doing it this way if big pieces of the project are dependent on other pieces getting done first.

which brings me to this idea

How about making obtaining the resources a project in and of itself? Then put the dependent projects in a list in the resource project's support materials.

Why not, provided that I clearly define the project outcome as I don't want to obtain the resources simply in order to obtain the resources -- I can see from the rest of your post that we agree on this, regardless of how unrelated your example might be to my projects. I have also been convinced by other users that Someday/Maybe list might as well be a place to keep projects I can't do now provided that I review the list regularly, with David's method of managing that list (quoted above by TesTeq) appearing particularly useful. In effect, when speaking of projects I can't do now, I still support Katherine's approach for must-do projects, while the rest might as well go on S/M list in order not to make much clutter on Projects list, and also in order to more easily facilitate the "shifting tactical priorities" spoken of in the book.

Your speedup -- working directly from the project plan -- is completely GTD-compliant already. When you quit working on the project, just remember to note the new NA on your NA list.

Katherine

Assuming that in such scenario, the NA should be something like "Work from the project plan for X", my question is where do I place that NA context-wise if the actions are tied to multiple contexts -- i.e. do I place it on all the context lists the actions would belong, or do I create a special @Project list?

I have literally hundreds of this sort of project. I have all of them as "on hold' in my Omnifocus (OF) system.

As I am not familiar with Omnifocus, could you please tell me how "on hold" translates to the "pure" GTD terminology (e.g. as Someday/Maybe or Waiting For etc.) -- or is it an extension not applicable to other tools?

Another is that you need to know how the tools you use help with the way you think. For me getting everything in one place turns out to be really critical.

I agree, though I assume I could have multiple inboxes (in-baskets) depending on the type of input (paper-based, PC-based, mobile-based). Is this a correct approach?

Dusan

 

[Oogiem]

As I am not familiar with Omnifocus, could you please tell me how "on hold" translates to the "pure" GTD terminology (e.g. as Someday/Maybe or Waiting For etc.)

Unfortunately from my POV on hold covers both someday/maybe and waiting for. I'd like a clearer line between them but with a good weekly review it's not that hard to make the system work.

Several folks have added waiting for contexts to handle that issue

I haven't gotten a round tuit yet re that

 

[Roger]

As I am not familiar with Omnifocus, could you please tell me how "on hold" translates to the "pure" GTD terminology

The closest is probably Incubate -- see pgs 126-127.

Cheers,
Roger

 

[Gardener]

I wanted to chime in and mention that OmniFocus also has a Start Date capability. If you give a project a Start Date in the future, it will disappear from the view of available projects until you reach the start Date.

I use this for things like "Order spring bulbs." I don't want this cluttering up my lists in April when it's totally irrelevant, and I don't want to set a hard due date for it. But I do want it to reappear in my lists in, say, August, when the bulb catalogs start coming available. And I don't want to have to remember to actively make it reappear. Start Dates do all this.

I'm not quite sure where this is relevant to the discussion, but the discussion made it come to mind, so I thought I'd mention it. I think that in pure GTD terms, this might be analogous to a tickler.

Gardener

 

[kewms]

Assuming that in such scenario, the NA should be something like "Work from the project plan for X", my question is where do I place that NA context-wise if the actions are tied to multiple contexts -- i.e. do I place it on all the context lists the actions would belong, or do I create a special @Project list?

I would NOT define the NA in this way. Once I stopped working from the project plan, I would figure out the next immediately doable action and put it on the appropriate context list. Which is more likely to get you moving: "work from project plan for X" or "@call Monty re: information request for X?"

Katherine

 

[chandi786]

Yeah OmniFocus is really good but unfortunately that's for MAC only

I use OmniFocus (Mac only), and it allows me to put projects On Hold or Pending.

 

[dusanv]

I would NOT define the NA in this way. Once I stopped working from the project plan, I would figure out the next immediately doable action and put it on the appropriate context list. Which is more likely to get you moving: "work from project plan for X" or "@call Monty re: information request for X?"

Katherine

First of all, thank you for getting back to this issue, and I really appreciate your comments. My main concern, if you recall, is about that rather simple kind of project plan consisting only of a sequential action list. Naturally, in such case, I would not stop working from the project plan until the project is completed (I might move on to another project for a period of time, but that's what I'd call pausing, not stopping). So, while your example kickstart action is certainly more motivating than is a vague reference to a project plan, I would prefer having a constant NA reminding me that I need to work from the project plan until the project is completed (and sure, the project plan need not be immutable, and that's what Review is for).

Still, the question of which context list to put that constant action into remains if the actions belong in multiple contexts -- I've seen mentions of @Anywhere context in another thread and I do like the idea in absence of a better one. I hope I've explained my concerns clearly and am looking forward to some comments.

Dusan