Tracking a Project's next action(s)

[cfoley]

Often the effort shifts elsewhere. I don't think there are universally correct answers here. We each have to choose what is important to us.

Consider this scenario:

I've been outside doing @Outside tasks. I took the meter readings and measured some spare carpet in the garage. When I got back to my desk I wanted to add the new next actions: "Submit meter readings" and "Cut spare carpet to size." In this scenario, it turns out that I had enough spare carpet for the floor of my storage space.

In a system that has no links, I can just write my new next actions into the appropriate contexts. Here the extra effort is in remembering the link or writing enough extra information for the link to be obvious.

In a computerised system that is linked, I have to find the corresponding projects in order to make the links. Here the extra effort is in locating the project each time I want to add a new next action.

My personal choice is 3" x 5" index cards. Project on the front, next action on the back. When I do a next action, I usually place the card on my desk so that I can easily write a new next action. Sometimes I don't and that is when I have to leaf through and find the right index card.

 

[ianfh10]

People find it's not always obvious at a glance what Project the Next Action is about.

Why does it matter whether it's obvious at a glance a next action is about a project or not?

This sounds facetious, but it's a genuine question.

 

[cfoley]

Knowing the project is important for choosing actions in the moment. If you don't know what project an action belongs to, how can you make a judgement call on the priority?

It is also important for knowing what to do after you complete the action. Do you continue to work on the project or do you write the next "next action" in the context list.

 

[gtdstudente]

On this end, the general knowing which Area of Focus of the Four Areas of Focus and what they mean to each other for Maintaining/Progressing Project(s)<>Next Action(s) with an intuitive sense of due dates and 'pressure relief' provides all 'grounding' necessary to make the best decision/priority without any 'deliberative wondering' sufficiently facilitates a calm sense of being for doing

 

[mcogilvie]

Knowing the project is important for choosing actions in the moment. If you don't know what project an action belongs to, how can you make a judgement call on the priority?

I have found that knowing the project is not particularly useful to me In the moment. It is a factor, yes, but so are several other things. In addition, the project name Itself does not carry direct priority information.

It is also important for knowing what to do after you complete the action. Do you continue to work on the project or do you write the next "next action" in the context list.

Again, the project link itself does not carry this information. It’s a given that you should recognize with some certainty that a next action belongs to particular project, but the link itself is not necessary. If I need to, I can check project support just fine without it. Most of the time it is not necessary, and perhaps a barrier to progress.

I realize that I am a dataset of N=1, but I have found empirically that directly linking projects to next actions is of dubious value to me. I think David Allen is probably correct that flat lists which separate next actions from projects and project support is the most nimble and most efficient set-up. I have digital tricks that help me get close to this ideal, but I am by no means sure those tricks would work for anyone else. I do think simplification of one‘s system is a valuable thing for anyone to investigate.

 

[ianfh10]

Knowing the project is important for choosing actions in the moment. If you don't know what project an action belongs to, how can you make a judgement call on the priority?

It is also important for knowing what to do after you complete the action. Do you continue to work on the project or do you write the next "next action" in the context list.

Why do you need to make a judgement call on a next action's priority based on its associated project? What about the project gives you the information on what to decide to do next?

Like mcogilvie says, there's nothing intrinsic to the project that actually gives you this information.

I spent so much of my time trying tags, links, copying actions, duplicating actions, moving actions from project lists and back again, that I simply gave up. The overhead was too much. I actually felt so much freedom in just letting go and allowing myself to trust my system.

 

[ianfh10]

On this end, the general knowing which Area of Focus of the Four Areas of Focus and what they mean to each other for Maintaining/Progressing Project(s)<>Next Action(s) with an intuitive sense of due dates and 'pressure relief' provides all 'grounding' necessary to make the best decision/priority without any 'deliberative wondering' sufficiently facilitates a calm sense of being for doing

I'm sorry if I'm misunderstanding but I'm not quite sure what you're saying?

 

[cfoley]

I have found that knowing the project is not particularly useful to me In the moment. It is a factor, yes, but so are several other things. In addition, the project name Itself does not carry direct priority information.

Again, the project link itself does not carry this information. It’s a given that you should recognize with some certainty that a next action belongs to particular project, but the link itself is not necessary. If I need to, I can check project support just fine without it. Most of the time it is not necessary, and perhaps a barrier to progress.

