Project definition/format: full vs task+subtask form

[Yodude120]

Hello all,

(long thread -- brace yourselves )

I would like to get some feedback for what you think about how "projects" are defined and how they should accordingly be handled.

Up until now, I have never adhered strictly to DA's rule that a project is anything that requires more than 1 step to complete. This is mainly because, if you apply this rule consistently and recursively, you can easily end up with a list of a couple dozen (or even a couple hundred) projects, and these often involve very small stuff (essentially you will get projects that are merely a collection of other sub-projects, and so on and so forth until you have projects of projects of projects ...). Obviously having so many "projects" is nothing wrong in itself, but it definitely has some disadvantages: for example in prolonging the time it takes to complete a (small) project from start to finish (and consequently having small projects take very long to finish when they can be discretely/punctually finished in a small time), the need to have any further ideas on the (small) project go through the processing step and lumped with all the other projects, and also the problem of waiting for the weekly review to see how to progress further on it, on the other hand you also introduce constant topic and task/project switches while completing tasks with this definition -- a very important disadvantage if you know some neuroscience -- among other disadvantages.

While the "project" appellation (& corresponding handling) very definitely holds for "projects" in the common sense of the term, it does not hold for what I call mini-projects: stuff like changing a light bulb, taking apart your IKEA chair and doing some maintenance on it, etc. I have always, nearly from the start of my practice, handled these in the now-ubiquitously-supported task + subtask form (in a digital todo manager). With this strategy (keeping the full "project" status/header for *actual* projects on the projects list and mini-projects simply on the Next Action & other lists) you have big advantages, like focusing on a big task that requires maybe a couple of hours or a whole day from start to finish until you get it done, processing whatever ideas you get for it on the spot / ad-hoc (for example grabbing some lube/oil & lubricating the IKEA chair joints on the spot etc). A main advantage is also avoiding those brain-taxing topic/project switches.

The way I understand it (and some other people in the communicty share my opinion), the raison-d'être of a project definition according to DA's terms is that in case you finish a next action on a project, you need some form of reminder somewhere in your system to tell you the final outcome is still unfinished, to know that you still have to do work on this project and that you need to define a next action for it (e.g. during the next weekly review). However this is really a non-issue in modern todo managers / organizers because if you have a clearly defined parent/big task and subtasks, it will be self-evident if the main task is not completed even if you complete all its subtasks, in which case you would directly think of why this is the case and come up with / complete the remaining actions on the spot. The other raison-d'être for DA's definition is to be able to quickly assess your workload based on the project list. But I would argue this isn't possible if you apply the strict project definition, and the workload is NOT determined anyway by the number of projects (esp. when they're of those "mini" variants) but by the breadth and complexity of projects, for which the number of *big* (or commonly-defined) projects is actually better as you can more easily get a feel for that with a small/high-level projects list compared to a huge project list. For example, you can obviously see how it's easy/difficult to assess workload (or get an overview) for the following 2 persons by only checking their projects list (projects indicated by P, SP for subproject -- full project split off --- SSP for sub-sub-projects etc):
- Person A (applying the split strategy): P- moving cities (SP - switching health insurance, SP - finding a new home/appartment), P - starting a job (SP- contract paper work, SP - getting a work permit for it) etc etc
- Person B (applying the simply 1+ NA strategy recursively): P- moving cities (SP - switching health insurance, SSP - finding and deciding on a good insurance company ,SSP - setting up an insurance consultation appointment and on and on); P - starting a job (SP - contract paper work, SSP - preparing and finalizing contract X, SSP, preparing and finalizing contract Y etc etc, SP - getting a work permit for it, SSP - setting up an appointment with the local immigration authoriries, etc).

Note that I added the SP and SSP indicators and the separation myself, but if you apply the DA definition & recommendation from the book as-is, you simply put all those P, SPs and SSPs on the same project list -- and unless you do more advanced things -- 1) you don't have a good and efficient way to see the relationship/hierarchy between them and 2) the overwhelming amount of SPAM on that list (e.g. setting up an appointment) makes you absorb so much information while reading the list, and have to separate the wheat from the chaff in terms of scale/breadth, that you actually end up unable to judge your workload and its sources only from reviewing that list (esp. because some stuff on that list actually are wrappers that contain other projects). I feel projects need to reside in the 10000 feet range, and things start getting messy if they are defined in the 2000-4000 feet range and lumped in with the 10000-feet projects on the same list with no distinction. The assessment of workload definitely should happen at the 10000-feet level and would go murky / get overwhelming if it includes lower-level and/or overlapping commitments.

