How do I get next actions to play well with projects?

G

gernblanston

Guest
I’m experiencing a series of issues around organizing tasks versus projects properly. I would appreciate any feedback or advice. Not that it matters too much, but to give you an idea of my system I’m using a Moleskine large ruled notebook (the one with the hardback cover).

1. As we know, many projects require only two or three tasks to complete. It seems wasteful to use an entire page in a Moleskine notebook (or any other notebook for that matter) to track such projects. Some options I’ve considered:

  • Track more than one project on a single page... but the problem is I would need more space in case the scope of the project changes.
  • Use Post-It notes and stick ‘em into my notebook.
  • Any additional ideas that you may have.

2. I find that projects -- not just next actions -- belong in many context-based lists. This presents a problem because it seems that GTD calls for restricting each list to tracking either a project or next action (not both)ß. For example, I created a context-based list called @Lamborghini to track anything to do with my car (a Pinto). One of my list items is “get car serviced,” which requires more than one task and thus constitutes a project (I have to call the dealer/local repair guy to compare quotes, work it out with my carpooling partner, etc.). But I also have tasks, such as “get car washed.” Questions:

  • Would I perhaps gain more efficiency by creating a separate list called “@Car service”? If so, I would definitely run into the problem described in item #1 above: having to document a project with only two or three next actions.
  • Might it be better to create two context-based lists with the same name -- one for projects, the other for next actions?
  • Okay, I was kidding about the Lamboghini/Pinto thing. (I have a RAV4 (and my list is so named.)

3. When I’m capturing stuff to my system, I find that I tend to get bogged down in thoughts of “now where should I put this?” instead of focusing just on capturing. Any advice here?

  • One option I thought of is to create a “brainstorm” list that I can use as a draft of ideas and then transfer items as necessary to my system.
  • Another thing I had considered was that as I get more seriously into using my system (I’m relatively new to this), I find that I will be creating lists on an as-needed basis -- in other words, perhaps over time, my needs will help create the system.

Once again, I’m grateful for any feedback.
 
TesTeq

TesTeq

Registered
Answers to questions 2 & 3.

gernblanston;58078 said:
2. I find that projects -- not just next actions -- belong in many context-based lists. This presents a problem because it seems that GTD calls for restricting each list to tracking either a project or next action (not both)ß. For example, I created a context-based list called @Lamborghini to track anything to do with my car (a Pinto). One of my list items is “get car serviced,” which requires more than one task and thus constitutes a project (I have to call the dealer/local repair guy to compare quotes, work it out with my carpooling partner, etc.). But I also have tasks, such as “get car washed.”
Click to expand...
Projects do not belong to contexts! They may belong to areas of responsibility/interest/focus (20K level). @Lamborghini is your area of focus and it should not contain any Next Actions.

gernblanston;58078 said:
3. When I’m capturing stuff to my system, I find that I tend to get bogged down in thoughts of “now where should I put this?” instead of focusing just on capturing. Any advice here?
Click to expand...
It's easy. Just put your notes in your inbox and forget about them until the processing time.
 
darlakbrown

darlakbrown

Registered
You absolutely do not need to use an entire sheet of paper to for each project name. You can simply create a list of projects on one page. Some projects will require additional support material, which you can create (and reuse) a simple file folder for. As you do your weekly review, scan the list of projects and pull (at least) one next action for each project on the list. Put the next action in the appropriate Context list. Then when you're in that context look at that context list. You're overthinking this.
 
G

gernblanston

Guest
Reply to TesTeq

TesTeq;58079 said:
Projects do not belong to contexts! They may belong to areas of responsibility/interest/focus (20K level). @Lamborghini is your area of focus and it should not contain any Next Actions.
Click to expand...

TesTeq,

I'm a little more confused now. If @Lamborghini is an area of focus and should not contain any Next Actions, where do I keep the list of Next Actions associated with my car? In other words, how can @Lamborghini not be a context list based on my car?
 
A

aaronmclay

Registered
Just want to make a quick comment here as I had a similar problem.

First, DA suggest that you have one list of Projects. It's a simple list of all your projects and what I find helpful is to group things together by Areas of Focus or the 20K level. For example, I have a Home and Car Area of Focus where I list all the projects that pertain to my house and car.

I use a software program called OmniFocus as it helps me organize my projects into these "Areas of Focus folder.

Second, I believe that you should only have your active projects for the week (or until your next weekly review) on your projects list. Everything else can go into your Someday/Maybe list.

Not to steal from the Weekly Review CD that DavidCo sells but there was a specific section where they talked about how many people have many different Someday/Maybe list for all the different areas of their life. Perhaps you can have one for Future Car Maintenance....

Third, your context really should reflect the physical item or location you must have to complete the action. In your example, @Lamborghini would only work if your NA was, "Wash Car" or "Change Oil" ect.

However in your specific example there are many different contexts. Here is what I would have done... I have to call the dealer @Phone/ local repair guy to compare quotes @phone, work it out with my carpooling partner @partners name, take car to shop @errands etc.

If you think about it the only one that requires @Lamborghini is taking the car to the shop...but what's needed to make that next action successful...the shop..which is the context.

I hope I didn't confuse you to much.;)
 
G

gernblanston

Guest
aaronmclay;58090 said:
Just want to make a quick comment here as I had a similar problem.

First, DA suggest that you have one list of Projects. It's a simple list of all your projects and what I find helpful is to group things together by Areas of Focus or the 20K level. For example, I have a Home and Car Area of Focus where I list all the projects that pertain to my house and car...

Second, I believe that you should only have your active projects for the week (or until your next weekly review) on your projects list. Everything else can go into your Someday/Maybe list...

Third, your context really should reflect the physical item or location you must have to complete the action. In your example, @Lamborghini would only work if your NA was, "Wash Car" or "Change Oil" ect.

However in your specific example there are many different contexts. Here is what I would have done... I have to call the dealer @Phone/ local repair guy to compare quotes @phone, work it out with my carpooling partner @partners name, take car to shop @errands etc.

If you think about it the only one that requires @Lamborghini is taking the car to the shop...but what's needed to make that next action successful...the shop..which is the context.

I hope I didn't confuse you to much.;)
Click to expand...

No, you didn’t confuse me at all -- in fact, you’ve clarified something that I think I may have misunderstood the first time I read the book: the idea that context-based lists are theoretically supposed to be based on a location. I’ve been thinking of context lists in much broader terms: more as projects.

I’ve been using the GTD principles for some months now at work, with great success. What I do is fairly simple: in Outlook, I create a Task folder for each project I’m working on. So for example, I might have Task folders called, “Book 1,” Book 2,“ and so on. I’ve read postings from people on this site and others that talk about keeping all of their tasks in the same Outlook Task folder and then categorizing them... I’ve tried that and I find it’s time-consuming and crowded. My solution has worked very well and increased my productivity tenfold. I’m also a lot calmer when I’m at work. For the purposes of Outlook, I don’t really need an @Computer list because I’m always at my computer. So I just organize everything by project.

To keep to the point, I mention my Outlook system because it works very well for me. I don’t like electronic organizers, so I’ve resorted to using a Moleskine lined journal for my personal GTD. But that’s where the way it works breaks down.

At the beginning of this response, I wrote that I may have misunderstood context lists the first time I read David’s book. I’ve been thinking of lists more as project-based than context-based. I think this is one of the issues I have with GTD. Don’t me wrong -- it’s changed my life for the better. Maybe this is sacrilegious, but it seems counterintuitive to me spread related tasks across different lists. It seems far more intuitive to group my car servicing into a project-based task list.

Consider the following two sets of lists:

Set 1:

Project List of Next Actions: Get Car Serviced
- Call Toyota to get info on 10k mileage servicing/estimate.
- Call local repair shop for estimate.
- Decide and schedule service.
- Call carpooling partner.
- Drop car off.
- Pick car up.
​

Set 2:

@Phone
- Call Toyota to get info on 10k mileage servicing/estimate.
- Call local repair shop for estimate.
- Decide and schedule service.
- Call carpooling partner.
- [Other phone-related tasks sprinkled throughout this list]

@Errands
- Drop car off.
- Pick car up.
- [Other errand-related tasks sprinkled throughout this list]
​

Am I misunderstanding the purpose of context lists, or did I get it right? It seems to me that Set 1 is a lot easier to follow.
 
K

kewms

Registered
gernblanston;58093 said:
No, you didn’t confuse me at all -- in fact, you’ve clarified something that I think I may have misunderstood the first time I read the book: the idea that context-based lists are theoretically supposed to be based on a location. I’ve been thinking of context lists in much broader terms: more as projects.
Click to expand...

To be precise, contexts are based on available resources. @Phone items, for instance, are calls that can be made from any phone. That's the list you look at while you kill time waiting for your flight, because you know you can do everything on it.

At the beginning of this response, I wrote that I may have misunderstood context lists the first time I read David’s book. I’ve been thinking of lists more as project-based than context-based. I think this is one of the issues I have with GTD. Don’t me wrong -- it’s changed my life for the better. Maybe this is sacrilegious, but it seems counterintuitive to me spread related tasks across different lists. It seems far more intuitive to group my car servicing into a project-based task list.

Consider the following two sets of lists:

Set 1:

Project List of Next Actions: Get Car Serviced
- Call Toyota to get info on 10k mileage servicing/estimate.
- Call local repair shop for estimate.
- Decide and schedule service.
- Call carpooling partner.
- Drop car off.
- Pick car up.
​

Set 2:

@Phone
- Call Toyota to get info on 10k mileage servicing/estimate.
- Call local repair shop for estimate.
- Decide and schedule service.
- Call carpooling partner.
- [Other phone-related tasks sprinkled throughout this list]

@Errands
- Drop car off.
- Pick car up.
- [Other errand-related tasks sprinkled throughout this list]
​

Am I misunderstanding the purpose of context lists, or did I get it right? It seems to me that Set 1 is a lot easier to follow.
Click to expand...

The first issue is that neither Set 1 nor Set 2 contains Next Actions. A Next Action is immediately doable, with no dependencies. But you can't call the repair shop for an estimate until you know what work you want done, and you can't arrange alternative transportation until you know when you need it. So calling Toyota is the *only* Next Action for this project. Everything else is project support.

Second, Set 1 *is* easier to follow if that's all you have to do, or if you're working consecutively through the car service project. (Which is why this list is project support material.) But if you have 20 different phone calls to make for several different projects, it might be helpful to have all of those phone calls in a single list where you can just crank through them. Similarly, if you have big chunks of reading to do for five or six different projects, it might be nice to have a complete @Reading list to help you decide what to read given the amount of time you have. That's where context lists come in handy.

Hope this helps,

Katherine
 
M

Mark Jantzen

Registered
Seems Like Overplanning

That's too much work for me.

I put this on my Project list: Get Car Serviced

I put this on my @Calls list: Toyota re: service estimate ###-###-####
(don't underestimate the value of the phone no.!)

The other stuff sounds like too much work and would clutter my next action lists. I personally keep a page of notes in an ACTION SUPPORT folder with all the other thoughts or ways to clarify the initiative.

I might put the second call (local garage) on my action list but I'm not going to put, "Drop off car" until I've decided where and when I'm going to do that. I want the flexibility to deal with changes that happen along the way and not have to renegotiate much more than my next action.

My $0.015
 
A

aaronmclay

Registered
it seems counterintuitive to me spread related tasks across different lists. It seems far more intuitive to group my car servicing into a project-based task list.
Click to expand...

1) I want to say, that you have to find out what works for you. Hey, you may make some mistakes but do what feels best.

2)I'm going to reference the "Productive Talk" Podcasts that David and Merlin Man at 43Folders.com did 2 years ago AND the Weekly Review Audio CD....