I realize that I am a dataset of N=1, but I have found empirically that directly linking projects to next actions is of dubious value to me. I think David Allen is probably correct that flat lists which separate next actions from projects and project support is the most nimble and most efficient set-up. I have digital tricks that help me get close to this ideal, but I am by no means sure those tricks would work for anyone else. I do think simplification of one‘s system is a valuable thing for anyone to investigate.

Yes, I agree with you 100%. I wasn't advocating for a link in the post you quoted. Rather, I was giving two reasons why "knowing" the project can be useful. You phrase it as "you should recognize... that a next action belongs to particular project". I think you phrased it better than me.

 

[cfoley]

Why do you need to make a judgement call on a next action's priority based on its associated project? What about the project gives you the information on what to decide to do next?

Like mcogilvie says, there's nothing intrinsic to the project that actually gives you this information.

Here is an example. Of these two next actions, which is the higher priority?

• Look up Alice's number and put it on my calls list.
• Look up Brian's number and put it on my calls list.

You can't tell from the actions alone. However, recognising the project can give you the information to decide which is higher priority.

If these are the projects respectively:

• I have a new coffee table for the living room.
• We have a plan for the party.

Then knowing this will help you choose which is the higher priority action.

I spent so much of my time trying tags, links, copying actions, duplicating actions, moving actions from project lists and back again, that I simply gave up. The overhead was too much. I actually felt so much freedom in just letting go and allowing myself to trust my system.

I've tried most of these too and agree with you.

 

[gtdstudente]

I'm sorry if I'm misunderstanding but I'm not quite sure what you're saying?

Please be specific, thank you. Better still, if you so please, refer simply refer to prior post. Thank you

 

[gtdstudente]

Here is an example. Of these two next actions, which is the higher priority?

• Look up Alice's number and put it on my calls list.
• Look up Brian's number and put it on my calls list.

You can't tell from the actions alone. However, recognising the project can give you the information to decide which is higher priority.

If these are the projects respectively:

• I have a new coffee table for the living room.
• We have a plan for the party.

Then knowing this will help you choose which is the higher priority action.



I've tried most of these too and agree with you.

Great example . . . A Four Areas of Focus would give instant/'timeless' Clarity/Priority. Thank you

 

[ianfh10]

Here is an example. Of these two next actions, which is the higher priority?

• Look up Alice's number and put it on my calls list.
• Look up Brian's number and put it on my calls list.

You can't tell from the actions alone. However, recognising the project can give you the information to decide which is higher priority.

If these are the projects respectively:

• I have a new coffee table for the living room.
• We have a plan for the party.

Then knowing this will help you choose which is the higher priority action.



I've tried most of these too and agree with you.

You're right that these actions don't have an inherent priority to them, but that's because they've not been clarified enough.

However, nothing about their associated projects tells me about the actions' priority either.

That's because those actions don't exist in a vacuum and wouldn't present themselves to a person in such an way. You've generated them somehow; they either came from the review of your projects list or they spawned a project.

If I had the same projects and actions, they'd be:

Get new coffee table
Plan party

And on my next actions list I'd have:

Get Alice's number to call about buying coffee table
Get Brian's number to call about party

Surely you'd instinctively know which related to which project? And also, in the moment, does it matter? If you call Brian and he agrees to DJ, you'll know where and why and when he'll be DJing regardless of whether that action is linked to your "party" project, whether by link, hashtag, action in two places, or other method. Just because GTD says you shouldn't think "of" something doesn't mean you're precluded from doing the thinking about it.

Edit: spelling and clarification

 

[ianfh10]

Please be specific, thank you. Better still, if you so please, refer simply refer to prior post. Thank you

Specifically, in your post:

On this end, the general knowing which Area of Focus of the Four Areas of Focus and what they mean to each other for Maintaining/Progressing Project(s)<>Next Action(s) with an intuitive sense of due dates and 'pressure relief' provides all 'grounding' necessary to make the best decision/priority without any 'deliberative wondering' sufficiently facilitates a calm sense of being for doing

What do you mean when you say what your areas of focus 'mean to each other'? Aren't areas of focus necessarily distinct?

What do the <> symbols mean in the phrase 'Maintaining/Progressing Project(s)<>Next Actions', and what do the italics signify in this statement?

I also don't understand the significance of the differently coloured letters of the word Focus in your post and whether I was supposed to grasp the post based on the meaning of those colours?

 

[cfoley]

