When do you put the next action of a project in your next action list ?

[dienkwik]

Hi, all:

When do you put the next "action" of a project in your next action list ?
Do you do it right after you complete the previous next action ? Or do you wait until you review your projects ?

I'm curious how others are handling this.

Thanks,

Dien.

 

[Gardener]

It depends.

A project with no next action is a situation that should be corrected, so I wouldn't make a point of waiting, as in, "Oh, that needs a next action--no, wait for the weekly review!"

On the other hand, correcting that situation is not the top priority either, so also don't make a high-priority point of ensuring that every project always, always has a next action.

If I'm working on that project, then the last action before I go on to work on something else would generally be to add a next action.

If I'm working in a context--for example, making a number of calls or sending a number of emails--I probably won't bother to go create new actions as I check off each call and each email, and therefore those projects will probably have no actions when I'm done. (OmniFocus does support an unlimited list of next actions per project, but I try to avoid doing that these days.)

I tend to have a fair number of, "My brain is tired. What's something easy I can do?" moments, and during those moments I may do a sweep of projects and give a next action to the ones that lack them. If this didn't happen without my making a point of it, I'd probably make a point of it and plan on two or three sweeps per week.

 

[Folke]

I agree with both Gardener and jenkins. I am also quite relaxed about next action. I quite often speed review a project if I have done something about it, and even if I do not it is usually cool because I often have several next actions in them - and I'll probably look at it quite soon; I definitely would not wait until the weekly review.

I also agree with this:

I was under the impression that if a project has more than one next action (i.e., actions that can truly be completed independently of one another), both can go on your next actions lists.

Definitely - but lots of people wrongly claim that there can only be one next action. David Allen however expresses it very clearly in his first book (paraphrased from memory): "you must identify every next action in every moving part of every project". There can be no question.

 

[Gardener]

Definitely - but lots of people wrongly claim that there can only be one next action. David Allen however expresses it very clearly in his first book (paraphrased from memory): "you must identify every next action in every moving part of every project". There can be no question.

My translation of that instruction is based on my definitions. To me, if a project has another "moving part", that's another project. So I may:

- Create another project for that part and give it a Next Action.
- Create a Someday/Maybe project for that part.
or
- Ignore that part and treat it as a sort of invisible Someday/Maybe.

So the project Create World's Best Tailored Jacket may have three current projects:

- Fit jacket pattern
- Obtain and prep jacket materials
- Re-learn how to padstitch

and six others that are hanging out in Someday/Maybe.

That ignores the question of multiple parallel actions for a project. "Obtain and prep jacket materials" could include tasks related to fabric, buttons, thread, canvas, etc, etc. The distinction between parallel next actions, and multiple moving parts, is a fuzzy one.

I generally make a conscious choice to have exactly one Next Action for a project, and to treat any lists of other actions as project support material. But I agree that confining myself to one action is not required, it's just my preference

 

[dienkwik]

Thanks all for the inputs

I myself am doing it the same way we are all describing it here.
However, doing it this way feels like I'm choosing to advance all my projects in parallel, but slowly, i,e. I don't get to the outcome sooner.

Sometimes I feel like I should prioritize the projects and clear out several next actions of some projects in succession to get to the outcome sooner, and let other lower priority projects be delayed.
With only one next action in my next action list for a project, though, once I have completed that action, I would scan my next action lists and pick another one, which is surely from a different project.

I was tempted to set my own rule of getting the next action set for a project right after I checkoff the previous one. This way, I have all projects' next action under consideration when deciding what to do next. I just never succeeded in really doing it consistently

 

[Gardener]

I'm not sure I'd say I make that a conscious choice -- I can't help the truth that taking my vacation can be moved forward with two independent actions. I would say that I don't make a conscious effort to unearth parallel next actions. I'm usually content to have just one (and perhaps a mind-map or outline for support material, depending on the scope of the project). And if in the middle of the night, I remember "Ah! I can't forget to find a moving company re Project #1," I might just tuck that away as project support material, rather than mining that thought for next actions. However, when I review Project #1's support material, I don't think I'd make a conscious choice to not throw "Research moving companies" onto my At Computer list.

Yep, and there's certainly nothing wrong with that. I've just learned that for me, every time I make my project and action lists simpler and shorter, my use of the system gets better. I can have an infinite amount of complexity in my project support materials, but my project/action lists need to be simple.

I also don't have sub-projects, because those are, again, an added complexity. I know in my mind that those two or three or seven projects are all toward the same higher-level goal, but they're not listed in any way that indicates that fact. If there were any risk of my forgetting what they're about, I'd put that in the name.

 

