ThinkingRock Forum

One question about GTD methodology. I'll get the book tomorrow but listened a
couple of times to the audiobook version. I didn't understand how to process a
thought when you have multiple actions of a project.
When processing a thought in TR, you can only add the very next action together
with creating a project.

Either you add one action at a time, you don't care about the following actions
and you simply add them one by one when reviewing your projects if the
preceding action is done.

Either you immediately add all actions you already know in the project. That
can be done by reviewing the project after processing all thoughts, but that
means thinking about that project twice, first when you process the thought,
then after to add the next actions. How do you handle that?

Another problem is that if I add all actions for all projects, my action list
get quickly overwhelmed by a bunch of actions I don't want to think about right
now, for any reason.

Here's an example:
Project: Repair the bicycle
A1: Buy a new chain
A2: Clean the bicylce
A3: Place the chain

I know all 3 actions so I would prefer to enter them all immediately. A1 and A2
can be done ASAP but A3 depends on A1 so I don't want to see it right now.

If dealing with the very first action only, should I add only one of A1 or A2,
or both? Then add A3 only when A1 is done?

If adding all actions immediately, should I set it A3 as inactive and mark it
ASAP during a project review? Ideally there should be a way to add dependencies
so A3 would go from inactive to ASAP when I click 'Done' on A1.

How to you deal with such (yet simple) cases?

Thanks,
David

This is something that I would also like to have, the ability to add several actions from the "process thought" screen. I proposed this here some time ago: http://www.thinkingrock.com.au/forum/vi ... .php?p=989 (first bullet).

What I do at the moment when several new actions occur to me while processing a thought is I switch to the Actions or Projects screen, add them directly into the corresponding project, and switch back to the Process Thoughts screen.

Hi David,

Your instinct is right -- since you have two actions that can be done right now (A1 and A2), make them both ASAP. Leave A3 inactive. When you have checked off both A1 and A2, A3 will become ASAP automatically. (This assumes that A1, A2, and A3 are the only actions in your project, and that you have project sequencing turned on.) No need to wait for your weekly review unless you want to.

GTD emphasizes that the next physical action is the only thing you need to keep a project moving forward. However, it also encourages natural planning and figuring out as many steps ahead of time as makes sense. It's perfectly fine to have two next actions for a project -- but you only *need* one.

Thanks for that tip, I didn't know "automatically sequence actions" would turn the next inactive action of a project into ASAP. That will be very usefull.

Another tip from your example: Imagine that A2 "clean bicycle" can really be done at any time before or after you put on the chain, but A3 "put on chain" cannot be done until A1 "buy chain." In this case, I would probably put A1 and A3 into a subproject, like so:

Project: Fix Up Bike
- Subproject: Put New Chain on Bike
- - Task A1 "buy chain" (ASAP)
- - Task A3 "put chain on bike" (Inactive)
- Task A2 "clean bike"

If you set up your project like this, you can do task A2 any time you want, but task A3 will not become active until after task A1 is complete.

I also thought about this though I was a bit afraid of adding an action outside of the project it should belong to. That's not very neat if you look at the projects but at the action level, that really does what you want it to do. Thanks for that tip too, that's great to see how others are using TR and GTD.

As far as I understood, it is actually suggested to include the A2 action into the Fix Up Bike project. Sequencing should only be enabled in the subproject titled "Put New Chain on Bike".

IMHO the whole concept of sequencing should be scrapped in favor of a 'depends on' field added to each action. The current mode of dependent actions depends upon a linear sequence of events when, as anyone who builds a complex project knows, the actions may or may not flow in a linear order where one and only one of my projects actions are available as a next action.

The way TR works around this is to place the sequencing inside of nested sub-projects, but really this is just an added level of complexity that is not needed if we had a 'depends on' field/list that can point to one or more actions in a given project.

With a 'depends-on' field in an action I can blaze away at creating actions within the project, and then go through and look at the natural dependencies of each action and assign their dependency. TR should then automatically place all actions that are pointing to an incomplete action in 'inactive' status. Once the dependent action(s) are completed the inactive action should then 'spring load' into the 'do ASAP' list, completely removing the manual process of reviewing projects for inactive actions that can be promoted to 'do ASAP'.

There is a terrific example of dependent actions in work through the TiddlyWiki called MonkeyGTD (3.0 alpha r9902 is the exact version that has this). It is for this feature alone that I have switched over to MonkeyGTD as my day-to-day GTD tool, but I would love to switch back if this feature is ever implemented in TR.

On our list for a while. I have increased its priority.

_________________
Claire
ThinkingRock Analyst and Tester

That's what I love about MonkeyGTD: You can choose on what action in the project an action depends on, without creating subprojects or anything.
Would be nice to see such a feature in ThinkingRock.

Any action on codemagic's suggestion yet? This one feature alone would cause me to sign up a member. Will not buy TR GTD without it.

The "depends on" idea seems much better than sequencing. I agree with Gray.

Has this been acted on yet? I was a ThinkingRock member about a year and a half ago, but ultimately fell out of use for two reasons. One was that the speed of the filter became an issue over time; the way it loaded the entire list - completed and not completed both - and then filtered became a problem when you've been using it for months and have hundreds of completed tasks. The second was that the lack of the ability to set a task to inactive until a dependent task was completed.

Looking at the 3.0 feature list, performance enhancements and improved archiving make me think the first may be better. If the second were in v3, I'd upgrade again to see how it is doing.

So has it been implemented anywhere? Thanks!

Aaron

The depends on feature has not been implemented. Users are not complaining about performance anymore.

_________________
Claire
ThinkingRock Analyst and Tester

Thanks, Claire! Glad to hear the performance seems to have been taken care of. I'll keep an eye out for the dependency feature across projects, and hope it gets added. Question - do you know if you were a former member if the cost of renewing the membership is $10, or the $40 of a new member from scratch?