[denrael]

I've been spending time here at the end of the year, rethinking my implementation of OmniFocus and, on a broader perspective, GTD. I've come to the conclusion that I think I've been making my projects too broad of a scope. For example, I have a project surrounding monitoring my mom's finances. Tasks within that might be insuring that her IRA transfer occurs between IRA and investment account. What that amounts to is that the overall project really has no end to it, and tends to have a myriad of unrelated tasks in it.

Where I am coming to is I think that should more likely be a folder, representing an area of focus, and the project should be resolving mom's mandatory IRA withdrawl for the year. Something smaller, with a visible finish to it.

I'm curious how others define projects, with regard to scope, and size.

[whpalmer4]

You have two main options, in my opinion.

One is to have a folder that contains all the activities, with a collection of projects (File 2012 federal tax return, Take 2011 IRA distribution, Open new investment account, etc.) You'll probably want to have a single action list in there to handle miscellaneous tasks that don't really rise to the level of being projects.

The other approach which might make sense is to have a single action list in place of that folder, with action groups (nested actions) instead of projects. I use single action lists in place of projects when it's something that has no definite outcome (Pet care, Exercise) and I don't need all of the tools that OmniFocus offers, such as being able to review those "projects" individually, put them on hold, or drop them. No need for a "miscellaneous" catch-all in this case, as those actions just go in the SAL.

Probably the former approach is better for this particular scenario, but for lighter weight jobs the SAL approach keeps the number of projects down (which means the names of the minor things aren't popping up in project name lists).

OmniFocus makes it relatively easy to convert between one form and the other, so it isn't a big deal if you decide the initial approach you've taken isn't the right one. To convert from a single action list to a folder + projects, create a folder, select the top level actions and groups and outdent them via cmd-[ (converting them to projects), then move them to the new folder. To go from the folder to a single action list, create a single action list, then select all the projects and drag them into the single action list.

[denrael]

Some good talks there. I actually had not thought about single actionless as you described them using the Action groups within them. Normally when I've used single action list they have been without the grouped items which is strange because I love grouped items elsewhere. Thanks.

[whpalmer4]

Something that may not be obvious about single action lists is that you can set those action groups to repeat just like projects, if you have something that has a few steps and needs to be repeated. For example, that Pet Care SAL could have a repeating action group that has actions to make an appointment every year with the vet for a rabies shot for the dog, put the new tag on the collar, file the vaccination certificate, etc. Use a start date along with the repeat so the next instance doesn't become available until the proper time.

Originally Posted by whpalmer4

That Pet Care SAL could have a repeating action group that has actions to make an appointment every year with the vet for a rabies shot for the dog, put the new tag on the collar, file the vaccination certificate, etc.

I always had problems to define a project and saw in your other posts the advice that a project should have an endpoint. That makes sense to me. Right now I have some projects like the one above for my dog's medicine (call vet, fetch medicine, give it to dog daily, call vet, fetch medicine, give it to dog daily, call vet...) and some other things. Beside that there are some SALs in my Pet-Folder (Miscellaneous, Healthcare/Vet, Action and Fun, Dog School).

The "repeating projects" clutter up all my "real" projects. Would you recommend to turn these ones into action groups and put them in their related SAL? But at my first look there are some disadvantages for this. For example, I can't add any action via Quick Entry into a action group, only into the SAL the group lives in and I can't put a action group manually on hold, right? If the group is repeating it puts itself on hold or just paused depending on the dates.

[whpalmer4]

Potential disadvantages to collecting items in an action group instead of a project or single-action list include:

• No "on hold" status for action groups
• Can't "drop" action groups
• No independent review status or functionality for action groups
• Can't add things to action group by name from quick entry or Inbox

Except for the independent review status, and the lack of a name visible to quick entry or the Inbox, you can fudge these after a fashion by using a start day way off in the future. Not perfect, but workable. The lack of name visibility can also be seen as a feature, if you're trying to declutter and the contents of the action groups aren't going to change frequently.

I wouldn't lose too much sleep over making the perfect choice here. You can convert projects into action groups by dragging them into another project or single-action list in the sidebar. You can convert action groups back into projects by dragging them out. Try it both ways, and see which way works best for you.

As for the distinction between parallel project and single-action list for ongoing areas of responsibility ("projects" with no endpoint), it's again not a big deal for me. Conceptually the single-action list approach is perhaps a bit cleaner, but an equally valid point on which to make the decision might be whether you prefer the next action view behavior of a parallel project (shows the first available action reading down from the top) or a single-action list (shows every available action, and by default, styles them a bit differently). Again, easy to convert back and forth if you decide you haven't made the right choice, and there's nothing preventing you from doing some each way, if that works best for your needs. A list full of "little" things that you won't need to choose from the whole list might contribute a bit less clutter if a parallel project is used; a list full of "bigger" things where you want everything to get some visibility might be better suited as a single-action list.

Thanks, that helped me.