I haven’t coughed up the $10 but according to the sample of his Setup Guide for Omnifocus we shouldn’t use Sequential projects.
we recommend only using the Parallel type for all of your projects.
…
We have found the Sequential type to be far too limiting for most people’s needs, by forcing you into only one next action.
I’m coming back to OF after a while (I’m new to version 2) so things may have changed. But if Dave Allen say so, it must be the best way to set OF up? But I’m not convinced…
I find that sequential projects can be very useful - especially for more routine projects where there’s a very specific and logical order for accomplishing actions.
On a side note, groups can be either sequential or parallel. So, you could have a parallel project that contains one or more sequential groups. Similarly it might make sense to have a sequential project that contains one or more parallel groups.
I agree. I can think of many projects in which one action depends on the previous having been completed. I’m not sure why the Setup Guide should advise in the way it does. Maybe it’ll cost me $10 to find out!
I’m sure there are may Things users who have come over to OF simply because of Sequential projects.
Exactly this.
It is not one choice per project (parallel or sequential), you can choose a different setting for every action-group at whatever nesting-level you want.
@vloris Exactly. You can have any combination of sequential/parallel groups within a sequential/parallel project. You could even have, for example, a parallel group within a sequential group.
Sorry, all, to necropost, but this is just too funny. He writes, in that sample:
Have you ever known, when starting a project, exactly what the steps are in the project, in the exact order that those actions should happen, with no new variables along the way?
Uhh, yes. Yes I have. I’m building an illustration for a client right now, and I know for a fact that “v1” comes before “make revisions to v1” – and that (several steps later), “send invoice” comes after “send finalized PDF”.
One thing I’m a little flummoxed by right now with Omnifocus 3 is that I’m finding attaching a due date to any task in a sequential project unblocks that task even if it’s a few tasks down. In my example above, there’s a due date for the final PDF of the illustration, but it’s still blocked because I haven’t gotten through v1, v2, etc… I don’t remember this in earlier versions of Omnifocus, but maybe my memory is faulty?
That sucks. One of the most useful things about GTD is the abilty to forget what isn’t needed at the moment. Hope you submit a feature request - I’ve just started w OF3 but I’m sure this will annoy me at some point, too.
All this time I thought the GTD methodology was about doing the Next Action and then the Next Action until the project was complete.
parallel projects allow any task to be the next action and in my head that means you’re gonna spend time trying to work out what to do next every time you visit the project…
I approach projects with a what do i do first, and then what, and then what thought process, so at least a few of the next actions are in place - I’d agree that some projects are parallel, but there are some that are much easier to manage as sequential, even if the order isn’t strict - by doing one thing at a time and completing it before seeing the next helps avoid overwhelm.
I have a lot of projects that are sequential - checklists to make sure a process is completed - not using sequential projects is bonkers.
I emailed them about it. Also, I just realized while creating some other projects that the later item in a sequential project will become unblocked only when it crosses the threshold of “due soon”.
So I’m gathering the idea is that tasks with looming due dates come up even if they’re blocked. I guess this is useful in practice, but I personally would prefer to just let them remain blocked. I mean, due or not, if an earlier prerequisite (if it’s truly a prerequisite) is not taken care of, the deadline is gonna get missed anyway.
I sort of agree with David Allen in that truly sequential projects are more rare – but I think that because they’re a more specialized kind of project Omnifocus should treat them according to their rules: an earlier item blocks a later one and that’s that. If it didn’t, we wouldn’t be using a sequential project in the first place :)
Well, in Projects, for one – and any Perspective where I’d be seeing the matching tags. The issue isn’t that the blocked tasks are appearing first, it’s that they’re not greyed out as unavailable when they should be. In the screenshot below, removing the due date from the second two tasks renders them unavailable as they’re supposed to be.
Also note that if the due date is pushed back later (next week, say), the tasks go back to being blocked. It’s “due soon”, I think, that triggers them to become available.
But I am on the beta channel for updates… You are currently running OmniFocus 3.0.2 test (v119.19 r318892 built Sep 28 2018), which is the newest version. If you wish, you can downgrade to an older, but possibly more stable, version.
If that’s happening, it’s definitely a bug. Are you seeing this on iOS or macOS or both? Please email it in, either way! (Unless it’s already fixed in the latest test build.) Thanks!