Managing/tracking projects and multiple next steps

[wjrosie]

Hi,

I'm just starting to use GTD with outlook and am wondering how to tasks of projects where multiple next steps are known. In reading GTD and other summaries, the guidance given is to identify and record the next tangible action as a task. In most cases, people know multiple tasks, often independent, that need to occur--but not necessarily all of them. Is the best practice to log multiple tasks/next actions, if known or is there another suggestion?

Also, when creating a project, I have been summarizing the desired outcome and some key actions i'll need to take as a reminder but creating discreet actionable tasks for the items i know of.

Any guidance on this approach or something that works for you?

Thanks,
Bill

 

[Folke]

Yes, list all the next actions that are now possible for you to do in the project. At least one next action.

If you have additional actions that are not possible yet, but which will become possible (next actions) after some of the other actions have been completed, then in most apps you need to use some workaround. In "paper GTD" these future tasks are considered to belong in the "project support material" (i.e. along with all your budgets, brochures etc) outsode of your regular GTD lists. But if you have a task app you probably want them listed in the app straight away, but "invisible" in your Next lists etc, only visible withing the project itself. Many (most) apps have no support for this, so you'll have to find a workaround to prevent them from cluttering your Next list(s), Waiting For list etc.

 

[GMX]

Outlook + OneNote

If you also have OneNote along with Outlook, then this is an easy problem to solve.

Recommended reading: GTD with Outlook 2010 and OneNote 2010 | A Blog by Michael Wheatfill on Microsoft Technologies and Productivity

 

[Gardener]

I've started to turn against entering multiple actions for a project. I've repeatedly found myself with tangles of actions that were no longer relevant, and several projects whose next actions were, "Clean up actions for this project." So my view now is that a long, detailed sequence of actions should be treated as project support material, rather than being entered directly into your GTD system. I leave them out, even though OmniFocus, my tool of choice, supports as many actions as I want to enter for a project.

There's also the possibility that your projects are too large. I find that I'm making my projects smaller, and smaller, and smaller, and I have yet to find that they're too small. Sometimes the logical size for a project, at least for me, *is* the point where there is only one next action for that outcome.

For example, let's say that I want to have a really big Christmas party. The project could be:

Project: Throw whiz-bang Christmas party

That project would have all sorts of parallel tasks, related to the food, the decorations, the guests, the music, the venue or the cleaning if the venue is at home, the parking, how to make sure that Auntie Rose can get there. So to me, it's not a project, it's a group of projects or perhaps a short-term Area of Focus. It might be a couple of dozen projects that sprout into existence, get done, and vanish, such as:

Project: Gain agreement on guest list.
Project: Get whiz-bang invitations designed and sent.
Project: Select baker for whiz-bang Christmas cake.
Project: Get guests with mobility issues to and from the party.

 

[Folke]

So my view now is that a long, detailed sequence of actions should be treated as project support material, rather than being entered directly into your GTD system.

Well, you are perfectly right that all the subsequent actions (not actionable yet) in fact are classified as project support material in GTD. But even the project support material is part of your total GTD system.

In principle, your subsequent tasks can be in a shambles wherever you keep them, and so can your now current next and waiting for actions, or any other part of your total GTD system. for that matter. Reviewing is key.

The question is only which app or filing cabinet or notebook etc you use for which part of your total GTD system, and this will depend on the characteristics and capabilities of each such tool. The various conceptual GTD buckets do not necessarily have a 1-1 relationship with the physical tools such as filing cabinets or apps.

You are right that it is necessary to be able to see the difference between the subsequent actions and the now current actions. But whether that is done in one app, or across two apps or fifteen different apps and different manila folders in different cabinets is a separate issue.

