Why would you want to list all the possible actions? Way to much work. Just write down the next actions. Think of them as kinda sort of bookmark like in ok that's where I am with this project at the moment.

Do you want to see all the work at a glance? A big outline? The blueprint for your project? In strict GTD this is project support material. Project support does not belong onto your next action lists.

Keep your system simple.

Enjoy life.

Thanks very much for your response. On one level I understand what you are saying. But during my collection phase, all of these tasks (call this person, email that person, buy this reference book, check at that library, etc) were in my head, and in order to get them all out, I wrote them onto individual 3x5 cards. Now I've got this stack of tasks that I thought were going to be processed (one at a time) by either doing, delegating, or defering. Now how do I tell which tasks (that take longer than two minutes, and are not reference, or someday/maybes, or delegatable) get put into context lists and which are the "project support materials" you mentioned? Sorry if I seem thick and thanks again to anyone.

They are specific actions, and certainly they are bundled into things with singular goals, right? I would think of each singularish goal as a project.

I think it's perfectly fine to have projects and subprojects etc. Don't spend too much time on that kind of organization, though. on my ktgd i have projects and subprojects. the nice things about omnioutliner is that it's trivial to layer those things.

I've also taken advantage of GTD's "area of responsibility" thing, which are kinda ongoing bins. So I have an area of responsibility of a class I'm teaching. Projects are like "write midterm exam." Next actions are specific places to look for quesitons, etc.

GTD is the most powerful when you break things down into useful ways, not too big. "Write a book" is way, way too big for a project. Identify subgoals. Collect next actions around those subgoals.

those are my thoughts.

I try to keep my projects as small as possible, so as to give myself a sense of accomplishment.

I would put "write book" in the higher levels of GTD planning, perhaps at 20,000 feet (areas of responsibility), 30,000 feet (1-2 yr goals) or at 40,000 feet (3-5 year goals). This would depend on how soon you need to finish the book.

You know you want to write the book. The key is coming up with all the smaller projects that will get you to that larger goal. You might create projects for each of your research agendas. Or you can create a project such as "draft chapter one." By setting your sights on more immediate outcomes, you can then think of the concrete steps you need to do in order, say, to draft the first chapter. Sometimes, when working on a big project, it's helpful to forgot the immensity of the total task and to focus on the smaller pieces.

Thanks very much for these responses. They have clarified for me the best approach for dealing with a very complicated, multi-multi-step project. As I process my inbox today I'll identify the smaller subproject that each task belongs to and track progress that way. I agree that this will provide more opportunities to see movement forward and break the large (sometimes overwhelming) project of writing a book into manageable chunks.

Thanks again for your help.

"Rather than trying to run down all the branches to the end, using GTD means thinking just as far ahead as you need to think in terms of your actions, and no further. So when things change in the real world, as they invariably do, you don’t have to spend hours re-drawing the Gantt chart — instead, you are already at the appropriate juncture, and can instantly re-calibrate and change course to take the next most appropriate path."

http://www.43folders.com/2006/10/17/robert-peake-part-one/#more-730

How many of these are mutually exclusive?

Call this person goes on @phone
e-mail that person goes on @email
buy book and check Library goes on @errands

The problem would only lie if one task dependent on the completion of another. e.g. if Call person depended on you having received the email or bought the book first.

I'm not writing a book, but am writing an album. I have a project with the album title, which has subprojects for each song, and a list of other tasks in a project list and NAs for any task that doesn't require others to be completed first (like brainstorm album titles, brainstorm cover ideas).

Each song, then has a list of things I need to do to complete it (like Research lyric idea, write lyrics, Create new project file etc). I only add one or two NAs depending on the state of the song. e.g. I might have a brainstorm lyric ideas as a NA and a record guitar part NA. (if I had written the music first).

I've done a quick count of the steps I've written down for the 11 songs and overall project and there are probably around 150 items in the project lists (which will grow / shrink as things progress), but I only have around 15 actual NAs on the go.

There would be no point me adding a "mix song" NA until I had completed recording all the bits, so it stays on the list of tasks for the project.

When I finish one NA, I look at the task list for that (sub) project and choose the next appropriate NA.

It is quite fluid, since part way through the song I may change the instrumentation, or rewrite something or scrap the song so the project task list only needs to change and I don't need to find and change a bunch of NAs.

Regarding the Novel thing. I might try the write a novel in a month thing next month. (http://www.nanowrimo.org/). I think that will be a project with one NA. "Write more stuff".

Hope that helps

Chris

This is a good thread, very helpful.

Having written novels, I can add this. Perhaps the most immediately beneficial aspect of GTD will come when you're actually in the writing process with your capture device beside you. You will help yourself immeasurably if you can train yourself to jot down all the many things that dart through your mind as you're writing, rather than let yourself get distracted.

"I wonder if daffodils would actually be in bloom?" is a note in your capture device to track down later, for example, rather than going off surfing the web to find out when daffodils are in bloom.

One of the most useful things I learned as a writer was to to leave blanks when I wasn't certain of something and keep writing, or write something descriptive knowing I needed to figure out the correct word later.

She grabbed the __________ from the desk behind her and held it behind her back. (Note in capture device: think of something more interesting than bookend that can be used for weapon.)

Or, He opened a leather--would it be portfolio? not sure-- and pulled out a sheaf of yellowed pages. (again, note in capture device, "would Jerry carry a leather portfolio or is that too formal?)

Your capture device will be your friend many times over. It can help you stay focused on the page in front of you instead of tracking down details that you can do later.

Good luck!

I've tended toward a rule of thumb that no project (sub-project, whatever) should be longer than 2 hours. Somedays, I make the project no more than 45 minutes.

The key is to break the big outcome down into smaller sub-projects you can wrap your mind around.

But if you need to sit down and *write* for 3 hours, then that's an appointment on your hard-landscape calendar. I suppose you could list it as a next-action (@computer) or project ("write for 3 hours") depending on how you think about it.

While your miliage will clearly varry, there are a couple of very logical way that you might think about breaking up a book. I'm no expert, but it's always seems to me that the first key is to keep the invidiual tasks as specific as you can, rather than vauge "write 1000 words in the morning," something like "wrap up chapter 3" and so forth.

One way to break up "the book," is by aspect. Use different projects for data collection, analysis, outlining, drafting, revising, seeking feedback. Frankly, I wish KGTD had a cascading context feature. Ultimitly it's all different contexts, even if it's in your head, so maybe you keep the single project, and then have a context of computer-_____, where ___ is the "aspect." Which would work. I haven't tested it out, but surely you can have various levels of an action. WIth start and end dates, you can keep your scope narrow enough, to not be descrited by everything that is going to be comming up, but you don't have to break the system too much.

I hope that made sense,
cheers,