Comments on: Linking Actions to Projects: The Big GTD Controversy

By: pboru

pboru — Mon, 07 Feb 2011 01:48:51 +0000

One other question I had relates to the Action List and Project Planning File. At any given time should the Project Planning file contain all the actions. Thus if I had Project that had 100 actions and only 15 have no dependencies, does my Project Planning file still contain 100 actions or 85 since 15 are now on the action list.

What is the weekly flow between the Project Planning File, Project Lists, and Action List ?

So if I have 2 active projects I have 4 files: 2 Project Planning Files, 1 Project List and 1 Action List ?

By: pboru

pboru — Mon, 07 Feb 2011 01:19:32 +0000

Thanks Andre. I read David Allen’s book “Getting Things Done”, but I was really confused on the project aspect. I Googled multiple sites to get further clarity, but with no luck. I even wrote a few posts in the GTD forum to better understand projects. It was not until I read your post that it clicked or I had the “ah-ha” moment.

Thanks for the time spent on writing the post. I went back to the GTD forum and provided a link to this page in case others such as myself need the clarity on GTD provided by your post.

pboru Chicago,IL

By: Andre

Andre — Sun, 06 Feb 2011 23:18:26 +0000

I wouldn’t hibernate them if (a) they’re parts of an active project and (b) they truly have no dependencies (you have everything you need to take the action). I don’t know what your tasks are, but I’d assume that at least some of those 15 tasks are done in different contexts. So if six are @computer actions (i.e. they could be done at any computer), three are @errands, and another six are @office actions, you would be looking at much smaller lists at any one time. For instance, if you were sitting at home when you typed your comment, you wouldn’t have to worry about the six next actions that belong on your @office list. Of course, this all assumes that you split your next actions into context lists, which I always recommend.

By: pboru

pboru — Sun, 06 Feb 2011 22:02:01 +0000

Great post, I had been struggling for a few days on this issue until I found your post.

What if you have for Project A 15 independent tasks that can be done now, do you put all 15 tasks on your actions list or do you hibernate some. I typically have multiple projects that have for the most part independent tasks. If I have one spreadsheet for all the independent tasks for all projects, then my fears is I would end up getting bogged down with which tasks to work on and which have priority.

By: kyith

kyith — Sun, 07 Nov 2010 13:29:00 +0000

great post. alot of people who first got into GTD failed to see the esscence of simplicity in the structure of GTD Kyith Productive Organizer.com

By: Piaras

Piaras — Tue, 22 Sep 2009 10:43:07 +0000

Good post, even a year later. projects continue to be a challenge, this was helpful
P

By: Productivity through Lucidity: Why Perspective Precedes Action

Productivity through Lucidity: Why Perspective Precedes Action — Mon, 08 Sep 2008 19:35:30 +0000

[...] to nest action items underneath project headings to reaffirm their relationships. I came to the same conclusion very early on. I found that by using hierarchical lists, I wasn’t so much reviewing as [...]

By: Andre

Andre — Tue, 05 Aug 2008 00:09:30 +0000

Hi Blair,

“Milestone” is a better way to describe an intermediate deliverable than what I typically refer to as a “subproject.” It’s easier for non-GTD users to understand.

3×5 cards are great for planning — for stepping out the milestones; and they give you a good workspace for breaking down milestones into next actions.

By the way, what exactly are you referring to when you mention being “in beta-version”? Is that another (cooler) term for white belt?

By: Blair Rorani

Blair Rorani — Mon, 04 Aug 2008 23:58:10 +0000

I am in beta-version with actions and what David calls milestones in his Make it Up, Make it Happen article.

When you plan a project in some detail (because you need to versus submit tax return that takes say three actions) he talks about purpose, vision, brainstorm, organise and next actions.

When I get to the organise step, I create what agile software developers will call a feature or a story or a backlog item. This is a deliverable. Because nearly every action will have a deliverable (something is different in the world after you take action) then this works well I find. These stories/milestones mean you can keep visibility across an entire project (if it’s mapped out) but the next actions are kept on your flat lists.

For example:
Project (vision step) = Design new training programme
1 Milestone (organising step) = Complete training needs analysis

All that can go with your project support materials.

Then, on your @computer list your next action might be “E-mail SMEs to arrange time to scope learning objectives”. This is one of several actions that will produce the deliverable/milestone of “Complete training needs analysis”

If I am reporting on this project, I can tell the stakeholders the status of the milestone, rather than the next actions. If Matt is responsible for the milestone I mentioned above I know to follow up with him if it gets behind.

If you really need to estimate and track time to complete or effort, then the milestones can have this data added to them as well.

As I’m in beta, I’m using plain 3×5 cards for milestones, and the smallest rectangular post its for next actions on context lists (A4 paper).

By: Andre

Andre — Wed, 23 Jul 2008 22:13:54 +0000

@Joao: The trick is to put blinders on your next actions to avoid thinking about the project it belongs to, and therefore everything else related to it. When I’m making a phone call, I only want to think about the phone call, and not everything I have to do afterwards. At any one moment in time, we can only focus our attention on a single action. Anything else is a waste of emotional energy. That’s why I recommend keeps project headings in a different “drawer” than next actions.
@Charlie: In the case of a research project, unless I had a lot of experience with the material, I would avoid mapping out a complete time allotment on the front end. Instead, I prefer to block a single session for gauge the pace of apprehension, then schedule each subsequent session individually — at least until I have a reliable idea of how much ground I can cover per session. Reading 100 pages of Being and Time will take much longer than reading 100 pages of Time and the Art of Living, so the density of the material needs to be factored in.
Once I map out a project plan, I extract the next actions and file the plan away for retrieval on an as-needed basis. It might take me eight weeks to complete a research project, but I’m generally not concerned about anything that lies beyond the week ahead (i.e., past the next weekly review) unless I’m behind schedule, or need to ensure that something else I’m scheduling that far in advance doesn’t conflict. As long as I’ve done everything I’ve scheduled between weekly reviews, and assuming there hasn’t been a change of deadline, I don’t need to review the plan to reaffirm than I’m on course. But if I find myself lost for any reason, that’s when I pull out the project plan again. Sometimes I do find that I’ve left something out, but as long as I know I’ll see the plan once a week, I usually don’t have to think about in in between.