SlideShare a Scribd company logo
1 of 2
larrinski
                                                                               09-12-2012, 10:25 AM
I've been a long time user of RTM for my GTD system. I love it for my personal life, but find that I use
a notebook a lot at work (Inbox/Notetaking), and would like to have a paper system for work, and use
RTM for personal.

The problem I have is that RTM is great with Tags, and my projects are saved Smart Lists with all the
Next Actions visible within the Project. I like the ability to see my tasks by context or by project.

My lack of understanding of the project list on paper keeps me from moving there. i.e.- I don't know if
all my projects and the next actions should be on the Project list page, or just the name of the project.
It seems that if I put the next actions nested within the project list, then re-write the next actions
within the context lists, I am doing double the work.

Maybe I'm answering my own question, but it seems like a digital solution (and RTM) works best for
not duplicating tasks on lists.

Help me understand how project lists on paper are supposed to work... :)


TesTeq
                                                                                   09-12-2012, 12:05 PM
I don't know if all my projects and the next actions should be on the Project list page, or just the
name of the project.

Project List is just a Project List - contains project names only.


It seems that if I put the next actions nested within the project list, then re-write the next actions
within the context lists, I am doing double the work.

Next Actions are on @context lists. No double work required. You can write down some Project actions
in the Project support file/notes if you are afraid that you will forget about something important.


johnaohman
                                                                                    09-12-2012, 12:19 PM
So a few areas of comment here:

1). I believe that technically, the original description by DA on this issue was that the Project List only
really needed to contain the project name (+/- a description of what the successful outcome looked
like). The idea was that all you really needed to do was identify the very first "next action" and put
that on your Next Actions context list(s). When you completed that one, you could then identify what
the next sequential action was and put that one on your Next Actions list .. .. and so on and so forth
until the project was completed. The weekly review would help identify any active projects for which a
current, uncompleted Next Action wasn't in your system. For those projects where not all actions are
strictly sequential, you could certainly create Next Action items for the parallel steps, but for the
sequential steps, really only the very next step needed to get onto your Next Actions list(s).

2). However, if you're like me (and it sounds like you are), I like to take a project and "plan out"
most, if not all, the steps needed to complete it. For me, it gives me a much clearer picture of just
how big this initiative is going to be and how much resource (mine own and others) will be required.
But, if you're going to approach it that way, you might end up with Actions that aren't really Next
Actions because later sequential steps would require that previous steps be completed first. If, on the
other hand, your Project List contains the nested action steps, and your Next Action list(s) contain
only true next actions, you do, indeed, end up writing these things down twice in a paper system.
That's one of the reasons that I, personally, choose to use a digital system. So my use of paper vs
digital is the opposite of what you're contemplating - rather than move to a paper actions system to
accomodate your paper note-taking/inbox, I choose to use a digital note-taking/inbox to accomodate
my digital actions system.

3). Either way, the issue of linking actions to projects has been the subject of many, many discussions
here. Some say you don't need to do that at all, while others (myself included) feel that it's desirable.
Easy to do with most digital systems - somewhat harder on paper, although various suggestions of
including the project name (or some project code) into the text of the Next Action item is adequate to
make the link if you want to have it.


larrinski
                                                                                    09-12-2012, 03:00 PM
So a few areas of comment here:

1). I believe that technically, the original description by DA on this issue was that the Project List only
really needed to contain the project name (+/- a description of what the successful outcome looked
like). The idea was that all you really needed to do was identify the very first "next action" and put
that on your Next Actions context list(s). When you completed that one, you could then identify what
the next sequential action was and put that one on your Next Actions list .. .. and so on and so forth
until the project was completed. The weekly review would help identify any active projects for which a
current, uncompleted Next Action wasn't in your system. For those projects where not all actions are
strictly sequential, you could certainly create Next Action items for the parallel steps, but for the
sequential steps, really only the very next step needed to get onto your Next Actions list(s).

2). However, if you're like me (and it sounds like you are), I like to take a project and "plan out"
most, if not all, the steps needed to complete it. For me, it gives me a much clearer picture of just
how big this initiative is going to be and how much resource (mine own and others) will be required.
But, if you're going to approach it that way, you might end up with Actions that aren't really Next
Actions because later sequential steps would require that previous steps be completed first. If, on the
other hand, your Project List contains the nested action steps, and your Next Action list(s) contain
only true next actions, you do, indeed, end up writing these things down twice in a paper system.
That's one of the reasons that I, personally, choose to use a digital system. So my use of paper vs
digital is the opposite of what you're contemplating - rather than move to a paper actions system to
accomodate your paper note-taking/inbox, I choose to use a digital note-taking/inbox to accomodate
my digital actions system.