You're right that these actions don't have an inherent priority to them, but that's because they've not been clarified enough. Plus, the projects don't tell me anything about the actions' priority either. Nor do the projects' names give me any information as to their own priority either.

Ah, right. I agree that the projects don't have an intrinsic priority since priorities change over time. But knowing the project, and therefore the overall desired outcome does help to make priority decisions in the moment. At least it helps me. To be clear, when I am saying priority, I am talking about the model for choosing actions in the moment: context, time, energy, priority.

Surely you'd instinctively know which related to which project? And also, in the moment, does it matter? If you call Brian and he agrees to DJ, you'll know where and why and when he'll be DJing regardless of whether that action is linked to your "party" project. Just because GTD says you shouldn't think "of" something doesn't mean you're precluded from doing the thinking about it.

Yes, I agree that making the link explicit is not the important thing.

 

[gtdstudente]

Specifically, in your post:

What do you mean when you say what your areas of focus 'mean to each other'? Aren't areas of focus necessarily distinct?

What do the <> symbols mean in the phrase 'Maintaining/Progressing Project(s)<>Next Actions', and what do the italics signify in this statement?

I also don't understand the significance of the differently coloured letters of the word Focus in your post and whether I was supposed to grasp the post based on the meaning of those colours?

CUT-&-PASTE from Previous Post:

on [page 185, 195, respective editions] was finally figured out through Areas of Focus via Weekly Review:

Until the next Weekly Review, like a compass: "I absolutely know right now everything I'm not doing but could be doing if I decided to."

1. DIVINE [East]

2. PERSONS/HEALTH (Unhealthy)[North] . . . includes GTD objectifying anything off/out of mind: Mind Sweeping, Natural Planning Model, Weekly Review, etc.

3. TOOLS/UTILITIES [South] . . . includes GTD objectified Next Actions [Calendar, Checklists 'Rehearsals/Doing', Contexts, Tickler, etc.], Projects to Horizons

4. FISCAL [West]

On this end, everything in life . . . including antagonists . . . fits in the above Four Areas of Focus

Arguably, the End of most Projects are either current Maintenance or Progressing something new for/into ones overall GTD 'Life-System'

"<>" . . . the dynamic reality relationship between Ends [Projects] and Means [Calendar, Next Actions, Reference(s), Support Material(s), etc.]

To keep things light for kicks and giggles, N,E,S,W coordinates are expressed as 'GTD feng shui'

 

[bishblaize]

Why does it matter whether it's obvious at a glance a next action is about a project or not?

This sounds facetious, but it's a genuine question.

You often need to know what project you're working on when you complete the action. If you ask a colleague to meet with you and they say "What about?" and you have no idea, that would be kind of silly. So how do you know? Essentially there are four options that come to mind.

1) You memorise it
2) You go back and scan through your project list until you find the Project that goes with the Next Action
3) You embed the information into the Next Action via its wording - e.g "Phone Bob to find time to meet RE signing off last year's audited accounts".
4) Your lists are structured digitally so whenever you see the Next Action you also see the Project

Of these four, the last one is the quickest and has the least memorisation and it's an intrinsic feature for most computerised GTD tools. It's also worth pointing out that this in isolation is somewhat useful, but hardly a game-changer, if it were literally the only benefit. However, there are other benefits, eg.

• At your Weekly Review you can look at a Project and see all the NAs associated with it without having to go hunting for them in your lists. (This is a huge time saver and is often cited as the reason people switch to a system of linked Project/NAs in the first place.)
• If a Project becomes suddenly urgent, you can find all the NAs quickly so that you can prioritise them, including changing Context if you need to.
• Makes it quick to check that key Projects always have another Next Action lined up instead of waiting for the weekly review.
• If you have links to your support material attached to your project, you can get from your NA to the support material in a click or two.
• It lets you make quick changes to all your existing next actions in a Project should you need to (eg if the result of one next action means you have to change your parallel actions)

And lots of minor variations on the same theme.

I also noticed at one point you said "I spent so much of my time trying tags, links, copying actions, duplicating actions, moving actions from project lists and back again, " While tags are indeed a feature of most computerised apps, if you are manually linking, copying or moving stuff between lists, then that might explain what the issue is. I don't do any of those things in the tools I use. Perhaps this is the issue, the tool you tried worked in a way that didn't suit and your expectation is that all tools work that way? I recognise that not all tools suit all people, but I think if you're avoiding all tools based on the experience of one then you might miss an opportunity.

 

[ianfh10]

