Ok. I sorta remembered my other question.

From the sounds of it, you should only have one NA for a project. But what if there are a couple things that could be done next on the project, independantly of one another? Lets say I could make a call to someone about one part of the project, or pick up some needed supplies for another part of the project. Is it a bad idea to put an NA on both my @Phone and @Errand lists? Is this acceptable? Am I thinking about this wrong? :confused:

NAs in different contexts are fine. It's putting things on the action lists that aren't actions which causes the problem. So, an NA saying

@calls-phone Fred about project X

and

@errands-buy chipboard for project X

is fine.

In fact, I see nothing wrong with

@calls-phone Fred about project X
@calls-phone Harry about project X
@calls-phone Jane about project X

As long as the calls are INDEPENDENT. If you need information from Fred before you can speak to Harry, then phone Harry is not an NA. Similarly, if you need to talk to Fred before buying the chiboard, then the latter is not an NA (yet).

Does that help?

Steve

Thanks Steve, that does indeed help. If I'm going to be doing this sort of thing though, where parts of a project are independant of other parts, would it be best to scrap the original project and create smaller projects for each independant piece, in order to keep clear outcomes? Or does this just introduce more complexity into the system than it's worth?

Seriously, what ever works for you is 'best'.

Slightly more helpfully, perhaps, is 'sometimes'.

This something that doesn't come over very well in the book, but DA has spoken and written about (and I could probably find the reference I'm thinking of if I wasn't at work stuck behind the firewall). Not all projects are alike! Many projects (most?) won't require any significant planning. There will be few enough NAs so that you won't need to worry about splitting things into sub projects. If we use the earlier example, the project could be 'put flooring down in the roofspace of the garage'. You need to buy the chipboard and invite a few mates to come round to help (with the promise of beers, perhaps :D). Doesn't need splitting up -- even if you make it more complicated and so some phoning round to get the best price on the chipboard.

Something like 'build the garage' would require much more planning and might well end up spawning sub-projects.

That's how I'd do it. anyway!

Steve

Haha. Yeah, I guess it makes sense to go with whatever works for me. It's just that I've tried organization many times before, and they've all failed. I was just trying to stay as rigidly by-the-book as possible, in hopes that it would keep me from making a mistake. Suppose I should put a little slack in the reigns...

What you said makes sense though. Scope is something I have trouble with, but I'll just have to stick to using my judgement on it. Thanks again though for answering my question about multiple NA's. That was a big help. :)

What I was thinking of was Stew of this parish.

Might help - explains things more clearly than I managed

S

Thanks for the link, Steve! I'm glad you found it helpful. :)

Kris, et al. -
I think the important thing to take away from GTD is that it's not an organization system or a documentation system - it's a reminder system designed to keep one's head clear. True, these reminders are organized in some fashion, but that's not the end-all, be-all of the system. If someone were to find my notebook and open it up, they'd have a tough time deciphering it. Lines from here to there, margin notes, colors, bits scratched out....some pages are just a mess. But I don't keep it to pass on information - I keep it for myself. Even the way I wrote something (or the pen I used, or the post-it note it's written on) can remind me of the state of mind I was in when I wrote it, which, in turn, can remind me of what I need to do next and why.

Thanks Stew/Steve. That was a great read. I think I was following a similar path of over-analysing every project. I'm a little obsessive compulsive, so losening my grasp might be tough. I'll definitely give it a shot though. :D

Thanks again.

Hi Kris, before trying GTD I was like you. I had tried several organization systems, and I just wasn't able to make them work for me and how I worked.

The thing is, I've found that GTD was actually the first system that is designed to be flexible, and DA even mentions that (in the project planning bit quoted above). I don't need to treat remembering to buy dog food in the same way I need to treat managing a multi-million dollar project.

Good Luck!

Adam

I'll add a few thoughts to the other terrific comments above.

o How much project planning you need to do is a combination of personal preference and the complexity/scope of the project. You decide. *However*, doing it while processing your inbox is not a good idea - it will slow you down from getting it to zero, which is crucial. If two minutes of "back of the napkin" sketching is adequate, great. Otherwise, make an action called "plan project x." That said, if you have a ton of ideas just from looking at the sheet of paper, by all means capture them. It's not work losing them (as you experienced with your "I just had it" question).

o Each project needs at least one active action, but more (if they're independent) is fine. You're call - how fast do you want to move the project ahead?

o Contexts are optional. I've worked with people who have 200+ actions and *like* a single "actions" list. Your call - try both, see which works.

o If you're away from your files and you'll be working on the project, make sure to bring the plans with you. I recommend to clients they carry the following:

o calendar
o actions list
o [waiting for]
o [projects]
o capture tool (i.e., blank pad/cards)
o Action Support folder (for actions needing paper that doesn't have a dedicated folder)
o Read/Review folder (for those "between" moments - only for FYI reading, BTW)
o relevant project folders

o "sub" projects: If it helps mentally to create separate projects for different parts of a main project, that's OK. The main project might have an overarching set of plans and ideas, which are implemented by the sub-projects. In general, keep it simple if possible. One tip: If you want to keep paper from separate aspects of the project grouped together, try prefixing the file folders with the project name then the subcategory, e.g., "NASA consult - plans", "NASA consult - contract", "NASA consult - travel", etc.

Hope that helps!