3). Either way, the issue of linking actions to projects has been the subject of many, many discussions
here. Some say you don't need to do that at all, while others (myself included) feel that it's desirable.
Easy to do with most digital systems - somewhat harder on paper, although various suggestions of
including the project name (or some project code) into the text of the Next Action item is adequate to
make the link if you want to have it.

Thanks for the clarification. I never felt comfortable just naming my projects without fleshing out
action steps. A lot of my workflow is not necessarily sequencial. So if I have a project with @phone,
@computer, @agenda, they may go in any order. Waiting for a weekly review seems so long term.
Being in banking/lending, many of my clients are done in only a few days. But I may need to deal with
a bunch of different actions within the project. So it is nice to be able to review the remaining steps I
need to take within the project.
I think I'll just stay with RTM. It works so well. :)

More Related Content

Similar to Larrinski

An overview of my PhD research
An overview of my PhD researchAn overview of my PhD research
An overview of my PhD researchFelienne Hermans
 
Top Three Data Modeling Tools Usability Comparsion
Top Three Data Modeling Tools Usability ComparsionTop Three Data Modeling Tools Usability Comparsion
Top Three Data Modeling Tools Usability ComparsionErin
 
Top Three Data Modeling Tools Usability Comparsion
Top Three Data Modeling Tools Usability ComparsionTop Three Data Modeling Tools Usability Comparsion
Top Three Data Modeling Tools Usability ComparsionErin
 
CTTS CASE STUDY - Milestone 2 Problem AnalysisPage 2-7MILEST.docx
CTTS CASE STUDY - Milestone 2 Problem AnalysisPage 2-7MILEST.docxCTTS CASE STUDY - Milestone 2 Problem AnalysisPage 2-7MILEST.docx
CTTS CASE STUDY - Milestone 2 Problem AnalysisPage 2-7MILEST.docxannettsparrow
 
Choose Boring Technology
Choose Boring TechnologyChoose Boring Technology
Choose Boring TechnologyDan McKinley
 
INTRODUCTION TO Database Management System (DBMS)
INTRODUCTION TO Database Management System (DBMS)INTRODUCTION TO Database Management System (DBMS)
INTRODUCTION TO Database Management System (DBMS)Prof Ansari
 
Recommendation systems
Recommendation systemsRecommendation systems
Recommendation systemsAnton Ermak
 
Demystifying dot NET reverse engineering - Part1
Demystifying  dot NET reverse engineering - Part1Demystifying  dot NET reverse engineering - Part1
Demystifying dot NET reverse engineering - Part1Soufiane Tahiri
 
“Don’t Repeat Yourself”: 4 Process Street Features to Keep Work DRY
“Don’t Repeat Yourself”: 4 Process Street Features to Keep Work DRY“Don’t Repeat Yourself”: 4 Process Street Features to Keep Work DRY
“Don’t Repeat Yourself”: 4 Process Street Features to Keep Work DRYLizzyManz
 
معرفی زبان مدلسازی Archimate 2
معرفی زبان مدلسازی Archimate 2معرفی زبان مدلسازی Archimate 2
معرفی زبان مدلسازی Archimate 2Amir Darajeh
 
Remote First Team Collaboration Tool
Remote First Team Collaboration ToolRemote First Team Collaboration Tool
Remote First Team Collaboration ToolJessica Arevalo
 
Software Requirement Analysis and Thinking Process towards a good Architecture
Software Requirement Analysis and Thinking Process towards a good ArchitectureSoftware Requirement Analysis and Thinking Process towards a good Architecture
Software Requirement Analysis and Thinking Process towards a good Architecturemahmud05
 
Experimenting With Big Data
Experimenting With Big DataExperimenting With Big Data
Experimenting With Big DataNick Boucart
 
Meeting Questions and Answers:
Meeting Questions and Answers:Meeting Questions and Answers:
Meeting Questions and Answers:butest
 
Big data and hadoop ecosystem essentials for managers
Big data and hadoop ecosystem essentials for managersBig data and hadoop ecosystem essentials for managers
Big data and hadoop ecosystem essentials for managersManjeet Singh Nagi
 
SharePoint Apps for the End User
SharePoint Apps for the End UserSharePoint Apps for the End User
SharePoint Apps for the End UserRegroove
 

