bcmyers2112;112377 said:
If I might be so bold, if you've run into trouble entering next actions that weren't truly actionable the problem may actually be inadequate project planning. Clarifying the purpose, vision, and principles for a project can sometimes help determine what's truly needed to drive a project forward and what's not.
I'm sure that there are some projects that march along according to plan, but I think that most projects are going to have built-in areas of uncertainty, and also unexpected hiccups, no matter how well-planned. If you extract many areas of uncertainty into the project planning, they're still areas of uncertainty, and they still have to be worked with actions.
For example, your programming project depends on being able to buy a particular piece of software functionality. You are familiar with an appropriate piece of software, so you merrily write actions. ("Determine needed number of MagicWidet seats." "Submit purchase paperwork for MagicWidget." "Install MagicWidget." "Write blah using MagicWidget." "Write blah2...") Then you find out that MagicWidget, Inc., has abruptly declared bankruptcy, and you have to start a software selection process and decide whether you can support the needed functionality at all. Suddenly, that list of actions is no good.
Or the lead carpenter on the house that you're building quits.
Or the bride for the wedding you've already set the menu for is suddenly diagnosed with an allergy to shrimp.
Or a spell of hot spring weather kills all the peas in your demonstration garden, and you were going to use themn as the primary visual aid for your talk on Mendelian genetics.
Things change, no matter how well you plan. Your purpose, vision, and principles can help guide you on what to do next ("Is it better to use photos of peas, or make my point in the garden with various kinds of cabbage instead?"), but they can't guarantee that you can keep marching down your original path.
bcmyers2112;112377 said:
Simply deciding on an absolute rule of only one next action per project
But that's not what I said. I expressed opposition to "long, detailed sequence of actions" and said that "Sometimes" a logical project size is a size where the project has only one logical action. I didn't suggest any absolute rules.
bcmyers2112;112377 said:
may be as hampering as entering next actions that aren't truly necessary. I frequently have projects where there are multiple things that are actionable now because they're not dependent on each other. If I were to only enter one next action at a time for projects like that I wouldn't progress on them quickly enough.
That's where I would break the project up into multiple projcts. This is in part, again, because I use OmniFocus, and OmniFocus offers a number of useful per-project behaviors. It keeps track of how recently you've reviewed a project, and lets you identify stalled projects (projects with no actionable action), and so on. If a single project has several threads of activity, I can't use those behaviors for those threads unless I break them up into their own projects.
Let's say that I want to make a jacket out of felted/"boiled" wool. As I start that project, I could work at least three threads of activity at once:
- Finding and fitting a pattern suitable for the thick but moldable texture of boiled wool.
- Mastering sewing techniques appropriate for those thick fabrics.
- Finding the right wool for the final jacket.
I could work all three of these in a single project, but if I do then it's less likely that, for example, OmniFocus would remind me that the "finding the right wool" project is stalled because I'm waiting for a call back. I would have to remember to keep all three threads going, and I want GTD to do the job of remembering those things.