This is a great venture. I am trying to capture the way I have implemented by GTD system. I am not very organized to tell exactly how the system works for me. I would capture things that catches my attention. Then I may go into the details.
I have defined collection baskets. These are places I get my "thoughts". Outlook is my main collection tool. I get mails I need to process. I have tried many different ways in the past to have a leak proof collection system. Initially I was using "Thinking Rocks" 'F6' collection. I got to know with experience this is duplication. I get my actions in Outlook; then I have to duplicate it to TR. This has the advantage that; I could process all my thoughts at once. In a long run it failed and really ruined my GTD system. Hence I currently use TR's collection just to capture ideas/things that pops up in my mind during a days work.
In Outlook; I forwards mails to myself by setting the category as 'THOUGHTS'. I have also created a simple rule mentioning that all the mail with that category get into the 'THOUGHTS' folder. As I process it, I delete the mail. I am safe, since the original mail is not lost.
Other places I get my todo's are from our bug tracker system, meetings and other telephone calls. All those are mailed to myself or captured in TR.
Once in a while I process all the thoughts collected. While processing the thoughts I create projects and actions. TR offers a good way to filter activities. I go each next actions and complete it. Finally I review the projects and add subsequent actions if required.
One problem I often get into is that, I haven't developed the habit of relying my processing system completly. This is the hurdle which I am overcoming now. I look at Outlook for the tasks I need to do. Obviously it takes slight amount of time to determine what to do. This could be avoided fully if I have a trusted system. Some day I plan to write how to build a trusty system; once I manage to create one.
The weakest link in my processing is the 'WAITING' actions and 'DELEGATED' actions. It is quite difficult to follow it up.
This write up is no where near to completion. But this is what is in my mind now. Perhaps on an another day, I can describe it little better.
Thursday, September 27, 2007
Wednesday, September 26, 2007
GTD way of writing ..
I was thinking I would start writing first experiences with GTD. But there are many things flashing my mind currently that I am getting distracted with those thoughts. I will put down what is in mind currently before venturing to my past days.
Today Morning, as I was walking I was thinking of a problem I am facing with GTD with the delegated tasks. This is a very tricky one to me. I am interested how others handle this.
To start with you have a task to Delegate. You don't want to define the next actions for that. In this case; ideal thing would be delegate this task and set a follow up date and forget it. But what if you want to track the progress. You have to create a next action just for follow up. This could be a meeting or a mail sent for update. I feel the overhead for this is little high. Your system is getting clogged with lot of small tasks. Is there a better way?
I started thinking how I am handling now. This is surely a hole in my system. Remember, when it comes to delegated tasks I am not at my best. Here is the step by step things I do today.
1. Create a desired outcome for the delegated task, and set context as "review".
2. Set a due date I would like to follow up.
There is big problem with this. I am trying to define a next action for a delegated task. This is not good.
I tried another workaround.
1. Create a delegated task.
2. Set a follow up date.
3. In the notes field (I am using Thinking Rock) I would put the desired outcome for that follow update. The desired out come will be a obvious one to the concerned parties or it is mutually agreed.
This approach seems to be fine. I could look at the notes and see that things are on track. Does anybody has a better approach ?
Also, I have come across yet another issue with my GTD implementation. This esp with "mail context" task. I would have a next action to mail somebody. After mailing I would expect I could mark the action done. But very often the mail is some clarification I require. The other person may not be in a position to clarify my question. My task gets into a idle state. I cannot proceed. If it is on the same day; I could remember. But usually such things gets spilled to the next days. For tracking such tasks; a "@ followup" tasks has to be created . This is a overhead of maintaing a GTD system (with any other system per se). I haven't got a break through in this. Currenly I create a follow up task. One idea could be change the context, after you send the mail. Example, after mailing, the context will change from "mail" to "waiting" or "followup".
Today Morning, as I was walking I was thinking of a problem I am facing with GTD with the delegated tasks. This is a very tricky one to me. I am interested how others handle this.
To start with you have a task to Delegate. You don't want to define the next actions for that. In this case; ideal thing would be delegate this task and set a follow up date and forget it. But what if you want to track the progress. You have to create a next action just for follow up. This could be a meeting or a mail sent for update. I feel the overhead for this is little high. Your system is getting clogged with lot of small tasks. Is there a better way?
I started thinking how I am handling now. This is surely a hole in my system. Remember, when it comes to delegated tasks I am not at my best. Here is the step by step things I do today.
1. Create a desired outcome for the delegated task, and set context as "review".
2. Set a due date I would like to follow up.
There is big problem with this. I am trying to define a next action for a delegated task. This is not good.
I tried another workaround.
1. Create a delegated task.
2. Set a follow up date.
3. In the notes field (I am using Thinking Rock) I would put the desired outcome for that follow update. The desired out come will be a obvious one to the concerned parties or it is mutually agreed.
This approach seems to be fine. I could look at the notes and see that things are on track. Does anybody has a better approach ?
Also, I have come across yet another issue with my GTD implementation. This esp with "mail context" task. I would have a next action to mail somebody. After mailing I would expect I could mark the action done. But very often the mail is some clarification I require. The other person may not be in a position to clarify my question. My task gets into a idle state. I cannot proceed. If it is on the same day; I could remember. But usually such things gets spilled to the next days. For tracking such tasks; a "@ followup" tasks has to be created . This is a overhead of maintaing a GTD system (with any other system per se). I haven't got a break through in this. Currenly I create a follow up task. One idea could be change the context, after you send the mail. Example, after mailing, the context will change from "mail" to "waiting" or "followup".
Tuesday, September 25, 2007
Implementing the GTD system - Part I
I started my trials with GTD around in April 2007. It is almost 5 months I am trying different ways to get a leak proof GTD system. I have tested quite many tools in these days trying to figure out the one which suits me the best. Though there are many tools in the net, I found "Thinking Rock" more suitable one.
After using this for more than 5 months; I have come to a conclusion that tools doesn't matter a lot to implement an effective GTD system. You can in your capacity implement GTD in many ways, with or with out any software tools. But I am a software professional, I spend most of my time with the computer.
I started implemented GTD with out reading David Allen's "Getting Things Done" book. I falied miserbly after few weeks of implementing GTD. But my belief on the methodology kept me trying again and again.
I had my first GTD system running few weeks; before it rusted and become obsolete. By that time I got "Getting Things Done" book; and it stresses about the importance of a trusted system. Initially I didn't understand it correctly. But to build a trusted system it is a huge effort. It requires constant maintenance. Even today; I cannot claim I have a trusted system. When I did a Root Cause Anaylsis (RCA) study on why my first implementation failed; I observed that I had a good collection habit but a very poor processing habit. As a reason the thoughts got piled up and with "Thinking Rock" it is FIFO. My immediate tasks had to be processed and due to th e huge pile; I never processed it. The pile simply become obsolete and difficult to maintain. The "trustworthiness" of the system is lost.
Another reason; I could see is failing to define what thoughts are. I thought "thoughts" are todo items. To some extent it is correct. But it doesn't mean that I have to empty all the items in various collection buckets into one and start processing. This has high duplication and bit boring. I got most of my tasks from my email client - 'Outlook'. I started putting things from Outlook into Thinking Rock. In this process I had to sync Outlook with Thinking rock manually. Then start processing to create actions.
So the workflow is something like
1. Collect all the tasks as 'thoughts' into Thinking Rock.
2. Process all the Thoughts from Thinking Rock into Actions & Projects
I could have directly converted things from outlook to action and projects in Thinking Rock. I failed to understand it. My processing took time and effort and finally broke.
Reason 2
The next biggest reason I failed is not defining next action correctly. I may say that I didn't understood the meaning of next action correctly. I never thought next action is next smallest iota of work that can proceed the project to completion. Instead I entered vague title of tasks as next action; which is not clear what to do next. The real task of 'doing things' failed here. I had to think what to do in the next action.
Reason 3
Review. Review was almost missing from my system. Also, here I misunderstood what to be reviewed. It should be "todo" items. I was always reviewing "done" things to make sure there is no action left any more. I didn't reviewed 'todo' items. Daily review or Weekly review was not part of the process.
Reason 4
Failure to update regularly. I was often caught in very important tasks; where it was obvious what the next action is. (Atleast I thought I knew it). For this reason I had lot of overdue actions and obsolete items. It became a burden. I thought of deleting some times. But the fear that I will loose somethings always prevented me from doing it.
There could be few other reasons it might have failed. I can conclude that all the above ones failed from creating a 'trustworthy' system to rely.
I also realized that it is a great effort to have a trustworthy system for a long time. It requires constant attention and effort to keep it updated. Also, this is the foundation of a good GTD system. The problem of this system is; it gets rusted very very soon.
In the coming blogs; I will deal more about the lessons I learned from my first implementatuion. Also; I would also mention how my current system looks like; and what I think of an ideal solution it.
After using this for more than 5 months; I have come to a conclusion that tools doesn't matter a lot to implement an effective GTD system. You can in your capacity implement GTD in many ways, with or with out any software tools. But I am a software professional, I spend most of my time with the computer.
I started implemented GTD with out reading David Allen's "Getting Things Done" book. I falied miserbly after few weeks of implementing GTD. But my belief on the methodology kept me trying again and again.
I had my first GTD system running few weeks; before it rusted and become obsolete. By that time I got "Getting Things Done" book; and it stresses about the importance of a trusted system. Initially I didn't understand it correctly. But to build a trusted system it is a huge effort. It requires constant maintenance. Even today; I cannot claim I have a trusted system. When I did a Root Cause Anaylsis (RCA) study on why my first implementation failed; I observed that I had a good collection habit but a very poor processing habit. As a reason the thoughts got piled up and with "Thinking Rock" it is FIFO. My immediate tasks had to be processed and due to th e huge pile; I never processed it. The pile simply become obsolete and difficult to maintain. The "trustworthiness" of the system is lost.
Another reason; I could see is failing to define what thoughts are. I thought "thoughts" are todo items. To some extent it is correct. But it doesn't mean that I have to empty all the items in various collection buckets into one and start processing. This has high duplication and bit boring. I got most of my tasks from my email client - 'Outlook'. I started putting things from Outlook into Thinking Rock. In this process I had to sync Outlook with Thinking rock manually. Then start processing to create actions.
So the workflow is something like
1. Collect all the tasks as 'thoughts' into Thinking Rock.
2. Process all the Thoughts from Thinking Rock into Actions & Projects
I could have directly converted things from outlook to action and projects in Thinking Rock. I failed to understand it. My processing took time and effort and finally broke.
Reason 2
The next biggest reason I failed is not defining next action correctly. I may say that I didn't understood the meaning of next action correctly. I never thought next action is next smallest iota of work that can proceed the project to completion. Instead I entered vague title of tasks as next action; which is not clear what to do next. The real task of 'doing things' failed here. I had to think what to do in the next action.
Reason 3
Review. Review was almost missing from my system. Also, here I misunderstood what to be reviewed. It should be "todo" items. I was always reviewing "done" things to make sure there is no action left any more. I didn't reviewed 'todo' items. Daily review or Weekly review was not part of the process.
Reason 4
Failure to update regularly. I was often caught in very important tasks; where it was obvious what the next action is. (Atleast I thought I knew it). For this reason I had lot of overdue actions and obsolete items. It became a burden. I thought of deleting some times. But the fear that I will loose somethings always prevented me from doing it.
There could be few other reasons it might have failed. I can conclude that all the above ones failed from creating a 'trustworthy' system to rely.
I also realized that it is a great effort to have a trustworthy system for a long time. It requires constant attention and effort to keep it updated. Also, this is the foundation of a good GTD system. The problem of this system is; it gets rusted very very soon.
In the coming blogs; I will deal more about the lessons I learned from my first implementatuion. Also; I would also mention how my current system looks like; and what I think of an ideal solution it.
Subscribe to:
Posts (Atom)