I just read a guest article by Ray Sidney-Smith on Mike Vardy’s Productivityist blog from Nov 2014. The title is:
15,000 Feet: The Space Between Projects and Areas of Focus and Responsibility
It’s probably best to read the whole article for context, but the basic concept (which I really like for the structure I am trying to create) is:
“A program solves for me the problem of a project that doesn’t fit the mold of GTD-defined project. (You can replace “program” with another term for 15,000 feet, but it was the best word I could find for my needs.) I needed to find a space between projects and my areas of focus and responsibility, and I settled for someplace in between.”
I am looking for a way to implement this Program in GTDNext, as the only levels offered are Area (which I understand can be interpreted broadly) and Project&Action. I was thinking of possibly using the list of Areas to define Programs (there are more Programs than AORs, so it might be a somewhat long list but still pretty manageable), and then placing an AOR Tag in each Project so that they can be “summoned” together under an AOR head when needed. Does anyone have any thoughts or suggestions that they could offer about this?
Great article. I can think of a couple of additional ways you could do this in GTDNext and there are probably more ways than that!
TAGS: You could create a tag for each program. Apply the tag only to the projects that comprise each program. Then by filtering by this tag you would be able to see all projects that are associated with this program.
Sub-Projects: You could make the Program a top level project and all projects that are part of this program would be sub-projects under the main “program”. In this case you might also consider adding a tag called “program” so you could filter your view to show only the projects that are acting as programs. Hope that makes sense.
I agree there is a big difference between projects and projects, as it were - or projects and “programs” as they are called here - or “real” projects and “tasks with subtasks”.
The way I have dealt with this is this: I simply have never accepted cluttering my projects list with “tasks with subtasks”. I usually use the app’s projects feature for more sizeable projects (think programs, if you like) and as AoR based containers for those actions that do not belong to a real project. But I keep all actions among the actions, whether they have sub-thingies or not.
In a multi-level app like GTDNext I still prefer the same approach - to keep it tidy at the project (program) level, but we can use the additional levels to better break down the actions into sub-actions.
I find that a hierarchical view is ideal for me up to the 30 k level - Groups of Areas of Responsibility, such as Business, Non-Profit and Personal, and also Goals (in the sense of “super-projects” 30-40k); I have two such Goals currently.
Thank you for these responses; they have been very helpful. I know terminology can be fuzzy (especially in the GTD realm), but from what I read in the article I view a program not as a sizeable project but as a related group of projects (regardless of size) grouped by their “flavor” (so they are above the project level) but they lie under one of your major Areas of Responsibility. So how to group them; and specifically how to group them in GTDNext?
@James - I tested your two suggestions against my original idea. I don’t like my suggestion because it in essence does damage to the traditional DA GTD concept of an AoR (i.e. it turns an AoR into this new concept of Program). Your TAGS suggestion was better, but I found that it relegated the important level of Program to a Tag; cluttered the Tags list a little bit; and forced me to click on a AoR button and a Program Tag button at the top of the center panel to break things out.
Your Sub-Projects suggestion was fantastic. Everything is extremely clean and well organized - - AoRs are selectable from the buttons at the top of the center panel; Programs are selectable from the left panel; and Tag buttons are left to do what they should do (which can include GTD Contexts as well as other needed keywords). I think this is going to work perfectly for me. Thank you.
I believe you are on the right track, and I get the impression that your thinking is not dissimilar from either mine or James’s.
I sounds as if you have now decided on a “program” level (at the very top, it seems) in your hierarchy. These “programs” you regard as “groups of related projects”. Presumably these “programs” are not tiny, so you presumably have only a reasonable number of such “programs” defined, which makes the list graspable. Other projects sit “under” these programs. And each program belongs uniquely to one “Area” (such as Work or Private) or perhaps even to one specific AoR (e.g. Husband, Gardener, Tutor … within the Private sphere).
This is all great.
Now, what you might want to think about (or maybe have thought about) is what you are going to do with those project-type thingies that will take so much time and effort and focus and will have such a large impact on your life that you may even have to revise your AoR structure if or when they are successfully completed (e.g. start a new business or become a politician). These would be referred to as 30k or 40k goals in GTD. What you could do is treat these just the way you treat “Areas” (Groups of AoRs; e.g. Work or Private.) If you use the “area tag” feature for the “areas”, then you may want to use that same feature for these higher goals. Or if you use the hierarchy (a new top level above the programs) for the “areas” you may want to use that for the goals, too. Or if you use both, which entails some redundancy but has its merits in terms of how you can view your stuff in more ways, you may want to make sure it all really tallies and makes sense for you both when you review and when you want to pick more tasks to do.
Just my two cents: I have used the GTD system for many years and it’s incredibly helpful for me–a lifesaver really. One of its keys is that it is not too complex; the same is important for an online tool. For me, adding another category, like “programs,” would start to erode the utility of GTDnext. I recently dumped my Nozbe account for a similar reason.
I don’t intend criticism for Charles or anyone else but I want the developers to know that it’s important to me that they stick to the core of David Allen’s Getting Things Done system.
I agree that the UI should be easy to understand for someone who just read one of the GTD books or just moved over from another GTD app.
The only words that exist in GTD to describe the “hierarchy” are action and project (and area of responsibility and groups of such), so I agree it is best to stick with these terms in the app.
But there is a lot of “power” in the ability to structure you stuff into more levels, for those users who want, so probably the key to simplicity is to not force this additional complexity onto those who do not want it, and to simplify the use for those who only want to use the basics.
For example, as I believe @Proximo once suggested, I think it would be smart have a button for “create project” (which would create a new top level item in the projects list in the left menu), and a button for “create action” (which would create an action in the list you are looking at, e.g. the Next list or a particular project). It is too complicated and unnecessary to have to learn the Workflowy mode for those of us who are used to Omnifocus, Nirvana, Things, Zendone, Doit etc etc.
Also, I think the outline hierarchy should not be the first thing in the left menu. Focus, Next and Waiting are probably the lists everyone needs to look at several times a day (and Inbox, for those who use it). But the hierarchy in its full width and depth is something that only “heavy organizers” will want to look at, ever. This could be hidden further down as a regular “project list”, where most users will just click the specific project they are need to review.
Those users who did in fact chose GTDNext precisely because of its unlimited hierarchical flexibility will easily find out how to sub-sub-subdivide their stuff in any way they please, so there is nothing for the developers to be scared of. Even if if some users use the hierarchy in such a way that a top-level entity is perhaps not a project at all anymore but maybe a 30 k Goal or a Group of AoRs or a “program” or whatever, these users will not have a problem with it being called “project” in the UI, as it was their own decision to use the hierarchical flexibility in this other way.
I visit the app from time to time but get scared away by it’s complexity and confusing UI. If it’s not simple to understand and use, I think you will loose many people who give it a try.
We have busy complex lives as it is and the last thing we need is a busy and complex app to help us manage it.