One frustration that I’ve had with GTD was the requirement that I separate my project plans from my NA list. If my project is “Shed built,” I can’t install the four corner posts until I’ve installed the base. I can’t install the roof, until I’ve installed the four corner posts.
Sometimes I would cheat and have many actions on my NA list:
Install base
Install North post
Install East post
Install South post
Install West post
Install roof
Only “Install base” is a NA, since none of the other actions can be done until the base is installed. The order in which the four posts are installed is not important. Any of the posts can be installed once the base is installed. So, once the base is installed, all four post actions are NAs. The roof cannot be installed until all four posts are installed.
Rigorous GTD states that I should have only “Install base” on my NA list. Then, when the base has been installed, I can put only the four post actions on my NA list. Then, when all four posts are up, I can put “Install roof” on my NA list.
I would sometimes cheat, and put all the actions on my NA list, because, for simple projects, I didn’t want to put the project plan in a separate place from my NA list. Although the projects were simple, they were complex enough that I did want a plan that told me what to do after each stage was completed.
If I were doing GTD on paper, I would review my NA list, see the “Install base” NA, then find the “Shed built” project plan and start working off the project plan. What I would like to do is avoid having to look at two lists: NA list and Project Plan.
If I were doing GTD electronically, I still have the same problem with most systems. Most systems do not differentiate between Next Actions and dependent actions.
The system I currently use, Achieve Planner, has recently updated so that I can now plan my shed and, with the click of a mouse, view either my Next Actions only, or my full Project Plans. (I have no financial interest in Achieve Planner other than being a satisfied customer.) This means that I put actions under projects, whether the actions are Next Actions or Dependent Actions. I do not have to worry about cluttering up my NA list, because the system can differentiate between Next Actions and Dependent Actions. And the system can allow me to view only my NAs, if that is what I want.
The system is very sophisticated because it allows me to create both many-to-one and one-to-many dependency relations. In the Shed example, many actions—installing the North, East, South, and West posts—depend on the one action of installing the base. And one action—installing the roof—depends on the many actions of installing the North, East, South, and West posts.
When I use the NA list in Achieve Planner, at first the only NA is “Install base.” When that’s completed, the four posts appear, all as NAs. When all four posts are marked complete, “Install roof” appears as a NA.
I used to feel frustrated. When I was planning a project I would usually put the plan in a “notes” section of the project because I didn’t want to clutter up my NA list. If I worked on a project, when I ended, I had to go to the notes section to find the new NA and add it to my NA list. The alternative was to cheat and put dependent actions on the NA list. It always bothered me that my software required me to manually transfer the same item from a project plan to a Next Action list.
Now, when I create a project, I create dependent actions the same way that I create next actions. They are all items under the project. But, if an action is dependent on other actions, I enter the action’s predecessor actions into my system. Then, when it’s time to do, I work off of my NA list. As soon as I mark my NA complete, the system removes that old NA from view and shows me the new NA.
I have gone into all this detail because I have found it a pleasure to work like this. It it much more productive to work this way and that is what GTD is all about.
Sometimes I would cheat and have many actions on my NA list:
Install base
Install North post
Install East post
Install South post
Install West post
Install roof
Only “Install base” is a NA, since none of the other actions can be done until the base is installed. The order in which the four posts are installed is not important. Any of the posts can be installed once the base is installed. So, once the base is installed, all four post actions are NAs. The roof cannot be installed until all four posts are installed.
Rigorous GTD states that I should have only “Install base” on my NA list. Then, when the base has been installed, I can put only the four post actions on my NA list. Then, when all four posts are up, I can put “Install roof” on my NA list.
I would sometimes cheat, and put all the actions on my NA list, because, for simple projects, I didn’t want to put the project plan in a separate place from my NA list. Although the projects were simple, they were complex enough that I did want a plan that told me what to do after each stage was completed.
If I were doing GTD on paper, I would review my NA list, see the “Install base” NA, then find the “Shed built” project plan and start working off the project plan. What I would like to do is avoid having to look at two lists: NA list and Project Plan.
If I were doing GTD electronically, I still have the same problem with most systems. Most systems do not differentiate between Next Actions and dependent actions.
The system I currently use, Achieve Planner, has recently updated so that I can now plan my shed and, with the click of a mouse, view either my Next Actions only, or my full Project Plans. (I have no financial interest in Achieve Planner other than being a satisfied customer.) This means that I put actions under projects, whether the actions are Next Actions or Dependent Actions. I do not have to worry about cluttering up my NA list, because the system can differentiate between Next Actions and Dependent Actions. And the system can allow me to view only my NAs, if that is what I want.
The system is very sophisticated because it allows me to create both many-to-one and one-to-many dependency relations. In the Shed example, many actions—installing the North, East, South, and West posts—depend on the one action of installing the base. And one action—installing the roof—depends on the many actions of installing the North, East, South, and West posts.
When I use the NA list in Achieve Planner, at first the only NA is “Install base.” When that’s completed, the four posts appear, all as NAs. When all four posts are marked complete, “Install roof” appears as a NA.
I used to feel frustrated. When I was planning a project I would usually put the plan in a “notes” section of the project because I didn’t want to clutter up my NA list. If I worked on a project, when I ended, I had to go to the notes section to find the new NA and add it to my NA list. The alternative was to cheat and put dependent actions on the NA list. It always bothered me that my software required me to manually transfer the same item from a project plan to a Next Action list.
Now, when I create a project, I create dependent actions the same way that I create next actions. They are all items under the project. But, if an action is dependent on other actions, I enter the action’s predecessor actions into my system. Then, when it’s time to do, I work off of my NA list. As soon as I mark my NA complete, the system removes that old NA from view and shows me the new NA.
I have gone into all this detail because I have found it a pleasure to work like this. It it much more productive to work this way and that is what GTD is all about.