I agree that most GTD apps have very limited functionality out-of-the-box for dealing with subsequent project actions. It can usually be done, one way or another, but it usually takes a few workarounds to both keep these tasks or projects in the app and at the same time keep them invisible expect when you want to look at them (review them, move them into an active state etc). But I have always been able to find reasonable enough workarounds for that - not elegant, but workable. (I don't know about Omnifocus.)

 

[bcmyers2112]

You are right that it is necessary to be able to see the difference between the subsequent actions and the now current actions. But whether that is done in one app, or across two apps or fifteen different apps and different manila folders in different cabinets is a separate issue.

Folke shoots, he scores. As I said in another thread, we're talking about matters of personal preference. This is one of the reasons I find GTD to be a great fit -- it allows lots of room for individual preferences. I am sure my GTD system bears little resemblance to yours -- and that's a good thing. There are as many ways to do GTD as there are people.

My preference is to keep future actions in support material, usually in the body of the Evernote note for a particular project. That works well enough for me.

If I were using a dedicated GTD app and I wanted to keep future actions the way you do, I suppose I could create a context for them or enter them without a context so they wouldn't be visible in my next actions lists.

Some people use mindmaps and create tasks that they move to their next actions lists as needed.

Lots of ways to do it. The key is to pick one you're comfortable enough with.

 

[bcmyers2112]

I've started to turn against entering multiple actions for a project. I've repeatedly found myself with tangles of actions that were no longer relevant, and several projects whose next actions were, "Clean up actions for this project."

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.

Simply deciding on an absolute rule of only one next action per project 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.

So my view now is that a long, detailed sequence of actions should be treated as project support material, rather than being entered directly into your GTD system. I leave them out, even though OmniFocus, my tool of choice, supports as many actions as I want to enter for a project.

If the actions are truly sequential, i.e. you can't do the second until the first is done, and so on, then I agree: the future actions belong in project support. But I think it's worth nothing that project support, reference materials, tickler files, etc. are all part of one's "GTD system." A GTD system isn't merely about next action lists. It's an ecosystem that encompasses anything you need to be productive.

 

[bcmyers2112]

In most cases, people know multiple tasks, often independent, that need to occur--but not necessarily all of them. Is the best practice to log multiple tasks/next actions, if known or is there another suggestion?

Hi, Bill. I'm also a Bill. It's a rather big club. Lots of us.

If there are multiple things you can do for a project because they're not dependent on each other then yes it is considered a GTD best practice to enter them all into your next actions lists. If there are future tasks you can't do yet but don't want to forget, those go in project support. As you can see from this thread there are lots of was to manage project support.

Don't be afraid to experiment and find what works for you. You may discover that one of our suggestions hits paydirt, or that none of our suggestions work for you. In the latter case, you may come up with a method on your own that works wonders for you. In that case, please be sure to come back and share that with us!

 

[Gardener]

Well, you are perfectly right that all the subsequent actions (not actionable yet) in fact are classified as project support material in GTD. But even the project support material is part of your total GTD system.

It is, but it's a part separate from the actionable lists, and thus handled differently. It sounded to me as if people were suggesting that these actions be placed in the actionable lists--which in OmniFocus is very easy, and that's why it's easy to get into trouble with them.

In fact, I don't think of something as an "action" unless it is in the actionable lists. If it's elsewhere, it's a thought, or a plan, or a don't-forget, not an action. That may just be my terminology.

In OmniFocus I can list any number of actions for a project, and choose their order. If the project is set as Sequential, then the topmost action will be "available" and show in perspectives designed to show available actions. When I check it off, the next one will show up--with no further action on my part. And so on, for however many actions I enter.

But that "no further action on my part" means that if the project doesn't progress as planned, then the actions that pop up will be non-actionable. To keep that from happening between reviews, I have to manicure those actions during reviews, evaluating their order, whether they're still going to be actionable when they're reached, and so on.

In principle, your subsequent tasks can be in a shambles wherever you keep them, and so can your now current next and waiting for actions, or any other part of your total GTD system. for that matter. Reviewing is key.

Yes, but the review of my project support material is very different from the review of my actionable lists. The support material can be more theoretical, less actionable, go down If/Then branches. The actionable lists should be actionable, and should be in the correct order.

So when I have a bunch of tasks in the actionable lists, I generally find myself manicuring them during reviews, and in spite of that, I usually find myself inserting the next task above them. So all that work accomplishes nothing.

The question is only which app or filing cabinet or notebook etc you use for which part of your total GTD system, and this will depend on the characteristics and capabilities of each such tool. The various conceptual GTD buckets do not necessarily have a 1-1 relationship with the physical tools such as filing cabinets or apps.

You are right that it is necessary to be able to see the difference between the subsequent actions and the now current actions. But whether that is done in one app, or across two apps or fifteen different apps and different manila folders in different cabinets is a separate issue.

Yes, and you and I may not actually be doing anything different. If you have your actionable lists, and then separately you have material from which you choose your next action when you are ready for it, and you don't necessarily chose the very topmost item in that material, and you don't laboriously sort that material during your review to make sure that the topmist item is going to be the right one, then we're doing the same thing.

I agree that most GTD apps have very limited functionality out-of-the-box for dealing with subsequent project actions. It can usually be done, one way or another, but it usually takes a few workarounds to both keep these tasks or projects in the app and at the same time keep them invisible expect when you want to look at them (review them, move them into an active state etc). But I have always been able to find reasonable enough workarounds for that - not elegant, but workable. (I don't know about Omnifocus.)

OmniFocus doesn't require a workaround--it does it easily and gracefully, and that is where I get into trouble.

 

[Gardener]

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.

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.

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.

 

[Folke]

Yes, and you and I may not actually be doing anything different.
...
OmniFocus doesn't require a workaround--it does it easily and gracefully, and that is where I get into trouble.

Indeed, we seem to take a similar view on these things.

And I agree with you about that horrible "sequential" project feature that apparently Omnifocus has, and which Nirvana has, too, and which I played with briefly while I used Nirvana. Sure, I has its initial toyish charm, but is absolutely useless. First of all, my projects seldom have just one next action, so for that reason alone I could not use it, and had to resort to a manual workaround.

Also I agree with you that the further down the list of subsequent tasks you go the more tentative the tasks tend to be, and more and more in need of rephrasing and restructuring later on.

Doing it manually is not bad at all. I have no problem with that, and that is what I do. It irritates me, though, that none of the apps I have seen has a simple manual solution built in, for example a divider line within the project between current and subsequent. Either they have nothing at all or they have that rigid and silly parallel-sequential thing. (Zendone is better in that regard, but I cannot use it for certain other reasons.)

Workarounds I have used are, for example: Nirvana had an additional non-GTD category called Later, which I had no other use for, so I put my subsequent tasks down as Later. Doit has a good visual Priority feature which has a No Priority value which I have no other use for, so I now use No Priority to represent subsequent tasks.

 

[Gardener]

Indeed, we seem to take a similar view on these things.

And I agree with you about that horrible "sequential" project feature that apparently Omnifocus has, and which Nirvana has, too, and which I played with briefly while I used Nirvana. Sure, I has its initial toyish charm, but is absolutely useless. First of all, my projects seldom have just one next action, so for that reason alone I could not use it, and had to resort to a manual workaround.

Just FYI, in OmniFocus you can turn off "sequential", either per project or as a default for new projects, and then all of your actions for a project are "available." (Well, unless you put them on hold or give them a future start date.) So don't let that, alone, put you off OmniFocus.

I figure that the sequential setting is useful for projects that are predictable; I just don't have many of those.

Also I agree with you that the further down the list of subsequent tasks you go the more tentative the tasks tend to be, and more and more in need of rephrasing and restructuring later on.

Doing it manually is not bad at all. I have no problem with that, and that is what I do. It irritates me, though, that none of the apps I have seen has a simple manual solution built in, for example a divider line within the project between current and subsequent. Either they have nothing at all or they have that rigid and silly parallel-sequential thing. (Zendone is better in that regard, but I cannot use it for certain other reasons.)

Workarounds I have used are, for example: Nirvana had an additional non-GTD category called Later, which I had no other use for, so I put my subsequent tasks down as Later. Doit has a good visual Priority feature which has a No Priority value which I have no other use for, so I now use No Priority to represent subsequent tasks.

Hmm. In OmniFocus I think that the best workaround would be to:

1) Turn off the sequential behavior.
2) Create a context that's set to On Hold, called, let's say, Pending. You can set your various perspectives to show or hide actions that are not "available", and On Hold actions are not available.
3) When you create a not-actionable-yet action, give it the Pending context. If most of the actions that you enter are pending and you want this to be the default behavior for all new actions, you could make that Pending context the default context for all of your projects.

