gtdstudente
Registered
UltravioletQueso, Great post and perhaps one can agree that it is times like this that one can thank the good Lord for GTD?
Do you set all next actions when project planning or just THE next action
- Thread starter ivanjay205
- Start date
I agree with Gardener, this is multiple projects, which opens up two of the most overlooked (IMO) aspects of GTD, time available and energy levels.
You might start the day aiming to work on the event, but daily demands interfere and you get to the end of the day having completed none of your aims, but you have a small 10-20 minute window in which you can achieve something.
You’re not going to work on your presentation which is a high energy and high time demand task, but you could do something towards the invites or choosing the food, which are low energy and low time demands.
By having these as separate projects you only look at the next action for a project that you know you have the time and energy for.
For me it would be easier to manage as separate projects. Different projects call for different amounts of planning and support materials. Distinct projects would mean you could move each one forward at its own pace.
It seems to me that if you keep separate project and next action lists, there’s not much difference between one project or separate projects. On the other hand, most of the apps that list next actions as part of projects also have subprojects, so not much difference there either. However, if multiple projects helps you keep track, why not? In the case at hand, I would go no further than two projects, one for meeting mechanics and one for content I need to prepare.
Quicksilver10
Simon PN
Dear UltravioletQueso, The section in Getting Things Done the book on the Natural Planning Model mentions setting a number of next actions for a project at once, where it is a larger project having a number of "moving parts", and where you can set a Next Action for each moving part . It gives an example similar to yours. I agree with the advice given above that in your case the "moving parts" are best handled as separate projects, but for further insights on which way to go on this, you could refer to the section headed "What about Subprojects" in Chapter 7 of the book. I guess that, as others have indicated, and regardless of whether the Next Actions are in separate projects or one big project, choosing which one to do would depend on the usual criteria, including context.
Last edited:
gtdstudente
Registered
Quicksilver10, While also respectfully understanding one is unable 'to do' a "Protect" . . . and is instead 'only' a series of "Next Action(s)" to complete 'the' "Project". Perhaps this is why in a somewhat 'mysterious' way "Next Actions" are their own set relative Objective Realities in regards to any "Project." In other words, the "Next Action's" job is to complete the "Next Action" as best as possible and at the juncture where the "Next Action" kind of has an intention of its own regardless of what "Project" is that it is serving and thus 'deemed' irrelevant. Thus, on a Practical Level, the "Next Action" List and the "Project" List are their own separate 'living' realities who confer/get-together during the "Weekly Review" to remain on the 'same-page' to continue building their trust with each other for Project building?
Last edited:
seedgrumble
Registered
If you already know the next actions of a project because you have seen a repeated pattern in the past, how will you put them in the next action?
For example, often I return items I buy online to get the refund. So one of my projects is: Return and refund on Item X from Amazon. I have found these are the steps that I need to follow sequentially every time within certain context.
For example, often I return items I buy online to get the refund. So one of my projects is: Return and refund on Item X from Amazon. I have found these are the steps that I need to follow sequentially every time within certain context.
- Request for an RMA. @computer
- Get the RMA. @email
- Pack the item with the RMA and the shipping Label. @home
- Drop off the item. @errands
- Receive the refund. @email
Last edited:
René Lie
Certified GTD Trainer
First of all, number 2 and 5 looks like "waiting for" to me.
Then, there's no one who says that you have to wait until your next weekly review before identyfing the next action. The weekly review is more like a "safety net" in this regard, ensuring that you at least once a week revisit your project, making sure that you have a next action on your project.
I often find myself, upon completion of a next action tied to a project, looking at the project list to see if I can activate or identify a next action for the project.
Last edited:
The article you cite says:
This means that those next actions should not be visible to you as next actions because they aren’t next. Many people like to use apps which connect next actions, possible future actions and projects in some way, e.g., Omnifocus, but that is not the only way to do GTD. However, your particular example of a return to Amazon would make a great checklist, which GTD embraces as a way to handle a frequently repeated sequence of steps.
gtdstudente
Registered
René Lie,
Weekly Review . . . "safety net" . . . GTD bammm . . . spot on . . . thank you!
Last edited:
The beauty of GTD is that it is so subjective and not dictatorial in its approach, add to that it is system/tool agnostic and you have a lovely conundrum of many ways to achieve outcomes.
I think Program Mgt is a little used term that could help. A few years ago I was managing a sizeable project of being accountable for the IT infrastructure of a new building for an organisation that was moving three separate offices into one new one. There were significant projects like
- relocating three server rooms into one outsourced data centre
- designing and implementing network for new building
- decommissioning old building networks
- creating new managed print service for the organisation
…and many more.
At the time I was reporting to the CFO and he wanted to know how I (and my team) was going. So I took a program mgt approach. Each week I had a simple one paper showing the status of each project under the heading of ‘Moving <orgname> to new building. This allowed me to report at a high level by program and yet manage at a project level. I also had many other projects on the go outside of this program for the new build. So I organised those into various programs of Application Support, Application design etc. It made it easier for reporting only a small number of programs as opposed to many many projects. Easier for reporting up and also for keeping my team informed
I think Program Mgt is a little used term that could help. A few years ago I was managing a sizeable project of being accountable for the IT infrastructure of a new building for an organisation that was moving three separate offices into one new one. There were significant projects like
- relocating three server rooms into one outsourced data centre
- designing and implementing network for new building
- decommissioning old building networks
- creating new managed print service for the organisation
…and many more.
At the time I was reporting to the CFO and he wanted to know how I (and my team) was going. So I took a program mgt approach. Each week I had a simple one paper showing the status of each project under the heading of ‘Moving <orgname> to new building. This allowed me to report at a high level by program and yet manage at a project level. I also had many other projects on the go outside of this program for the new build. So I organised those into various programs of Application Support, Application design etc. It made it easier for reporting only a small number of programs as opposed to many many projects. Easier for reporting up and also for keeping my team informed
Request the RMA is the only completable NA on that list so should be the only one on your list.
I’m not clear what the action is that you describe as Get the RMA, but to my mind that should be “RMA received?” and goes on your waiting for list.
When the RMA is received then that’s the trigger for adding the 3.Pack with RMA… to your NA list or simply do it. If you need to consult your project support to identify what action 3 is then this is the point that you would do this, not during the Weekly Review.
Once packed you move onto 4 which goes on your Errands list, again consulting your project support if you really need to, to identify this NA.
5. is a @waiting for list item, which when received is project complete.
DK
ivanjay205
Registered
Personally, I have OmniFocus setup with a sequential project. I add all of them to my list, even the waiting for items. As one is checked off the next one appears. However, they are hidden from view until that first one is complete so it works well for me.
Serendipity is such a wonderful thing. Today on my walk I was looking for a podcast to listen to. I happened to choose a GTD Virtual Study Group cast called Horizons of Focus from back in 2016. Currently I am having a detailed review of my HoF. To my amazement the concept of Programs that I mentioned in my reply above has already been discussed by the wonderful Ray Sidney Smith in his blog post here, entitled ‘15000 feet: The space between projects and Areas of Focus and Responsibility’. A very interesting view and might help this discussion.
Thanks for the link. The idea of Programs at 15,000 feet in between projects and areas is interesting. In the past, I conceptualized certain ongoing responsibilities too small to be an area but not projects as lying at 15,000 feet (or level 1.5 in the less evocative newer terminology). What I find most interesting is the idea that Programs can and should grow. While obvious in hindsight, the conventional GTD description of Areas does emphasize maintenance, with evolution over time implicit in regular review of areas. I’m not using the 15,000 foot level much these days, but I do find the idea of growth, as opposed to maintenance and evolution, interesting to apply around the Areas level. By the way, the post was written by Mike Vardy, a fairly well-known productivity writer. Perhaps you found his work through Ray Sidney Smith, whom I had not encountered before.