You often need to know what project you're working on when you complete the action.

I actually don't find this to be the case.

If you ask a colleague to meet with you and they say "What about?" and you have no idea, that would be kind of silly.

You don't have an action that exists in a vacuum like this. I'd likely have agendas list for them anyway, or, I'm processing and reviewing often enough that you just know why you want to meet, the action has been generated somehow but you're talking as if I'd just come across "meet colleague" in my system and then decide to do it, which I wouldn't. Plus your action would be fully clarified and contain all the information required to do the action in the moment. By the logic of the example, if the action is is 'meet with Bob', knowing the project 'expand marketing department' actually gives you no more information on the action, either.

So how do you know? Essentially there are four options that come to mind.

1) You memorise it
2) You go back and scan through your project list until you find the Project that goes with the Next Action
3) You embed the information into the Next Action via its wording - e.g "Phone Bob to find time to meet RE signing off last year's audited accounts".
4) Your lists are structured digitally so whenever you see the Next Action you also see the Project

I'd actually say 3 would be the best practice because you've completed the thinking before acting on it. "phone bob" is not a fully clarified action, and it would repulse me regardless of what project it belongs to.

Of these four, the last one is the quickest and has the least memorisation and it's an intrinsic feature for most computerised GTD tools. It's also worth pointing out that this in isolation is somewhat useful, but hardly a game-changer, if it were literally the only benefit. However, there are other benefits, eg.

• At your Weekly Review you can look at a Project and see all the NAs associated with it without having to go hunting for them in your lists. (This is a huge time saver and is often cited as the reason people switch to a system of linked Project/NAs in the first place.)
• If a Project becomes suddenly urgent, you can find all the NAs quickly so that you can prioritise them, including changing Context if you need to.
• Makes it quick to check that key Projects always have another Next Action lined up instead of waiting for the weekly review.
• If you have links to your support material attached to your project, you can get from your NA to the support material in a click or two.
• It lets you make quick changes to all your existing next actions in a Project should you need to (eg if the result of one next action means you have to change your parallel actions)

And lots of minor variations on the same themes

I can't say there aren't benefits of having your actions dynamically available via both context and project, but my point is that there's no need to know which project they belong to in the first place.

I also noticed at one point you said "I spent so much of my time trying tags, links, copying actions, duplicating actions, moving actions from project lists and back again, " While tags are indeed a feature of most computerised apps, if you are manually linking, copying or moving stuff between lists, then that might explain what the issue is. I don't do any of those things in the tools I use. Perhaps this is the issue, the tool you tried worked in a way that didn't suit and your expectation is that all tools work that way? I recognise that not all tools suit all people, but I think if you're avoiding all tools based on the experience of one then you might miss an opportunity.

What I meant by this is that I tried using tool-specific features that didn't work for me, and taught me that the tool is not going to make my life easier, and that I can get very bogged down with tweaking and playing with a tool instead of doing work.

I don't any longer and I don't want to explore what a tool can do. Plus, a tool, especially a digital one, can break down, go obsolete, be unavailable. I can always fully clarify my thinking regardless of the tool.

I don't link NAs in any way to their project and it's made my life much easier; because in a way the project doesn't matter, it's just a placeholder for an outcome my next actions will move me toward. As long as my thinking is complete, I'm processing daily and doing a thorough weekly review, I have trust in the system.

 

[bishblaize]

I actually don't find this to be the case.


You don't have an action that exists in a vacuum like this. I'd likely have agendas list for them anyway, or, I'm processing and reviewing often enough that you just know why you want to meet, the action has been generated somehow but you're talking as if I'd just come across "meet colleague" in my system and then decide to do it, which I wouldn't. Plus your action would be fully clarified and contain all the information required to do the action in the moment. By the logic of the example, if the action is is 'meet with Bob', knowing the project 'expand marketing department' actually gives you no more information on the action, either.


I'd actually say 3 would be the best practice because you've completed the thinking before acting on it. "phone bob" is not a fully clarified action, and it would repulse me regardless of what project it belongs to.

I can't say there aren't benefits of having your actions dynamically available via both context and project, but my point is that there's no need to know which project they belong to in the first place.

What I meant by this is that I tried using tool-specific features that didn't work for me, and taught me that the tool is not going to make my life easier, and that I can get very bogged down with tweaking and playing with a tool instead of doing work.

I don't any longer and I don't want to explore what a tool can do. Plus, a tool, especially a digital one, can break down, go obsolete, be unavailable. I can always fully clarify my thinking regardless of the tool.