Similar to Larrinski (20)

Smart Housekeeping Apps
Smart Housekeeping AppsSmart Housekeeping Apps
Smart Housekeeping Apps
 
BusinessIntelligence
BusinessIntelligenceBusinessIntelligence
BusinessIntelligence
 
An overview of my PhD research
An overview of my PhD researchAn overview of my PhD research
An overview of my PhD research
 
Top Three Data Modeling Tools Usability Comparsion
Top Three Data Modeling Tools Usability ComparsionTop Three Data Modeling Tools Usability Comparsion
Top Three Data Modeling Tools Usability Comparsion
 
Top Three Data Modeling Tools Usability Comparsion
Top Three Data Modeling Tools Usability ComparsionTop Three Data Modeling Tools Usability Comparsion
Top Three Data Modeling Tools Usability Comparsion
 
CTTS CASE STUDY - Milestone 2 Problem AnalysisPage 2-7MILEST.docx
CTTS CASE STUDY - Milestone 2 Problem AnalysisPage 2-7MILEST.docxCTTS CASE STUDY - Milestone 2 Problem AnalysisPage 2-7MILEST.docx
CTTS CASE STUDY - Milestone 2 Problem AnalysisPage 2-7MILEST.docx
 
Choose Boring Technology
Choose Boring TechnologyChoose Boring Technology
Choose Boring Technology
 
INTRODUCTION TO Database Management System (DBMS)
INTRODUCTION TO Database Management System (DBMS)INTRODUCTION TO Database Management System (DBMS)
INTRODUCTION TO Database Management System (DBMS)
 
Recommendation systems
Recommendation systemsRecommendation systems
Recommendation systems
 
On no sql.partiii
On no sql.partiiiOn no sql.partiii
On no sql.partiii
 
Demystifying dot NET reverse engineering - Part1
Demystifying  dot NET reverse engineering - Part1Demystifying  dot NET reverse engineering - Part1
Demystifying dot NET reverse engineering - Part1
 
“Don’t Repeat Yourself”: 4 Process Street Features to Keep Work DRY
“Don’t Repeat Yourself”: 4 Process Street Features to Keep Work DRY“Don’t Repeat Yourself”: 4 Process Street Features to Keep Work DRY
“Don’t Repeat Yourself”: 4 Process Street Features to Keep Work DRY
 
معرفی زبان مدلسازی Archimate 2
معرفی زبان مدلسازی Archimate 2معرفی زبان مدلسازی Archimate 2
معرفی زبان مدلسازی Archimate 2
 
Remote First Team Collaboration Tool
Remote First Team Collaboration ToolRemote First Team Collaboration Tool
Remote First Team Collaboration Tool
 
Software Requirement Analysis and Thinking Process towards a good Architecture
Software Requirement Analysis and Thinking Process towards a good ArchitectureSoftware Requirement Analysis and Thinking Process towards a good Architecture
Software Requirement Analysis and Thinking Process towards a good Architecture
 
Experimenting With Big Data
Experimenting With Big DataExperimenting With Big Data
Experimenting With Big Data
 
Meeting Questions and Answers:
Meeting Questions and Answers:Meeting Questions and Answers:
Meeting Questions and Answers:
 
Big data and hadoop ecosystem essentials for managers
Big data and hadoop ecosystem essentials for managersBig data and hadoop ecosystem essentials for managers
Big data and hadoop ecosystem essentials for managers
 
Sp apps for the end user 2013-08-15
Sp apps for the end user 2013-08-15Sp apps for the end user 2013-08-15
Sp apps for the end user 2013-08-15
 
SharePoint Apps for the End User
SharePoint Apps for the End UserSharePoint Apps for the End User
SharePoint Apps for the End User
 

