My frustration with personal productivity systems like GTD is that they’re all about projects and tasks. They leave out a third category: programs. GTD thinks of a project as something that can be broken into a manageable number of tasks and scratched off a list. But programs go on indefinitely and cannot be divided into a small number of one-time tasks.
I’m using the word “program” as in an “exercise program” or a “research program.” (I could think of my exercise program as a project, but it’s one I hope not to complete for a few more decades.) Sometimes there is a neat hierarchy where programs spawn off projects that can be divided into tasks. But sometimes you just have programs and tasks.
One of my frustrations with managing software development in an academic environment was the large number of programs disguised as projects. (Sorry, I know it’s confusing to talk about “programs” in the context of software development and not mean computer instructions.) You can’t manage programs as if they were projects. For example, you can’t talk about “after” project is done if it’s not really a project but a never-ending program. You have to either acknowledge that a program is really a program, or you have to have some way to make it into a finite project.
I think GTD does handle what you are calling “programs”, but you don’t see those in the ground-level task lists that usually get identified with GTD. Programs are typically handled by the Someday/Maybe list and by the extended review process, whereby every so often you pull back to a very high level and determine what large patterns of activity you would like to have in your life. These usually involve generalized personal goals — “be a better husband”, etc. — but could encompass the kinds of meta-projects you are describing.
There’s nothing preventing a person from maintaining a list of programs in a file somewhere, too, which you then break down into a collection of finite projects, which then break down into atomic tasks. One of the great strengths of GTD is that it’s not a religion that must be followed absolutely, but can be scaled up, scaled down, added to, or subtracted from and still retains the basic core idea of “What’s the next action?”
I’ve struggled with the nomenclature for these things. One peculiar friend calls them “industries”, making himself analogous to a country. I have called them “responsibilities”, but that doesn’t really make a clear indication of what the associated data structure ought to be.
I think “program” is good, because the word “program” has lost its value in the software world and can now be repurposed. The Apple word “app” captures what an end user things of as a software entity; real world apps are not single executables anymore. Even the verb “programming” and the job title “programmer” seem a bit fuzzy and out of date.
Right. Excellent point John.
Part of the problem with programs is that they are intrinsically fuzzy.
While I was initially excited by GTD many years ago, it failed for me for this reason too, as given an on-going sequence of mutually dependent, ambiguous tasks defined in terms of the success or failure of other tasks, there was no way to break down the big goals that matter into a series of next actions. I found myself often falling back on following my own intuition more than a set of rules. So IMHO GTD is yet another attempt to make management into a science, rather than acknowledge it as an art. Although after the management types solve the Halting problem, then I’d be willing to revisit GTD.
I agree with your sentiments John. I still think there is value in wrangling To Do lists (and, recently, have found The Hit List a very good application for mine) but they do not encompass the messy, unstructured nature of part of my research.
About the best you can do is take Polya’s approach and use the following items: (1) write down the problem; (2) think very hard; (3) write down the answer.
Some background: I only kind of use GTD, but I did find one of its core ideas very important: break things down into tasks so you can say they’re done. I would agree this isnt easy with everything, but its not impossible either. Sometimes merely the act of deconstructing a program or set of strategic goals can serve to better communicate them to our staff, our superiors and increase the likelihood that we will achieve any interim milestones.
I’ve also found that breaking my overall strategic goals down into monthly (revised monthly) then weekly goals (revised every Friday) with a recurring daily task to “review weekly/monthly goals” is quite a bit more effective than my older, more GTD based system of popping things from waiting to action and vice versa.