Next action problem

[AGrzes]

I gave some problems on deciding what should I put on my lists next action.

First, many things that I do require many small steps that fit definition of next action. Buy if I only put first step on my list It may be hard to remember what is ultimate goal of this from glance. Moreover often it only makes sense to do a few steps at one sitting.

Second, other things that I do can be approached from different side. So if I put first step of some approach on my list and get back to it next week I do not remember what was my approach to problem, I do not know why should I be doing this action and I would choose another approach to problem that time.

I handle this issues by putting those "things" that are not really next actions on my lists but it causes another problem, that if I'm not at my full energy I tend to concentrate on smaller actions leaving bigger things not done.

I just thought of one potential solution, to keep smaller actions and bigger things on separate lists, so I would know that I should look at big first (If I have time and energy) before considering small and other way round only look at small actions If i have only 5 minutes to fill.

What do you recommend?
Have you faced similar problems?

[Oogiem]

First, many things that I do require many small steps that fit definition of next action. Buy if I only put first step on my list It may be hard to remember what is ultimate goal of this from glance. Moreover often it only makes sense to do a few steps at one sitting.

Second, other things that I do can be approached from different side. So if I put first step of some approach on my list and get back to it next week I do not remember what was my approach to problem, I do not know why should I be doing this action and I would choose another approach to problem that time.

...

What do you recommend?
Have you faced similar problems?

Spend more time on the project planning before you put the smallest action on your list so that you understand the purpose and maybe have an outlined approach. Save those notes in project support. Have the project support folder or files handy when you are working in case you need a reminder.

[AGrzes]

Spend more time on the project planning before you put the smallest action on your list so that you understand the purpose and maybe have an outlined approach. Save those notes in project support. Have the project support folder or files handy when you are working in case you need a reminder.

I find few problems in this approach.

First I think the main benefit of maintaining a list of nearest next physical action by context is that If you are in that context you can pick it up and do it straight away. The way you described one could put "Work on project XYZ (details in project support materials)" and have the same situation.

Second, If there are multiple approaches at problem the one devised in the past may not feel right when finally getting to work at it. And if it does not feel right it is hard to expect to follow it with great energy.

Third, In many cases thinking about how to do the task is most of the work, so when I would have time for detailed planning I could do the task right away.

[TesTeq]

If there are multiple approaches at problem the one devised in the past may not feel right when finally getting to work at it.

Could you please give an example? My projects seem to be very simple - the only problem I encounter is the lack of clarity of the outcome - it really hurts the execution performance.

[AGrzes]

Could you please give an example? My projects seem to be very simple - the only problem I encounter is the lack of clarity of the outcome - it really hurts the execution performance.

A sample project that I had problem with multiple possible approaches was preparing RPG session for my gaming group.

Other example of something complicated may be diagnosing problems with processing inbound synchronization message on the client system. It involved many steps like

• Analyzing the source code of receiving module
• Analyzing server logs
• Analyzing received communicates
• Retrieving half proceed communicates from database
• Decoding half proceed communicates
• Retrieving half proceed communicates from database once again because they was truncated
• Writing code to simulate processing flow
• ...

All in the same day

[mcogilvie]

I find few problems in this approach.

First I think the main benefit of maintaining a list of nearest next physical action by context is that If you are in that context you can pick it up and do it straight away. The way you described one could put "Work on project XYZ (details in project support materials)" and have the same situation.

Second, If there are multiple approaches at problem the one devised in the past may not feel right when finally getting to work at it. And if it does not feel right it is hard to expect to follow it with great energy.

Third, In many cases thinking about how to do the task is most of the work, so when I would have time for detailed planning I could do the task right away.

First objection: Try something like "Do concrete next action on Project XYZ." If you want to keep going on Project XYZ, do so. When you stop work on XYZ, determine a next action for it. A next action is like a book mark: It tells you where and how to start working on the project again.

Second: Your hypothetical next action is then not something you are committed to doing. Your next action is then to find the real next action. Or just do whatever feels right and move on from there.

Third: I'm not sure what you mean here. GTD does not particularly embrace detailed project planning. All you need for a project is a desired outcome and at least one next action. That's it. If you need more planning, that's a next action. If you don't need more planning, don't do it.

[mcogilvie]

Other example of something complicated may be diagnosing problems with processing inbound synchronization message on the client system. It involved many steps like

• Analyzing the source code of receiving module
• Analyzing server logs
• Analyzing received communicates
• Retrieving half proceed communicates from database
• Decoding half proceed communicates
• Retrieving half proceed communicates from database once again because they was truncated
• Writing code to simulate processing flow
• ...

All in the same day

Those are not project planning steps. In debugging, you may at any time stumble upon the answer you are looking for, and not need to proceed further in your diagnosis. What you have given are the results of brainstorming steps to determine the problem. This is classic project support material. Same with determining your approach to your RPG.

[AGrzes]

First objection: Try something like "Do concrete next action on Project XYZ." If you want to keep going on Project XYZ, do so. When you stop work on XYZ, determine a next action for it. A next action is like a book mark: It tells you where and how to start working on the project again.

I think it is good of thinking next action as a bookmark.
I have digital system where each action is linked to the project so I do not have to put the relation in name for action. But I think my objection still hold:
What is the point of identifying next action in advance when you will nevertheless have to spend consulting project materials when you pick it up and you may come up with better fresh next action?

Second: Your hypothetical next action is then not something you are committed to doing. Your next action is then to find the real next action. Or just do whatever feels right and move on from there.

Yes but that action often tends to lay on my list at least until next weekly review and in the meantime nothing gets done on that particular project. Maybe this is a different problem.

Third: This was response to suggestion to spend more time planning.

Those are not project planning steps. In debugging, you may at any time stumble upon the answer you are looking for, and not need to proceed further in your diagnosis. What you have given are the results of brainstorming steps to determine the problem. This is classic project support material. Same with determining your approach to your RPG.

This was a list of actions I have taken. I didn't put it in anywhere in writing (before this post) because I was doing it one step after another. But now I think it was not a good example.

Going back to RPG my problem was that I did not have much time to work on it so often I had put action to elaborate on some element then ran out of time, worked on something else and in the end improvised that element or omitted it entirely.
Summing up my action was chosen thinking I will put for example 6 hours in preparation but when I finally get only 2 it was not adequate.
--

And one new question.
How to handle actions with different size?
I find that some activities only make sense If I put at least 30 minutes - one hour in them, and they tend to be starved by actions that can be done in 5 minutes that are also on my list. And I find that often bigger actions provide more value but they are omitted because they are not that easy to cross out.