[Folke]

I myself am doing it the same way we are all describing it here.However, doing it this way feels like I'm choosing to advance all my projects in parallel, but slowly, i,e. I don't get to the outcome sooner.

Sometimes I feel like I should prioritize the projects and clear out several next actions of some projects in succession to get to the outcome sooner, and let other lower priority projects be delayed.

Nothing wrong with that. You do not need to be working off the next actions list(s). If you want to work on a particular project you can work straight off that project's list (wherever you keep it; I keep it all in the same app).

With only one next action in my next action list for a project, though, once I have completed that action, I would scan my next action lists and pick another one, which is surely from a different project.

I was tempted to set my own rule of getting the next action set for a project right after I checkoff the previous one. This way, I have all projects' next action under consideration when deciding what to do next. I just never succeeded in really doing it consistently

I think it is a good habit to "speed review" projects every so often and make sure you have all the next actions (that you want) listed as next actions. But no stress ... and it can obviously be more essential for some projects than for others.

I also don't have sub-projects, because those are, again, an added complexity.

This is a common objection. I can definitely live without sub-projects, and do not even have a sub-projects feature in the app I am currently using, but I honestly see sub-projects (unlimited hierarchies) not as a complexity but as a simplification. Yes, I really do. If I intuitively feel that something is part of something bigger, i.e. "under" something, it is so much simpler for me if I can just put it like that without any trouble or rather than have invent workarounds (complications) for being able to see them together in a structured way.

I think it is interesting that we humans can think so differently on what is simple and what is complex. But I am sure we would all agree that a car with just two wheels would actually be more "complicated" than a car with four wheels. Even though it is simpler in one sense to have fewer wheels, it also makes driving it and keeping it balanced a more complicated affair. And no wheels would be even more complicated - and simple - than two.

 

[Gardener]

it is so much simpler for me if I can just put it like that without any trouble or rather than have invent workarounds (complications) for being able to see them together in a structured way.

I think it is interesting that we humans can think so differently on what is simple and what is complex. But I am sure we would all agree that a car with just two wheels would actually be more "complicated" than a car with four wheels. Even though it is simpler in one sense to have fewer wheels, it also makes driving it and keeping it balanced a more complicated affair. And no wheels would be even more complicated - and simple - than two.

Well, I rarely need the workaround of the related name--I usually know what goal(s) the project is related to.

And it is "goal(s)"--there's often more than one goal, and the various goals and projects are more of a network or spiderweb than a hierarchy. For me to try to somehow indicate those relationships would be more complicated than just letting all projects sit at the same level. So it's not that I shy away from the complexity of the hierarchy because it's complex. I shy away from it because it's far less complex than the actual relationships, so its complexity is not actually depicting anything useful.

For example, when I plant sunflowers next year, my choice of sunflowers will feed into a breeding project, a dryfarming experiment, and the simpler goals of a prettier garden and having cut flowers. The project "Choose and buy sunflower seeds for 2016" could be seen as a subproject of four projects. If it's instead, "Choose and buy flower seeds for 2016", that supports even more projects. Placing it hierarchically under just one of those projects is more complicated than just leaving it at the same level as everything else.

 

[Folke]

So it's not that I shy away from the complexity of the hierarchy because it's complex. I shy away from it because it's far less complex than the actual relationships, so its complexity is not actually depicting anything useful.

For example, when I plant sunflowers next year, my choice of sunflowers will feed into a breeding project, a dryfarming experiment, and the simpler goals of a prettier garden and having cut flowers. The project "Choose and buy sunflower seeds for 2016" could be seen as a subproject of four projects. If it's instead, "Choose and buy flower seeds for 2016", that supports even more projects. Placing it hierarchically under just one of those projects is more complicated than just leaving it at the same level as everything else.

Haha. I know what you mean. I have actually suggested (even in this forum) that apps should allow users to let actions and projects be part of more than one parent project (parent entity), and I usually get totally mocked and scorned whenever I suggest that. I can live without it, but it would be neat.

I think that you would find that a surprising number of such cases can in fact be mapped into a regular hierarchy, but it takes a bit of definition work - to define what should go into each parent entity - and it also requires you to be prepared to assign it to just ONE and therefore have clear principles for that. Example: Let's say the parent level represents areas of responsibility, and you have an action or project to get a new TV set, and that the TV can and will be used for a wide range of purposes. It is with areas just as it is with people in a company, you need to have a rule for which ONE person (area) will get the job of buying the TV set (even though everyone will use it, and for lots of purposes).

