GTD Project List - deferred projects?


just worked on a projects list custom perspective, that I‘ll use during my weekly reviews. Just a plain list with all my projects and action groups (no actions shown).

While doing that I explicitly excluded on hold projects (put them on my someday/maybe list). However, I‘m still not sure what to do with deferred projects, projects that have a future defer date.

Would you put them on your project list or rather put them on someday/maybe or neither (Forecast perspective?). Haven‘t found good reasons for either one, yet. Curious about your opinions and reasoning.

Thank you all

1 Like

Not sure if this addresses your question, but I normally defer projects. Sometimes, I can’t start working on them until something specific happens. So, the project gets that date. I do not move them around, they are in the correct folder (or at the top level) and I just set the date on the project.

In my daily review, I do not review deferred projects, so they get out of the way until I can start thinking about them. It’s nice that I immediately see them show up in review. In my weekly review, on the other hand, I review everything.

If I have too much to work on, I use On Hold status instead of deferring a project to keep pending things out of my day-to-day radar.

1 Like

My idea is to usually use on hold to reduce the amount of active projects. I‘d rather not start with moving defer dates all the time. Defer would really be a topic for projects that should become active in the future. It’s not active now, but is it then a someday/maybe item? Or should I have a look at it during the review of the projects list? It‘s not something I work on now, so probably no.

I think, I‘ll put it on someday/maybe for now. Thanks for your replay.

PS: Really appreciate your plugin related posts. Your JavaScript is crazy (in a positive sense).

I use DEFERRED on actions or action groups but not on projects to indicate that something external limits when the action step can be taken. By example, I have a next step to post an answer key to an assignment, but that step is deferred until (just after) the due date of the assignment itself.

I use ON HOLD for projects but not actions or action groups to indicate either that something external limits when the project should become active or to push a project to a state of “someday” status. By example, I have a project to compile and post final grades for a course that has no business being active until (just before) the end of the course itself, I have a project to clean up the yard at an off-site location that has no business being active until I arrive at the location, and I have a project that I someday hope to start on writing a book.

Finally, I have a someday tag that I set on miscellaneous one-off actions. I can toggle this to active or on hold and include/exclude it from perspectives as desired. For example, at some point some time ago, I made a one-off action note to purchase a certain book “someday”, and that action is still sitting in my “Dreams” project with a “someday” tag.

Hope this gives useful insights.


Yes, I only use defer dates on projects which to indicate that I can’t start working on them until a specific date, not to reduce my project list.

Thank you for your kind words. I have been able to post to much lately because I was really busy, but I am planning to continue in the future.

I too appreciate that you have been helping in the automation sub-forums. I’ve seen your Things to OmniFocus export shortcuts.

1 Like

Could you explain why, for you, these are disjoint sets ?

(If I may use the expression)

Perhaps again this …

  • DEFER - a task or action group that has a date-specific external limitation on starting it
  • ON HOLD - a project that has an external limitation on continuing it or that I am deciding not to continue at the current time

The two distinctions are a) defer is solely for tasks or actions groups (never for projects) while on hold is solely for projects and b) I defer a task (or action group) when doing it is limited by an external factor that has a date while I set a project on hold to reduce the number of active projects on my plate.

Otherwise, the two settings that I never use are (tasks or action groups / on hold) and (projects / deferred). Correspondingly, a task (or action group) is never “on hold” (but the project that contains it may be), and a project is never “deferred” (but a task or action group within it may be).

I also track the status of my OF projects in a Kanban style board (on deck, in orbit, on radar, to land, on hold) with tags for focus (now, next, whenever, delegated, paused). I start with decisions based on the project board and move to OF to correlate with defer or flag on tasks as well as active or on hold for projects. In this regard, I use OF primarily to establish a healthy level of “task awareness” than to manage projects.

Hope this offers a better explanation.



Thank you for your explanation. Perhaps I missed a detail in my question.

You can’t set On Hold status for tasks, but you can definitely set a defer date on a project. Why don’t you do that ?

So my question really is: why do you set a defer date on actions but not on projects ?

I prefer to consider defer as an action to apply on to tasks. Perhaps, in one way, this is my counter approach to the fact that OF only allows me to put projects on hold but not put tasks on hold. In addition, I do not defer something unless driven by an external date limit. When projects are “date limited”, I take a different approach. As a case in point, suppose that I have a project “Paint (Vacation Home) Hallway” that cannot start until I arrive at the vacation home. I do not defer the project. Instead, I put the project on hold and set the next review date for the week before I leave to the vacation home, renewing daily.

Alternatively, I imagine, should I have to start deciding each time about whether I want to defer or hold a given project, my head would explode trying to go through the variations in if-then-else-endif or switch-case logic analysis steps. :-)


1 Like

I appreciate your reply.

Isn’t roughly the same effort deciding when you are going to set next review date then deferring the project ? Perhaps, I am missing the point there.

Oh, so you force yourself to not use defer on projects so there are no decisions involved. Your only option is setting On Hold status, right ?

To the first question… It is not about cutting between the different efforts involved (that may or may not be the same). It is the religion that I have decided to follow in order to best blend my approach using Kanban project management with the options in OF for task management. To the second question, most simply … yes. Granted, I may seem to cheat by playing with setting defined review dates (and other things) when I could just defer the entire project to that date. But such inverse thinking plays a bit of havoc with my approach using my Kanbans and would cause me to have to think perhaps with each project (which I do not like doing as preferred to having a recipe for all cases).

Hope this helps.


1 Like

Here are my 50cents.

The main reason to use on hold for projects is to be able to remove a project from my current commitments. Or in simpler terms: I just don‘t want to see any actions from any of these projects on my list to focus on the outcome of fewer projects.
In some few occasions, when it absolutely doesn‘t make sense to focus on the projects before a certain date, I use defer.

They don‘t offer an on hold status. Therefore, I either have to set them to someday/maybe (tag with status on hold which makes the action unavailable) or defer. Again, I use defer only when it doesn‘t make any sense to start working on it before a certain date.

Action Groups
Sometimes there‘s a larger project with multiple outcomes. Then I use action groups to bundle the corresponding actions to each outcome.
Now what happens if e.g. I cannot work on the 2nd and the 3rd outcome before I finish the first one? In such cases I often set the project to sequential. Which makes action groups 2 and 3 unavailable or blocked which is the term used by OmniGroup for that. With that all embedded actions get unavailable as well.
Within action groups I sometimes set them to sequential as well.

Finally, there‘s no perfectly correct or perfectly wrong. It‘s just to use the OF mechanisms to your advantage. Still, I try to stick to simple rules. At least rules I personally consider simple. Others are probably well with more complex rules as well.