SoftwareGuy;43978 said:
After doing GTD for a while, I fell off the wagon. In the process of getting back on, I started to seriously question how effective GTD really is.
I have had this same experience. In my analysis of my experience with GTD as well as the most-frequently-posted-problems (here and elsewhere), I decided that GTD's greatest strengths were in the areas in which it is most explicit and concrete -- the phases "Collect" and "Process." The "Process" algorithm, in particular, is a gem that, all by itself, greatly improved my productivity and peace of mind.
The "Organize" phase of GTD I found to be helpful in some ways but to complicate things in other ways. For example, "How do I link projects with their Next Actions" is a FAQ. In my experience, it was critical that I find a way to get the benefits of this organizing but to do so more efficiently.
Streamlining the overhead of organizing, for me, is all about tool choice. It is often said that GTD does not care what tool(s) you use, but it does not follow that you can equally efficiently use
any tool. If you have a lot of nails to drive, it's critical to choose a nailgun rather than a hammer. Personally, I abandoned vanilla Palm for
long lists of projects and NAs. There are tools that IMO require far less attention from me.
The phases "Do" and "Review" are, for me, the phases of GTD that required additions and modifications (YMMV). The first weakness here is prioritizing, another FAQ. I do not work best from a long list of unprioritized NAs which I then must choose from intuitively on the fly. (However, I imagine that for people with packed calendars, these lists could be spectacularly successful.) I solved my priority problem 1) by using a tool that reasonably prioritizes NAs with a useful algorithm, and 2) by scheduling blocks of time for tasks/projects that require them, as discussed in this thread already.
Julie Morgenstern's time management book has useful scheduling strategies that I integrated with these phases of GTD. For example, she emphasizes the concept of knowing
how long it takes to complete tasks. Say you have 200 NAs on your various lists and estimate that it will take 100 hours to complete them. And you have 50 projects that will take an estimated 3 months to complete. So altogether you have about 4 months of work in the system now. Knowing explicitly how much time you have already committed is a great reality check to prevent you from taking on more commitments.
The second problem I had with "Do" was procrastination. GTD (the "Process" phase) spectacularly eliminated procrastination caused by lack of clarity about
what to do. (For example, having "Mom's birthday" on a ToDo list instead of a nice clear NA.) However,
perfectionistic procrastination really gummed up the works for me. There IS overhead in maintaining a GTD system (or probably any system), and if you don't have good throughput of your NAs, that overhead grows to epic proportions. You can't just keep adding, adding, adding projects and NAs.
You must find some equilibrium point where tasks entering the system are roughly equally to tasks leaving. This is an area that GTD doesn't necessarily address (perhaps assumes), but since it was a problem for me, I had to address it.
Finally, the problem I had with "Review" was simply that I did not like to do the Weekly Review as described in the book. It was a time-consuming pain in the rear for me (YMMV). Much of the review described in the book was to get the system up to date. I streamlined this by 1) using software to automate some of the process, and 2) updating more frequently. I now keep my system up to date pretty much continuously, as stuff happens, or during hectic times, at least once a day.
Those were my experiences and my thoughts about them. My advice to you based on what you've written in this thread:
1)
Long and growing lists: Growing lists indicate that either a) you aren't Doing tasks fast enough, or b) you are adding tasks too quickly, or both. To address b), hypothetically schedule everything on your current lists. Estimate the time for each task and project. Group related tasks efficiently and schedule blocks of time for them. Pencil this all in on weekly calendars until it's all scheduled. Leave reasonable amounts of time for things that might come at you each day. This is not a schedule to necessarily follow, but just to become
more explicitly aware of everything that's on your plate. If it's too much, or you have a gut feeling that certain things will never get done, renegotiate them (i.e., remove them from your lists somehow!). The goal here is to achieve an equilibrium state where you have a reasonable amount of stuff in the system, and inflow equals outflow. Keep renegotiating and filtering incoming tasks until you achieve equilibrium.
If you are not Doing tasks fast enough, then you need to find a way to get your procrastinating rear in gear, which is beyond this thread, but there are many other threads in the archives that may help.
2)
Different tool(s) and/or processes: Once you have reached that equilibrium state, if you still dislike the amount of overhead to maintain your system, then start looking for tools and processes to reduce your overhead. But it may be that being realistic about commitments you take on will keep them at a manageable scale without any change in tools.