Both of these program, David has said, numerous times, referencing concerns about spreading NA over different context list (away from the project parent), "In the 20 or so years since I've developed this program, anyone who does the weekly review never has the problem of connecting next actions to projects or vise versa."

I'm paraphrasing and this isn't exactly your issue. However, in the GTD book David mentions that when you decide what NA you want to take action on you can choose by the Context you're in and then decide based on priority, energy, etc...

The benefit may not be self evident at first. For me, it turns my 130 NA list down to 20 NA to be done @home or 30 NA's @Computer...etc. How much easier is that!

I used Outlook for a long time until I moved to the Mac. You're system sounds a lot like Sally McGhee's which is like GTD but slightly different words and a heavy focus on Outlook.​

Consider the following two sets of lists:

Set 1:
Project List of Next Actions: Get Car Serviced
- Call Toyota to get info on 10k mileage servicing/estimate.
- Call local repair shop for estimate.
- Decide and schedule service.
- Call carpooling partner.
- Drop car off.
- Pick car up.
Set 2:
@Phone
- Call Toyota to get info on 10k mileage servicing/estimate.
- Call local repair shop for estimate.
- Decide and schedule service.
- Call carpooling partner.
- [Other phone-related tasks sprinkled throughout this list]

@Errands
- Drop car off.
- Pick car up.
- [Other errand-related tasks sprinkled throughout this list]
Am I misunderstanding the purpose of context lists, or did I get it right? It seems to me that Set 1 is a lot easier to follow.
Click to expand...