Of ocurse, this kind of split-strategy only works provided you actually do the clarification/processing work before, regardless of the format you save it in. Although this is not straightforward/possible in some cases (for example in research where the work is sometimes very unpredictable), you generally need to think of the very actual next actions even when you decide to save those in parent task + subtask form.

It's interesting that DA himself actually mentions/recommends this kind of split strategy sometimes ( "If there’s a good chance that a project can be finished in one sitting, in one fell swoop, then probably best to label it simply a next action and put it on your action list" https://gettingthingsdone.com/2010/02/managing-projects-tips-from-david-allen/ ) -- this is precisely the case where I think the task+subtask form is much more efficient. From what I understood from the GTD book (read both the 2001 and the 2015 ed.) this is really more of a tactical/strategic implementation choice that concerns managing projects and subprojects, and according to DA it's all really unimportant / just semantics provided you review everything (i.e. you pass over those next-action-like mini-projects at least once and assess whether there is a problem/lack of progress/shift in priorities/or all is ok). Some discussions in the community also show how the simple/strict 1+ NA definition can go overboard (see my previous post (missing some content weirdly) on https://forum.gettingthingsdone.com/threads/finalizing-gtd-tips.12302/, Jon Walthour"'s post on https://forum.gettingthingsdone.com/threads/action-directly-from-the-project-list.7187/#post-57879 , maybe also https://forum.gettingthingsdone.com/threads/how-to-define-a-project.11649/#post-93368 and https://forum.gettingthingsdone.com/threads/help-reviewing-is-driving-me-crazy.10558/#post-83669 ). In other cases the community has mixed opinions ( https://forum.gettingthingsdone.com/threads/how-big-are-your-projects.5426/#post-5426 ).

It all comes down to practical questions, really. It seems to me to be overkill to process/clarify input on, come up with options (ideas for incubator / Someday / Maybe etc) for, and review weekly projects like "take apart & relube/retighten IKEA chair" -> it just becomes ridiculous overhead; and the problem is if you dedicate 2 hours (or let's say even 3) a week to your weekly review / reviewing projects, the fact of the matter is if you have 100-200 projects this means you can't spend a little more than a minute reviewing each project. From my GTD knowledge & practice (4+ years now), this would be nearly a useless review (reading a list of projects is not the same thing as reviewing the projects on that list). The whole point of a review is getting a feel for the whole in a project (not missing the forest for the trees !), getting creative by making connections between different project components, bringing stuff up-to-date, evaluating Someday / Maybe items that have maybe become interesting/neeeded etc, reviewing support material etc -> there's no way you can do this properly and exhaustively for more than 20-30 projects per week in just 2-3 hours weekly (more like 6-12h weekly).

(continued)

 

[Yodude120]

(continuation)


A proper project review takes at least a couple (~5) of minutes per project. It therefore becomes crucial to park those mini-projects that can be done in one fell swoop on the next actions list (or waiting for etc), and treat them differently from regular projects. Though admittedly, this can only go so far and if the project exceeds a certain complexity/size than you just have to revert to the fully-managed project form with reviews etc (though for the mini-project having steps requiring multiple contexts you can still handle that in task + subtask form via tags). Especially considering your usual 5-30 projects --- in the more common definition of the term --- are generally of some complexity, you need to be able clearly see what's important to get them moving, what's stalled/waiting, what's blocked (by other stuff etc), what's good to keep in mind etc, and I don't see an elegant way to manage this if you break off every single small part of them into another project (DA himself says in the GTD book there's no perfect way to manage these hierarchies of projects) -- I therefore prefer using projects + subordinate parent task+subtask components, to faciliate stuff like maintaing a whole view (e.g. via a single project tag) and still being able to park components for the future/NA/tentative spheres etc. This also allows you to immediately recognize that a sub-component of a project is stalled/waiting (it would be on the waiting list), whereas if you split off the sub-project on its own you would just have it misleadingly reside in the "active" projects list (and if you're putting it on a "waiting for - projects" list along with its waiting for actions/components than you're just duplicating your work). From my experience reviewing projects in this more wholistic form can spark a LOOT of creative thinking / solve issues.


I'd love to have some feedback from the community in case somebody has some ideas/thinking/opinion/experience on this. I had some ideas for example to distinguish sub-mini-projects form usual next actions in a big project (maybe by specific tags / dedicated next-action-mini-project list). I've also thought of creating hierarchical lists of projects on the main projects list (using parent tasks for big projects and subtasks with indentation for many levels of subprojects); in this case you *can* split off projects while still keeping a feel for the whole, but even on an advanced task manager like 2Do, it's not possible to have a parent task split its subtasks across waiting for / Someday / Maybe / Next Action lists, but you can still immediately "open" a sub-project and see if what's exactly stalled/moving/tentative/on deck in it (I use tags for this, it becomes as simple as tagging each sub-project uniquely and searching for the tag across lists, but depending how much you flesh out you'd end up with many more tags than usual and lose again the forest for the trees..).


Thanks for your comments / feedback / thoughts

 

[mcogilvie]

DA says whether you list subprojects on your projects list is up to you. He also says it's ok to use a single next action for linear mini projects where there is a single clear next action at every step. Your example of fixing an IKEA chair would not even be a mini project for me, but a recurring next action. That said, a lot of how you handle this issue depends not only on personal preference buton the tool you use. Paper and Omnifocus are very different. I think there is value in discussing how different people handle these issues using different tools, but I don’t think there’s a general theory. There’s nothing like a few thousand next actions to find out what works for you and what doesn’t in getting things off your mind.

 

[kelstarrising]

Yodude120 What's the bottom line of your post?

 

[Gardener]

Assorted thoughts:

It sounds like you have a LOT of stuff in your project lists, as opposed to in project support material, ideas lists, etc. I'm not saying that you have an unusual amount--many people seem to keep a lot of stuff in their project lists. I, on the other hand, keep an absolute minimum there.

I think that this can be seen in terms of what you're optimizing for. Having all your projects planned out and arranged and each one having perhaps several Next Actions is optimizing for opportunity--it makes it less and less likely that you'll ever have a spare moment when you don't have the right task information at your fingertips.

It also makes it less likely that you'll miss a link between projects/tasks due to not having thought about that project/task lately.

But I feel that that's at the cost of a lot of reading and scanning and "brain full" consequences. And that while you will have thought about a lot of things lately, you will also have thought about a LOT OF THINGS lately, and so focus may be degraded.

Lately, I am ruthlessly optimizing for focus. This means that I don't just demote things to Someday/Maybe, I demote them out of my project lists altogether, out into "ideas lists", which I would put in the category of project support material. Things in my Inbox are more likely to flow out of the system (where here I use "system" to refer specifically to the project/action lists) than deeper into it. And I don't have subprojects or subtasks, and I prefer to have just one action per project.

I'm saying all this for context. Or something.

Re: "the need to have any further ideas on the (small) project go through the processing step and lumped with all the other projects"

This confuses me. I don't think that there's anything to stop you from adding an idea directly to a small project rather than taking it through Inbox/Processing. I may be wrong? Does GTD frown on this?

Re: "and also the problem of waiting for the weekly review to see how to progress further on it"

Similarly, I don't think that you have to wait for the weekly review. I see the review as "Make sure you give this attention." rather than, "Don't give this attention until."

Re: "on the other hand you also introduce constant topic and task/project switches while completing tasks with this definition -- a very important disadvantage if you know some neuroscience -- among other disadvantages"

Can you clarify this? I'm with you on the problem with task switches--hence my optimizing for focus. Where I'm unclear is with the idea (if this is what you're saying?) that the way that projects are defined would cause the brain to perceive something as a task switch or not. It's an interesting idea, but I'm not quite getting it.

Re: "stuff like changing a light bulb, taking apart your IKEA chair and doing some maintenance on it, etc."

I would consider these single actions. I've always felt that single actions are, to a great extent, dependent on the person and their level of expertise and knowledge. Since I know how to change a light bulb, for me that's a single action. For someone who's never done it before, it might be a project. ("Ask Joe how to change a light bulb." "Bring old bulb to hardware store get help in buying new one." etc.)

So for an expert baker, "Bake cake for dinner party" may be a single action. For someone who's never turned on an oven, it may be a six-month project with several dozen actions.

Re: "It all comes down to practical questions, really. It seems to me to be overkill to process/clarify input on, come up with options (ideas for incubator / Someday / Maybe etc) for, and review weekly projects like "take apart & relube/retighten IKEA chair"

I don't see that GTD asks you to do that, though. To me, that's a single action even in strict GTD. If I were sitting in my chair and found it to be behaving badly and knew how to fix that, I would type "Desk chair maintenance" into my Miscellaneous project as a single action, and that would be that until I get around to working that action. Of course, if my system isn't handy, those words might land in an Inbox instead, but I wouldn't do a lot of thinking about it--when I got to handling that Inbox, I would again just type in the action.

Re: "if you have 100-200 projects this means you can't spend a little more than a minute reviewing each project."

This is where my preference for short lists comes in, because I would never have 150-200 active projects. For me, if there were 200 threads, odds are that 175 of them would still be in lists outside my project/next action lists, and 15 of the remainder would be in Someday/Maybe and getting only cursury weekly review. ("Any chance I'll start that this week?" "Very funny.")

(Remember that this includes the fact that the light bulb type things would be single tasks, not projects, so it's not quite as small a number as it sounds.)

The remaining 10 or so would be represented in my lists, but much of their detail would be in project support material. So, for example, instead of a project "Choose carrot variety" I would have a project named something like "Create and finalize 2019 seed list". It might occasionally get a very specific action ("Google to figure out what that huge carrot was." "Send off for a paper Territorial catalog" "Ask Janet about those peas.") but much of the work would be represented by actions rather than explicitly detailed in them.

Re: "I don't see an elegant way to manage this if you break off every single small part of them into another project"

I don't put all this stuff--the many possible subprojects, the tasks under those subprojects, etc.--in my GTD lists. I put them in project support material. Only what I'm likely to work on in the near future goes in my lists.

This comes back to what I'm optimizing for. I realize that this eliminates the advantage of having everything right there, ready when I, say, finish something early, or enter an unusual context that I should take maximum advantage of. To me, this cost is much less than the cost of splintered focus.

And for the "unusual context" I can plan ahead and structure project support material designed to deal with that flaw. For example, if I know I'm going to go to Britex (San Francisco fabric store) for the only time in six months I might actually create a "prepare for Britex" project, with things like, "Go through Sewing Ideas list with an eye to what I might want at Britex." The result won't be quite as perfect as it would be if I had fully planned all those sewing projects, but that's not what I'm optimizing for.

For situations like discovering that my plane is delayed and I have six hours in the airport and I run out of important tasks for that context...eh. That's just not important enough for me, personally, to optimize for it.

This is all talking about personal rather than work stuff. For work, I'm making my lists even thinner, because I haven't had access to a good tool like OmniFocus. I've started using Jira, and may allow them to get just a bit fatter again, depending on how that works for me.

 

[Yodude120]

Yodude120 What's the bottom line of your post?

hello kelstarrising ! thanks for checking in !

The bottom line is this: I am really ambivalent currently about what's optimal (esp. for these small projects): my own task+subtask form (using a digital todo mamager) or the form recommended by DA elsewhere with separated project headers on the projects list and actions on the Next Action list (tool-agnostic). I have a lot of pros & cons, leaning for the former, but I'm still trying to find out if there is benefit to still adhere to the second format all the time.

For now after my little research I feel there's more benefit to the first form (I currently have an R&D project for this -- this is definitely something I would devote a project + reviews to )

Therefore I wanted to probe the community for what experienced GTDers think.

 

[Yodude120]

It sounds like you have a LOT of stuff in your project lists, as opposed to in project support material, ideas lists, etc.

actually with the split-strategy I'm adopting, I'm doing precisely what you'Re doing. I only call a "project" what any person lambda would call a project, I'm not using the 1+ NAs definition. I usually have 15-20 projects at MOST (and I've had *pretty* *pretty* hectic / busy periods) -- but these are wrapper projects which define big outcomes (moving, finding a new house etc). On the other hand, since I have all plans for the project already planned out as next-action-like elements but ticklered for later, as well as options in Someday / Maybe format, my project reviews (and I would argue anyone's project reviews) just won't fit in 1 min.

I think that this can be seen in terms of what you're optimizing for.

again, I'm really sticking to the task+subtask form for a lot of stuff now, usually a lot of these are under AOFs / bigger projects. Most big projects are outlined using several sub-projects in grouped-next-action form.

It also makes it less likely that you'll miss a link between projects/tasks due to not having thought about that project/task lately.

I've found an elegant solution for this: tagging. Everything related to a project is tagged with its tag. A search for the tag then lets you see exactly what the project involves, and that across all fixed lists (waiting, Someday / Maybe, Next Action lists, on deck / ticklered actions). But again I think this isn't manageable if you have 100-200 projects in the "strict" 1+NA sense.

I demote them out of my project lists altogether, out into "ideas lists"

hmm interesting, I'Ve also set up a "non-commital projects" list recently --- essentially Someday / Maybe projects. Actually, a huge chunk of my system is made of Someday / Maybe / options --- I find these can support a lot of creativve thinking without committing to anything, especially useful in research.

I don't think that there's anything to stop you from adding an idea directly to a small project rather than taking it through Inbox/Processing. I may be wrong? Does GTD frown on this?

hmm in principle this is ok, but wouldn't it be a bit like preferential treatment for certain incoming information/ideas ? I guess that's ok though, many times (even GTD coaches) have OKed this.

I don't think that you have to wait for the weekly review. I see the review as "Make sure you give this attention." rather than, "Don't give this attention until."

you have a point here, though I think there's value in restricting review time to the weekly review --- unless crisis dictates otherwise. There's a fine line to be crossed in reviewing too much (instead of doing).

(if this is what you're saying?) that the way that projects are defined would cause the brain to perceive something as a task switch or not.

what I mean is if you have the projects and NAs organized in the "full-featured" form (not in task+subtask form), i.e. with the project outcome on the projects list and associated items on other lists, you will generally not feel the need to directly specify new next actions when you complete existing ones; this is in contrast to a next-action (incl task+subtask form) where there's a clear tendency/expectation to start and finish it in one fell swoop with no interruptions. Unless you adopt a sort of express-processing / preferential inbox/idea treatment for this specific project (cf above), you will generally finish only the current NA(s) under it. This is because the project is not right in your face as in task+subtask form, where you you instantly know that finishing a subtask only leads to the following subtask or whether the project/parent task is still not finished in spite of finishing all the subtasks (& keep on working on it accordingly until finishing). You generally don't invent another NA for the same project when it's in the "full form" but rather switch to another already-defined next action, probably under a different project since you just ran out of NAs under your first project, that is until the whole GTD process gets/forces you again to produce a next action for the first project. What this translates to -- again in absence of absolute / targeted focus on that single project, rapid definition of its NAs instead of jumping to other stuff -- is switching projects/themes constantly. There is a catch here of course, in that you *can* choose to focus on this project alone, i.e. finding a NA for it directly/express and starting that instead of just picking up another NA from another project, but this usually requires some way to overview everything under a project, usually a tag to identify it or any other way to have it retrievable in full right in your face and not with other projects) and/or to do a proper review for it. But then again I am skeptical how many such tags you can realistically maintain if you start doing defining projects on the projects list like according to the 1+ NA definition. Even advanced/very capable task managers will probably start having problems with this.

Re: "if you have 100-200 projects this means you can't spend a little more than a minute reviewing each project." This is where my preference for short lists comes in, because I would never have 150-200 active projects.

I absolutely agree. This is precisely why I get phobic of hearing "150 projects" or even "600-700" (yes I've really seen this on these forums). You're just not reviewing at all anymore (at least not reviewing like DA actually recommends), you're probably just looking at the project header and that's it. Same parallel for workload overview --- you might very well have 600-700 projects but if those are exchanging lightbulbs etc, you're just kidding yourself in terms of your workload. This is why I'm very reticent to switch to the strictly-defined 1+ NA project form. For me too a ton of mini-projects are lying around on my Next Action list, but I don't review those like this (except when going over the header once a week, but nothing like delving into options, waiting items, support material etc). Review time is a scarce physical resource.

This comes back to what I'm optimizing for. [..] To me, this cost is much less than the cost of splintered focus.

precisely, one thing GTD teaches you is awareness of your work or metacognition. Same applies to contexts, if you're *technically* able to do something on your phone on the bus in 20 mins, you shouldn't necessarily put it on the "At Phone" if it would take you 7 mins on your computer --- you're just better of doing it on your computer. A project is a bit like a context (in terms of how the brain works it is actually), I also see a lot of neurological benefit in focusing on mini-portions that you finish all at once, if only for the myriad ways their other-wise splintered form would mishandle the subtasks' inter-connections / dependencies (which the brain handles in a breeze if the'yre all evaluated together, especially if the number is still relatively small).

For situations like discovering that my plane is delayed and I have six hours in the airport and I run out of important tasks for that context...eh. That's just not important enough for me, personally, to optimize for it.

I can recommend adopting a hybrid approach (I also have *proper* discrete next actions on my lists next to mini-projects): create a "shorttime" context for example using a tag, or anything else to identify stuff that don'T need more than 2-3 hours of work ("midtime").

I agree a lot with how you approach your lists. For me the biggest bottleneck here is the weekly review: unless you want to spend your week reviewing and not doing anything, you just can't afford to keep reviewing more than 20-30 projects (actually reviewing and not just reading the outcome of the project and sighing). It's good to see other people customize their lists in these ways. I think what's important is to not deviate from the GTD principles, like not holding stuff in your head etc, whereas maybe management strategies like this are more debatable/individual.