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]

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]

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]

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. :D

[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

[kewms]

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.

The @Anywhere context only works if the action truly can be done anywhere. The "work from project plan" task is sufficiently vague that you can't know whether it's even possible to do unless you look at the project plan. That's extra overhead that I just don't need to deal with.

I also think the notion that you only "pause" action on such a project may be overly optimistic. Who knows what might happen during the pause? How long can the pause become before it's no longer a pause?

Now, you could certainly word the next action so that it reminds you that the project plan exists. But if you're not going to put a clear, immediately doable action on the appropriate context list, I think you're sort of missing the point of the Next Action concept.

Katherine

[TesTeq]

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

Unfortunatelly in terms of GTD ""work from project plan for X" is just a new chunk of unprocessed stuff - not a Next Action. If you look at the context list and see such item you are not able to decide if you have enough time and energy to do it.

[CoffinDodger]

Completely agree about the NA not being specific.

One thing I'm trying to get my head round is the process of "stopping" doing something in terms of where this fits into the GTD approach.

When you get interrupted at a task you often only have seconds to "do" something about stopping it. Like when I'm working on a long document or piece of software code at work and a manager grabs me for a "quick chat" which could be any length of time in reality. I probably have time to hit "save" and not much more.

It's all very well saying add the next action to a list - but you might have several thoughts in your head because you've been working for half an hour.

I'm toying with jotting down what I think is the next action, or better still, which bit I was actually doing when interrupted, on a piece of paper and putting it in my inbox - i.e. I do an instant moment of "collect" rather than a longer moment of "process" to delve into which list I need to edit.

The metaphore I would use is of being interrupted when reading a book, popping a bookmark in, dropping the book on the table and walking off. You wouldn't really want to spend time writing out the line and page number in that case would you?

Then when I next process I will think "what exactly is this?" and word it properly and put it in the appropriate place.

[Oogiem]

One thing I'm trying to get my head round is the process of "stopping" doing something in terms of where this fits into the GTD approach.....

I'm toying with jotting down what I think is the next action, or better still, which bit I was actually doing when interrupted, on a piece of paper and putting it in my inbox - i.e. I do an instant moment of "collect" rather than a longer moment of "process" to delve into which list I need to edit.

Collect and process later is pretty much what I do when interrupted.

For example, I got a phone call interruption where I had to immediately go over to the guest house and get a meat order ready for pick-up. I was in the middle of researching some sheep for folks in Canada. I jotted down a few key words to remind me what I was doing on a piece of small note paper (Correct Eagle Creek to be Acel prefix re Macdonald lost flock) and tossed it into my in-box. In this case since I didn't need my desk to handle the interruption I left all my various reference materials I was looking at spread out on the desk. If I needed the desk I would have collected it, put the note on top with either removable scotch tape or used a post it note and stuck the entire mess into my in-box. I went out to deal with the meat order, got it ready and delivered to the buyer. Came back in and the only thing in my inbox at that time was the note. Grabbed it and was able to immediately get back to looking for the info on the Eagle Creek sheep.

Another example:

I was outside counting hay bales when I got an emergency phone call from hubby regarding a sick sheep in the upper pasture. (side note, a family cell phone plan is often more useful than you can imagine!) I stuck a rake in the hay stack where I was, wrote a quick note in my notebook and grabbed the crook to go off and catch the sick sheep. Dealing with that took quite a while, we had to catch her, decide what the treatment was going to be, get her down to the barn in a pen where she could be treated, collect the required medicine and other items, treat the sheep, get her food and water, check the spreadsheep data to see how old her lambs were to decide if I needed to catch them, back up to the pasture to watch for the lambs because they were on the edges of being old enough to wean. Discovered they are already stealing milk from an aunt so decided to leave them there. Emergency dealt with my next step was to ask where was I before this happened? First place to look is my little collection notebook. So I pull out my notebook and in it I saw the note "hay bales 756 rake". That prompted me to go back to the hay barn, find the rake, and start counting from there.

[dusanv]

Thanks Katherine and TesTeq.

Honestly, I've had the feeling since the beginning that the approach of having "work from project plan" as a NA was a bit awkward -- it seems I was hasty in trying to save some time on what I considered unnecessary redundant work. To quote Katherine's earlier post:

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.
I can see now that I was confused about the notions of quitting, stopping and pausing, so here is how I'd interpret this process now:
1. I put a kickstart action on a context list, with such an action serving as a trigger to get me started working from the project plan -- this may well be the first action listed in the plan.
2. I actually work from the project plan while the time/energy/context constraints allow.
3. When I suspend the work on the project, I decide that moment on the next immediately doable action for that project -- again, I might be able to use an action listed in the plan -- and write it on a context list.
Please advise if this is correct, so I could fix my lists.

@TesTeq: I really couldn't have imagined you not displaying that "thumbs down" icon :)

Dusan

[kewms]

I can see now that I was confused about the notions of quitting, stopping and pausing, so here is how I'd interpret this process now:
1. I put a kickstart action on a context list, with such an action serving as a trigger to get me started working from the project plan -- this may well be the first action listed in the plan.
2. I actually work from the project plan while the time/energy/context constraints allow.
3. When I suspend the work on the project, I decide that moment on the next immediately doable action for that project -- again, I might be able to use an action listed in the plan -- and write it on a context list.
Please advise if this is correct, so I could fix my lists.


Yes, that's exactly it.

Katherine

[TesTeq]

I can see now that I was confused about the notions of quitting, stopping and pausing, so here is how I'd interpret this process now:
1. I put a kickstart action on a context list, with such an action serving as a trigger to get me started working from the project plan -- this may well be the first action listed in the plan.
2. I actually work from the project plan while the time/energy/context constraints allow.
3. When I suspend the work on the project, I decide that moment on the next immediately doable action for that project -- again, I might be able to use an action listed in the plan -- and write it on a context list.
Please advise if this is correct, so I could fix my lists.

Yes! I fully agree with this interpretation!