The down side to this is that it defers the context decision; you set the context when you activate the action. (In fact, that would be how you'd activate it.)

 

[Oogiem]

I figure that the sequential setting is useful for projects that are predictable; I just don't have many of those.

It's also useful for projects where you don't want to deal with the later steps for a while yet. I use sequential almost all the time. If a project really has multiple things I can be doing at once in my world it almost always is actually several projects masquerading as a single project. I can nearly always reduce it to more projects and get the parallel nature stopped.

 

[Folke]

Just FYI, in OmniFocus you can turn off "sequential"

Yes, that seems to be the normal approach for those apps that have it, such as MyLifeOrganized and Nirvana. In Zendone you cannot turn it off, but you can create arbitrarily large clusters of "parallel" tasks within the sequence, for example first of all if you have more than one task that in actionable right now.

I figure that the sequential setting is useful for projects that are predictable; I just don't have many of those.

Or really truly sequential, such as raise ladder, climb ladder, change light bulb, climb down, fold ladder.

Anyway, that is how I feel, too. And it becomes too fiddly for my taste, anyway, to switch the auto-sequential behavior on and off depending on the project's current state. The ideal for me would be to have "parallel" as the default (so I do not overlook it later) and the just drag the task straight into sequence "under the hold line" when I notice that it cannot be done now (and vice versa if I realize the opposite). Then I could have any number of tasks in both "current" and "subsequent".

If a project really has multiple things I can be doing at once in my world it almost always is actually several projects masquerading as a single project. I can nearly always reduce it to more projects and get the parallel nature stopped.

I would say that is perfectly true in theory. If you choose to do it like that, though, you will either end up with a bloated list of projects, where many of them are tiny and interrelated in ways that are not transparent when you view the projects list, or with deeply nested project structures. In most apps you only have the first of these options available (you'll have an immense project list). I suppose in Omnifocus you can probably choose the deep nesting approach, too, with unlimited levels, just like in MLO. While unlimited levels is a strong and useful feature, I do not particularly like being forced to create additional levels just for the sake of "parallelism". All of these measures I find reduce my ability to read and review my projects. I prefer nesting to be done as a way to increase reviewability (like headings in an article).

For me personally, I like "the middle way" best - to have some flexibility within the project as to the number of active and yet-inactive tasks and thereby keep the project list reasonably short and the project structure reasonably flat. And I should perhaps add that this does not go against GTD in any way. In fact, DA talks about identifying a next action for every "moving part" of each project, without insisting that these "moving parts" need necessarily be declared as subprojects etc.

 

[TesTeq]

Stuck at the top.

Or really truly sequential, such as raise ladder, climb ladder, change light bulb, climb down, fold ladder.

I often forget to write down the "climb down" action and end up stuck at the top of the ladder or frustrated after several unsuccessful ladder folding attempts... ;-)

But seriously - many people overthink and overplan their actions...

 

[Folke]

But seriously - many people overthink and overplan their actions...

That's another good reason to just have a simple divider etc between actionable and not-yet-actionable (dependent) and play it by ear.

 

[Gardener]

I would say that is perfectly true in theory. If you choose to do it like that, though, you will either end up with a bloated list of projects, where many of them are tiny and interrelated in ways that are not transparent when you view the projects list, or with deeply nested project structures. In most apps you only have the first of these options available (you'll have an immense project list). I suppose in Omnifocus you can probably choose the deep nesting approach, too, with unlimited levels, just like in MLO. While unlimited levels is a strong and useful feature, I do not particularly like being forced to create additional levels just for the sake of "parallelism". All of these measures I find reduce my ability to read and review my projects. I prefer nesting to be done as a way to increase reviewability (like headings in an article).

For me personally, I like "the middle way" best - to have some flexibility within the project as to the number of active and yet-inactive tasks and thereby keep the project list reasonably short and the project structure reasonably flat. And I should perhaps add that this does not go against GTD in any way. In fact, DA talks about identifying a next action for every "moving part" of each project, without insisting that these "moving parts" need necessarily be declared as subprojects etc.

It's another personal-preference thing. I find it much easier to remember which projects are interrelated than to remember to keep all threads of a multi-thread project going. I prefer the structure that prevents, "Ack! I forgot to call Jane, and now she's gone on that vacation!" as opposed to preventing, "Um, which project was I calling Jane about? Let's check the notes..." Having "Call Jane" as the sole action of an entire project is more likely to have that effect--for me.

Of course, if I found myself checking the notes several times a day, that preference would probably flip. Usually the project name is enough to remind me what it's for.

That doesn't mean that I don't appreciate the flexibility of being able to have multiple actions, but for projects with any sequential nature (as opposed to things like shopping lists or lists of books or lists of ideas or my various single-action lists) I try not to use that feature much.

Multilevel nesting doesn't help me--the structures that I form in my head tend to go many-to-many rather than parent-child, so I'd rather just view the projects flat, sorted into a single level of folders for major areas. (Even then, projects across different folders are often related to each other, but that happens less often, so the folders are worthwhile for me.)

But the list of projects doesn't get too big for me any more, because I regularly move out projects that I realize are not going to progress in the next several weeks--I dump them in source material instead. If several sibling threads for a project *could* be active, but I know that I'm not likely to work on some, I'm likely to move those out.

 

[Folke]

I'd rather just view the projects flat, sorted into a single level of folders for major areas./QUOTE]

Exactly what I do, too!
(In my current app, Doit, the level above projects is called goals, but I assume your folders do the same job )

I need my manual workaround for having as many next actions as I want in each project and be able to "hide" the rest.

 

[bcmyers2112]

When I used to find myself frequently having to scrap next actions related to particular projects because those NAs turned out to be incorrect, it was almost always because I overplanned. For me part of project planning is clarifying what are true next actions versus ideas that need more time in the oven. The latter go in project support.

I have lots of projects that involve subprojects. There's nothing wrong with listing them as separate projects but I don't bother because usually accomplishing the subprojects alone won't mean much unless the ultimate project is achieved. I find it easier to keep my eyes on the prize if I keep the subprojects with the main project. There are use cases for doing it either way, I'm sure.

I find it easy enough to keep future actions (by which I mean actions that are clarified but are dependent on other things happening first) and ideas about possible actions (those that need more time in the proverbial oven) in the body of the digital note representing the project in my digital organizer.

I'm not looking to argue with anyone. Those are just my two cents.

Folke and Gardener, I am curious: what's the advantage in your view of keeping these things as discrete task items in your organizers versus just having them in the notes of a project? I guess I'm just not seeing it.

 

[bcmyers2112]

I often forget to write down the "climb down" action and end up stuck at the top of the ladder or frustrated after several unsuccessful ladder folding attempts... ;-)

I didn't realize you are a cat. I'm impressed. Your spelling, grammar and syntax are better than my cats'.

Don't laugh. One of my cats recorded a macro on my girlfriend's computer and on a subsequent occasion managed to print airline tickets.

I'm not joking.