Larrinski

  • 1. larrinski 09-12-2012, 10:25 AM I've been a long time user of RTM for my GTD system. I love it for my personal life, but find that I use a notebook a lot at work (Inbox/Notetaking), and would like to have a paper system for work, and use RTM for personal. The problem I have is that RTM is great with Tags, and my projects are saved Smart Lists with all the Next Actions visible within the Project. I like the ability to see my tasks by context or by project. My lack of understanding of the project list on paper keeps me from moving there. i.e.- I don't know if all my projects and the next actions should be on the Project list page, or just the name of the project. It seems that if I put the next actions nested within the project list, then re-write the next actions within the context lists, I am doing double the work. Maybe I'm answering my own question, but it seems like a digital solution (and RTM) works best for not duplicating tasks on lists. Help me understand how project lists on paper are supposed to work... :) TesTeq 09-12-2012, 12:05 PM I don't know if all my projects and the next actions should be on the Project list page, or just the name of the project. Project List is just a Project List - contains project names only. It seems that if I put the next actions nested within the project list, then re-write the next actions within the context lists, I am doing double the work. Next Actions are on @context lists. No double work required. You can write down some Project actions in the Project support file/notes if you are afraid that you will forget about something important. johnaohman 09-12-2012, 12:19 PM So a few areas of comment here: 1). I believe that technically, the original description by DA on this issue was that the Project List only really needed to contain the project name (+/- a description of what the successful outcome looked like). The idea was that all you really needed to do was identify the very first "next action" and put that on your Next Actions context list(s). When you completed that one, you could then identify what the next sequential action was and put that one on your Next Actions list .. .. and so on and so forth until the project was completed. The weekly review would help identify any active projects for which a current, uncompleted Next Action wasn't in your system. For those projects where not all actions are strictly sequential, you could certainly create Next Action items for the parallel steps, but for the sequential steps, really only the very next step needed to get onto your Next Actions list(s). 2). However, if you're like me (and it sounds like you are), I like to take a project and "plan out" most, if not all, the steps needed to complete it. For me, it gives me a much clearer picture of just how big this initiative is going to be and how much resource (mine own and others) will be required. But, if you're going to approach it that way, you might end up with Actions that aren't really Next Actions because later sequential steps would require that previous steps be completed first. If, on the other hand, your Project List contains the nested action steps, and your Next Action list(s) contain only true next actions, you do, indeed, end up writing these things down twice in a paper system. That's one of the reasons that I, personally, choose to use a digital system. So my use of paper vs digital is the opposite of what you're contemplating - rather than move to a paper actions system to accomodate your paper note-taking/inbox, I choose to use a digital note-taking/inbox to accomodate
  • 2. my digital actions system. 3). Either way, the issue of linking actions to projects has been the subject of many, many discussions here. Some say you don't need to do that at all, while others (myself included) feel that it's desirable. Easy to do with most digital systems - somewhat harder on paper, although various suggestions of including the project name (or some project code) into the text of the Next Action item is adequate to make the link if you want to have it. larrinski 09-12-2012, 03:00 PM So a few areas of comment here: 1). I believe that technically, the original description by DA on this issue was that the Project List only really needed to contain the project name (+/- a description of what the successful outcome looked like). The idea was that all you really needed to do was identify the very first "next action" and put that on your Next Actions context list(s). When you completed that one, you could then identify what the next sequential action was and put that one on your Next Actions list .. .. and so on and so forth until the project was completed. The weekly review would help identify any active projects for which a current, uncompleted Next Action wasn't in your system. For those projects where not all actions are strictly sequential, you could certainly create Next Action items for the parallel steps, but for the sequential steps, really only the very next step needed to get onto your Next Actions list(s). 2). However, if you're like me (and it sounds like you are), I like to take a project and "plan out" most, if not all, the steps needed to complete it. For me, it gives me a much clearer picture of just how big this initiative is going to be and how much resource (mine own and others) will be required. But, if you're going to approach it that way, you might end up with Actions that aren't really Next Actions because later sequential steps would require that previous steps be completed first. If, on the other hand, your Project List contains the nested action steps, and your Next Action list(s) contain only true next actions, you do, indeed, end up writing these things down twice in a paper system. That's one of the reasons that I, personally, choose to use a digital system. So my use of paper vs digital is the opposite of what you're contemplating - rather than move to a paper actions system to accomodate your paper note-taking/inbox, I choose to use a digital note-taking/inbox to accomodate my digital actions system. 3). Either way, the issue of linking actions to projects has been the subject of many, many discussions here. Some say you don't need to do that at all, while others (myself included) feel that it's desirable. Easy to do with most digital systems - somewhat harder on paper, although various suggestions of including the project name (or some project code) into the text of the Next Action item is adequate to make the link if you want to have it. Thanks for the clarification. I never felt comfortable just naming my projects without fleshing out action steps. A lot of my workflow is not necessarily sequencial. So if I have a project with @phone, @computer, @agenda, they may go in any order. Waiting for a weekly review seems so long term. Being in banking/lending, many of my clients are done in only a few days. But I may need to deal with a bunch of different actions within the project. So it is nice to be able to review the remaining steps I need to take within the project. I think I'll just stay with RTM. It works so well. :)