I don't link NAs in any way to their project and it's made my life much easier; because in a way the project doesn't matter, it's just a placeholder for an outcome my next actions will move me toward. As long as my thinking is complete, I'm processing daily and doing a thorough weekly review, I have trust in the system.

I can see the misunderstanding there. You seem to think I'm saying that there is some sort of literal data embedded in the Project title that would help you complete the Next Action. Occasionally there may be ( eg "Organise AGM for 1st July"), but mostly there isn't.

What I'm saying is that you routinely need to know what Project the Next Action will help to complete. If your project is "Complete Board report" and your Next Action is to begin a draft outline, you cannot do that without knowing that its an outline of a Board Report. Its not that the three words "Complete Board report" contains any factual data that will be contained in the report itself, but you absolutely have to know that its a Board Report when you start the draft.

Whether you do that with linked projects/actions like I do (see below), or you simply write "Draft outline of Board Report" and thereby incorporate the Project title into the Next Action, the principle is the same. You're helping remind yourself of the next step in your Project.



My points above were about the efficiency of how you remind yourself, not suggesting a different purpose.

 

[mcogilvie]

You often need to know what project you're working on when you complete the action. If you ask a colleague to meet with you and they say "What about?" and you have no idea, that would be kind of silly. So how do you know? Essentially there are four options that come to mind.

1) You memorise it
2) You go back and scan through your project list until you find the Project that goes with the Next Action
3) You embed the information into the Next Action via its wording - e.g "Phone Bob to find time to meet RE signing off last year's audited accounts".
4) Your lists are structured digitally so whenever you see the Next Action you also see the Project

Of these four, the last one is the quickest and has the least memorisation and it's an intrinsic feature for most computerised GTD tools. It's also worth pointing out that this in isolation is somewhat useful, but hardly a game-changer, if it were literally the only benefit.

I have found, to my real surprise, that 3) is consistently faster than 4). This is true for Collection, Organization and Processing, which I think you are discounting, and for Doing as well. I don’t really care to rehash all the mistakes I’ve made while ignoring David Allen’s clear, straightforward advice. I understand that many people find value in practices (and software) I have ultimately discarded. We’re all different, and our practices change with time.

 

[ianfh10]

I can see the misunderstanding there. You seem to think I'm saying that there is some sort of literal data embedded in the Project title that would help you complete the Next Action. Occasionally there may be ( eg "Organise AGM for 1st July"), but mostly there isn't.

What I'm saying is that you routinely need to know what Project the Next Action will help to complete. If your project is "Complete Board report" and your Next Action is to begin a draft outline, you cannot do that without knowing that its an outline of a Board Report. Its not that the three words "Complete Board report" contains any factual data that will be contained in the report itself, but you absolutely have to know that its a Board Report when you start the draft.

Whether you do that with linked projects/actions like I do (see below), or you simply write "Draft outline of Board Report" and thereby incorporate the Project title into the Next Action, the principle is the same. You're helping remind yourself of the next step in your Project.

View attachment 1407

My points above were about the efficiency of how you remind yourself, not suggesting a different purpose.

I understood your point, but I'm actually making the opposite one, that you don't need to know the project, and I'd advise people that often ask how to manage 'linking' actions to their project (and it does come up on this forum quite frequently) to just not do it.

OP stated they currently used a paper system, so your option shown above (option 4 in your previous list) is not a possibility to them, but clarifying the action always will be. I think 'draft outline' is not a fully clarified action, and this wouldn't be useful for anyone sitting down to execute next actions whether on paper or digitally, and of course you'd need some context for this.

How would you manage this NA if it was a single, project-less action? You would still have to go somewhere for some context/further information to help you complete the action. 'Draft outline for board report' is clarified enough that's it's self contained and could be completed by anyone (relatively speaking) without any prior knowledge of the context, like a colleague on your team, for example. I'd say this is not the same as knowing the project it's related to, but a fundamental behaviour of GTD that applies to all actions.

'Buy vegetables for meal' is a useless action whether I know it's for a 20 person family celebration project or a two-person anniversary meal (or whether I don't know it's linked to either project.

'buy onions, peppers and garlic for Thursday's anniversary meal' is fully thought out and clarified, and it still doesn't matter whether I know what project the action relates to. In fact, the action is so clear that it's removed any ambiguity whatsoever about what project it relates to.