In a way it is similar to the problem with contexts. If you use paper or a paper-emulating app you can have only one context for each task. Very clumsy, limiting etc (and most apps have a better way), but it can be worked around. I even use this single-context system myself (a bit unwillingly, but still). The solution (for me) is to have a ranking or "priority" of contexts - e.g. if an action requires me to be @Out with some special @Person, and since I cannot apply both, and since I refuse to create combo contexts such as Out with a Person, what I do is I have decided (permanently) that Person is a more restrictive contextual requirement than Out, so I mark it with Person only, and deal with the secondary contexts with the gut.

You can do similarly in a project hierarchy. (I do). You could perhaps decide that anything that relates to purchasing or planning for the garden goes in the Garden Manager bin. No?

 

[Oogiem]

When do you put the next "action" of a project in your next action list ?
Do you do it right after you complete the previous next action ? Or do you wait until you review your projects ?

For me most of the time when I define a project and create it I plan out and put in most of the next actions at once so it's done automatically for me in Omnifocus. Only very rarely will a given project plan actually change from when I first do it if I did the planning model correctly and properly the first time.

While it's true that you can put all available next actions on your lists for me, I'm with Gardener. If I have something that can be done in parallel it is nearly always a second project not a sub project. I don't like sub projects at all and do not do well with them. I function much better with a long list of discrete projects. Subprojects are complicating and lead to indecision.

So to give my take on the examples Jenkins posted I'd put all of those into separate projects. The goal is move to a new office, the projects include Planning the new office buildout and Packing for the office move. The Goal is take a nice vacation. Projects include Pack for trip to Florida and Decide on itinerary for trip to Florida.

I also can choose to focus on a single project and work through a bunch of next actions at once. I typically do that when I am staying in the same context for those actions. It makes no sense to jump to a new context and back and forth just to keep working on a project. So for example, I have a project that is clean-up the evaluate sheep module in LambTracker. I have about 8 Actions ranging from fix the update database button so it's disabled until you've got a sheep selected to edit screen layout to put more white space to the left of the star rating group. I will probably stay in that project doing as many of those actions as I can once I am in there because it's faster. However, a project like Endure shop is fully stocked before the weekend has the following next actions, Skein off sock yarn with a context of Shop Building, Get more brats from lockers, with a context of in town, and Put price tags on new yarns with a context of Little House. If I try to stay in that project I'll be running over to the shop, then down to town then over to the little house and it's inefficient. That is the beauty of contexts, stay in one as long as you can before changing and you'll end up getting much more done on your projects.

That does require that you spend more than a little time doing the project planning. Only if your projects are well thought out does this work.

 

[Gardener]

You can do similarly in a project hierarchy. (I do). You could perhaps decide that anything that relates to purchasing or planning for the garden goes in the Garden Manager bin. No?

Yes, but the Garden Manager has a bunch of projects, so I would still have projects and sub-projects-that-I-choose-not-to-treat-as-sub-projects.

I agree that if there were value in a hierarchical structure, there are a number of ways to achieve/record/display that structure. But it has no value for me. It's work that I don't see as having any payoff.

If I try to see a scenario where anything in this realm has value, I'd say that it could in theory be useful to have a tagging capability. I wouldn't use that to create a hierarchy, but I might use it for searches.

For example, if I decide that I've been short-changing my writing goals, I could search all of my projects for the tag "Supports Writing", and choose my tasks from the results. That way, if it's a beautiful day and I want to be out in the garden instead of writing, I could search for tasks with a Garden context that also Support Writing. (Maybe, for example, I'll buy and plant tomato plants, and photograph the process for a blog post on planting dryfarm tomatoes.)

People have been clamoring for years for a tagging capability in OmniFocus, and while I've never cared much, I agree that it would be nice. I haven't followed the latest major upgrade, so I don't know if it has it or not.

 

[Folke]

I agree that if there were value in a hierarchical structure, there are a number of ways to achieve/record/display that structure. But it has no value for me. It's work that I don't see as having any payoff.

For me it has a value to be able to review the stuff goal by goal, area by area etc. And with most apps I have used it does not take a whole lot of work to arrange the stuff in such a manner, either by using tags etc (perhaps called labels, contexts etc) or overarching "containers" (perhaps called folders, lists, goals, project hierarchy etc), or simply by prefixing projects systematically and being able to search for these prefixes or sort them alphabetically or manually.

There are lots of ways, and usually they are not a lot of work, so for me it is worth the extra couple of seconds every time I create new project, as it enables me to review my stuff in a safer and more relaxed way that also appears very natural and intuitive for me.