Actually, in my system I have both! =) I think you're right on target. In your Moleskin you may just want to carry NA's with you and leave your Project Support Material or Set 1 in Outlook.

However, when creating your next Actions list I would structure it a bit like this...

@Phone
- Call Toyota Maintenance Department (###-####) to get info on 10k mileage servicing/estimate.

Wait?!?! Where are all the other steps...well, Next Actions are the physical next step that advances the project. As Katherine stated, you all that other stuff is all dependent on what Toyota tells you.

Here's a quick tip about small project planning...
For my small project I don't plan anything but the next action I need to take on it. So many thing change because of the new information you get from completing a next action. As soon as I've completed the next action I immediately process that information and create a new next action for that project...if I have the time, energy, and I'm at the write context I do it. If I'm not then the NA goes on the appropriate context list and I merge the NA with my project during my next weekly review or when necessary.​

Here's a great example that happened to me today.

Project: Change Porch Lights to Energy Saving Bulb
NA: Find 4 Energy Saving Bulbs and take Downstairs [Done]
NA: Get Ladder from Utility Closet and place under first Porch Light [Done]
NA: Find a freaking screwdriver [Done]
NA: Remove Old Bulbs from Porch Light - Not Done :(

* The home builder decided to use apoxy to glue the porch lights down. Now, if I had planned that project out instead of just doing NA after NA I would of had to go back and replan and replan and then I wouldn't trust my system.

Instead there is a big stinkin' NA on my @email to the Home Builder on why they did this...

Regardless of all that chatter I just typed above, I suggest you take a 30 minutes tomorrow and just create a system for your Next Actions and use it for a couple of weeks and see what happened and what did you learn. Keep trying new techniques/software/hardware until you find what works. =) I wish you the best of luck.
 
B

BigStory

Registered
How about...

Hi Gern,

If you are at Outlook everyday, then why don't you just print out your next actions and toss the sheet into your Moleskine. You can use your Moleskine as an "inbox" or portable capture device.

Remember that next actions can kick you off, but you don't have to stop there. If you pick up the phone and call Toyota, and they tell you what you need to know, then you can simply do the next thing(s) if you want to keep running. When you have gone as far as you can or want, to go, just put the next action on your list and move on.

Many small projects don't need to be "Planned" past some quick brainstorming; you know the steps in your head faster than you can write them down, just as long as you don't forget the project itself. What you do need is 1. An outcome on you project list so the project doesn't slip through the cracks, 2. A next action in the proper context list so that if you are knocking off "calls" you can move the project forward an inch at least, and so you know where to pick up when you leave off.

Best Wishes,
Gordon
 
W

wordsofwonder

Registered
A couple of random thoughts on this topic:

First of all, I heartily concur with the comments about only writing down your next Next Action for any given project. I'll bend this sometimes and have multiple NAs for a project, under two circumstances:

  1. They don't depend on each other. For example, if I have to call Joe about project XYZ and I have to update the XYZ Wiki, the actions can go on my @Call and @Computer lists as long as the Wiki update isn't dependent on what Joe tells me. In this case, I limit myself to one NA per context, so that when I'm making phone calls, I only have one choice from my @Call list for the XYZ project.
  2. If I'm waiting for things from multiple people to move a project forward, I can put multiple items on my @Waiting list.

I've found, for my work (writing, photography and Web stuff) that mapping out the chain of possible future NAs I might take is usually not helpful. For example, I might list out a whole chain of actions that revolves around taking my Scion to the Toyota dealer for an oil change. But if I call the Toyota dealer and the next appointment they have isn't for six months, then my new NA becomes "Find a new dealer to service the Scion" and all that other planning goes out the window. So, when I brainstorm out that stuff, it goes in my project support folder for future reference, but not on my NA lists.

The other problem with maintaining project/next action linkages is that, if your tool provides any friction at all in terms of managing the linkage, you'll tend to resist doing it. My GTD system (using the now-orphanware NoteStudio Wiki) does a fair job of maintaining these links, but only because I've created a structure that automatically builds several kinds of indexes to let me see my lists in different ways. On the other hand, I found with both outliner-based systems and the NetCentrics GTD addin for Outlook, that maintaining the linkages was too much effort. And, too, if you can't tell from looking at your NA which project it goes with, that ought to be a warning sign that you don't have a good handle on what's on your project list.
 
Cpu_Modern

Cpu_Modern

Registered
wordsofwonder;58141 said:
I've found, for my work (writing, photography and Web stuff) that mapping out the chain of possible future NAs I might take is usually not helpful.
Click to expand...

Instead, mapping out the chain of (almost) definitive future, uh, milestones / sub-projects / deliverables, can be an awesome thing (for larger projects at least).
 
W

wordsofwonder

Registered
Cpu_Modern;58158 said:
Instead, mapping out the chain of (almost) definitive future, uh, milestones / sub-projects / deliverables, can be an awesome thing (for larger projects at least).
Click to expand...

Very true...and I often do that. I guess the point I was trying to make was that it seemed the original poster was getting bogged down in mapping out the future at too low a level of focus. I think that's where the trap lies.

I have about a dozen higher-level "meta-projects" on my list right now, each of which could (over its execution) spawn several projects. Having those longer-term goals mapped out definitely helps me execute on them - and, in fact, I've brought several of them to completion over the past few years.

But there's a difference, I think, between that and "map out the next 10 possible NAs that it might take to get my car's oil changed."
 
J

Jamie Elis

Registered
possible confusion of terms...

I think that there may be some confusion of terms. Just how close to GTD my definitions are, I don't know, but I am going to give you My capsule summary of terms for what it is worth....

Calendar= Basically a reference list of ordered dates with known date-related info such as deadlines, lead times, and appointments and other time-related information (holidays). Can also be a communication device and tool for looking into the future.

Context or next action lists= Lists by location or other limiting factor (such as a machine or a person) of activites that are reasonably specificied and that for you are a single action and that will move a defined project along or just have to done in your life. Sometimes these refer to or include a checklist.

Project List= The names of each project you are currently taking active steps on plus a brief description of desired outcome, and possibly purpose and due date to which you are commited. Some people have these in order by area of focus. This is not necessary but may have merits for some.

Currently = intention/hope/wish/necessity to take at least one action between your weekly reviews + probable opportunity given your various resources (including time not allocated to pinned down commitments and routine tasks). So get these on your calendar and review it before you make your action lists.

Project Support Page and/or File:

Support page = rough or summarized information that you need to have handy to manage your project or think your project through or carry out your project's actions, this can include lists of people, stuff, specs, ideas, timeline etc. Why might you need this? Your next actions might be occuring in various contexts and you might want to have "specs" at hand (phone numbers, sizes, names of key players). Also, as you complete one action on an active project you should create the next one and put it on a context list. You might need to refer to a mini-outline of your project to figure out the n/a. I find I need to do this in projects that are novel to me or have a lot of details. Remember that sometimes the n/a is "analyze pros and cons" or determine the n/a, not to worry, just be sure to write this down in the context list that corresponds to where you think can perform this.

If you are a student, an annotated syllabus and course bibliography is a great support page. But you will need to work with this with a calendar.

Support File = could be any combination of a folder, a note book, a textbook with sticky notes, a whole drawer if need be, or a computer file.

Work style and situation(s) will help you decide if you should just have all the active projects on a list, and/or a single page for each (or most) with some notes. Some people do not use a single page per project but refer to their support file. Where you are most of the time and the kind of informtion you need to create your description of your n/a will be factors in what you choose.

Sometimes the support page is a checklist.

SDMB Project List: List or list of projects in various states of description and actuality. What they have in common in that no action is planned at this time and you will not consciously plan an action, if you plan any at all, until the next weekly review. There will be a huge variation in degree to which these are described and defined. Some are projects you have started and really worked out in detail but you are settting them aside for some reason, possibly with a calendared note as to when you want to do something on them. Some are just little wishes or wisps of ideas but you want to look at them and mull them over. Some people divide these into real projects that are underway but they won't be taking an action on until a specific dates (SomeDayForSure) and those that are still wishes or even ones you hope might go away.

I hope this helps and I hope that if someone defines these more usefully they will feel free to commnet.
 
G

gernblanston

Guest
Fog has cleared re context v. projects, but now murky on project support

When I started this thread, I misunderstood the definition/purpose of a context list. My mistake, according to the responses here, was in forcing the project itself to be the context.

Well, I’ve seen the light. At least, dimly. (Thank you.)

There’s another issue, however, that I haven’t really been able to wrap my mind around.

I mentioned earlier that I have implemented, very successfully, an Outlook-based GTD system at the office. When I went back and studied my system through the prism of this thread, it occurred to me that I’m probably not using context lists as they’re strictly defined. If I understand the definition of “project support” lists (thank you Jamie Elis), I think I’m employing those in the form of checklists.

Here’s my method, in a nutshell. As a technical writer, I often work on five or more projects (manuals) at a time. Each of these documents has a myriad of details that require tracking. Most (if not all) are non-sequential; there is, 98% of the time, no specific “next action” -- it’s just a task. It can be done now, in fifteen minutes, or anytime before the end of the project. It doesn’t usually matter.

For the two percent of project-related tasks that need to be done in a certain order, I tend to place them in a hierarchical order in my Outlook task list. I get them out of the way.

To track tasks for each project, I’ve created a single task folder for each project in Outlook. I check off each task as I complete it. When a new task pops up, I plug it into the list appropriate to the project. At the end of the project, I know I’m done because I’m staring into an empty task list.

This method works for me brilliantly, and I can honestly say that I have increased my productivity about 500 percent since implementing it.

It would not make sense for me to separate all of these tasks into “context-specific” folders (that is, if you define “context folders” as strictly as has been done here). There are, of course, cases in which context does apply. But those are rare, especially with most of my projects lately -- since I am currently working with overseas engineers, I work at a single workstation almost 100 percent of the time.

Given both the success of my current method and the realization I’ve had about context, I’m now puzzled: how might David Allen characterize these task lists? Are they indeed “project support checklists?” Is it normal for such lists to be employed more than context-based lists? Or would you consider them “context-based lists?” (@Manual1, @Manual2, etc.)

Or, does it really even matter?
 
K

kewms

Registered
If it works for you, I don't think it matters. DA himself is a highly mobile executive who probably travels 80-90% of the time. Contexts are much more limiting for him than for someone who is at the same desk essentially all the time.

Katherine
 
Cpu_Modern

Cpu_Modern

Registered
gernblanston;58346 said:
I’m now puzzled: how might David Allen characterize these task lists? Are they indeed “project support checklists?”
Click to expand...

The scientific(sic) method would say: project plan in the form of a checklist.

David Allen would have a fancier way of stating it. Maybe like this:

"If you have some enhacing checklist that jazz up your view on your vertical focus, add these to your project support material as well. "
 
You must log in or register to reply here.
Top