I’m curious to hear how you would approach this project:
I am trying to decide between one large project with 5 sub-projects or have five smaller projects that auto complete when the last task is done. What I don’t like about one large project is that it never feels like i’m “complete” with Hot Tub Maintenance. .
I know this is a preference question, but I wondering how others would approach it.
I’d put it in one project, mostly because I’d otherwise foresee going to the store for monthly supplies then realising after getting home that I need something for every four months as well. You could probably avoid that scenario with tags and perspectives but I’d find it easier to review the whole thing at once.
I try to avoid action groups for this purpose. To me, action groups are more like “actions with pre-requisites” than they are a hierarchical organization of tasks.
Action groups don’t show up in hierarchy, even with “Show project paths” turned on, so it can quickly become unclear what outcomes actions are expected to work towards if trying to treat action groups as hierarchy in any view other than a project-based one (I tend to mostly work from tag-based views).
For me, each action (or action group) is its own distinct activity, where for action group actions, it is blocked by other things that have to happen first. So for this case, I’d use multiple projects, and I’d honour the repeats for each of those projects.
YMMV, though, it really depends on whether you tend to use project- or tag-oriented perspectives.
Thanks for the thoughts! I wanted to circle back and share what I ended up doing.
I split this into several smaller projects. The first task is flagged which shows up as a part of my daily workflow. I decided that it is easier for me to visualize what is happening and I enjoy the feeling of finishing a project, even if it is a small one. I am going to add other maintenance projects into this folder.
@dfay, haha about hot tub is relaxing! I think it will be more relaxing when I have the feeling that everything is under control.
I’d definitely do separate projects. Stuff that repeats on different intervals are clearly separate projects in my mind. The only exception for this in my mind, is single action lists where I have some isolated tasks on repeat.
On the other hand, I seldom do as detailed checklists as you do. If I’m standing over a hot tub, filters and hose in hand, I don’t want to pick up my phone for each step, checking off things as I go. Which is how I define how fine-grained I want my projects to be. There is no need for separate steps if I don’t see myself doing only some of them at a time.
Yes, this is super fine grained— a little too much. I’ve been inspired by the Checklist Manifesto which says that checklists help reduce errors even with obvious steps. For example, a surgeon who has performed thousands of surgeries might forget to wash his hands on occasion. The checklists reduce stress and increase the odds of getting it right. That being said, I sometimes wonder if it is better to keep some of the checklists outside of OmniFocus, i.e. a printed piece of paper where I keep my chemicals.
Yes, you are correct that maintenance is on-going and never ends. For me the beauty of Omnifocus is I can complete a maintenance step and then I don’t have to think of it again until the next maintenance step. I’ll never be done changing the oil on my car, but I’m certainly not thinking about it (or seeing it in OmniFocus) in-between oil changes.
You’re right…, Action groups only have meaning in project view, but if you view the same project under a context perspective, there is no hierarchy whatsoever. The parent action on the action group gets displayed as one more task, in whatever relative order to all tasks whithin the project, excepto that it is grayed out. I wish there would be sub-projects as opposed to having to group smaller projects in a folder.
Yet, if you want to have action groups (for planning /conceptual purposes) and still be able to display these actions together in a context perspective (for execution, knowing the desired outcome of the action group), you may define a different context (tag) for each action group and a context (tag) based view of the project will still show you all tasks belonging to an action grouo together, under the action group = context name.
Love Checklist Manifesto… I prefer keeping the checklists in the notes section. In case of Atul Gawande, in a surgery situation, all the items in the checklist happened at once and didn’t change context.
I’m a big fan of checklists, and The Checklist Manifesto is one of those books that I wish I had written. I have experimented with keeping checklists inside and outside OmniFocus. My problem with checklists outside of OmniFocus is that I don’t work through them as methodically as I do when they are actually in OF. I find being able to actually click a button to check them off when done is helpful to me. So, I prefer them to be in OF. However, sometimes, I’m so overwhelmed by administrative checklist items that the important things get obscured. My experiment continues!
Currently, I’m trying a mixed mode. I have certain checklists stored in TaskPaper format saved in Drafts and then when I’m ready to do the thing I need the checklist for, I send it as a template to OF. This system works great for the projects that I’m using it for.
