« A conversation with Mark Hurst, web usability expert and author of "Bit literacy" | Main | How to help people »

Extreme GTD: How low can you go (or: Can we 80-20 GTD?)

I had a great question from one of my coaching clients who happens to be familiar with GTD [1]. He wondered whether a simpler version of Allen's work was possible, say one that fits the spirit of the 80/20 Principle, maybe even something like 90-20 [2]. The reasoning is that the system can seem overly complex, with a significant barrier to entry.

So in IdeaMatt fashion I took this as a challenge and spent some time on an exercise of to figure out what's possible, given the various systems I've studied [3]. My goal was to stay true to my understanding of the the essential GTD habits, including workflow phases, processing and organizing (e.g., two minute rule, "sticky" inputs, and front-end decision making), and effective reminder systems. I wanted to look at as radical change as possible within these confines, rather than incremental adoption or simpler tools. (Note: A search for "GTD lite" and the like turned up some nice thinking on the topic, but a good number addressed adoption/tools, and not necessarily a shift in the method itself [4].) See below [5] for others who have looked at this.

My conclusion: An 80-20 version just ain't possible. This is both a testament to Allen's crisp system, as well as to the necessary rigor to back up the goal of a clear and focused mind. Following is a summary - you can read some background detail below. but I wanted to share the resulting simplified approach. I'd really love to hear your thoughts on this...

A simplified GTD-compatible system (~70-80)

This is the best I could figure out without incorporating more (relatively) radical ideas [3]. As in any simplification, there are serious trade-offs, with the biggest risk being keeping things out of your head. Note: I've thrown in some percentages estimating amount of simplification:
  • Collection: No change (capture everything, fixed # collecting points). Maybe maintain a single inbox for everything that you carry with you.
  • Processing: Use the 5Ds: DELETE, DEPOSIT (file), DELEGATE, DO (two minute rule), DEFER. ~20% simpler
  • Projects list: No change (master list of work requiring two or more steps).
  • Calendar: No change. BUT:
  • Actions: Schedule all actions on the calendar. No actions list, no contexts. 40%
  • Waiting For: None; use the calendar. This means you do hard scheduling of all follow-ups. 20%
  • Tickler: None; use the calendar. 0-30%
  • Filing [6]: No labeler (gasp!) No change in reference and project files. 10%
  • Someday/Maybe: None. 20%
  • Checklists: None; schedule as recurring reminders in calendar (daily, weekly, etc.) 10%
  • Agendas: None; keep with project materials (but OK to have "projects" for on-going meetings). 10%
  • Weekly review: None (!); do incrementally via daily review, say the night before (a common best practice). Review daily: calendar ~one week out (gets actions, waiting for, reminders), mind sweep. Opportunistically: projects. 30%
Importantly, to make this work you'll have to have an electronic calendar. Otherwise there's too much work moving actions around. Also, using it for ticklers and waiting for items probably requires electronic reminding.

What I like about this: 1) Simple. The calendar does most everything, with support by the projects list (which I really wanted to get rid of - thoughts?). 2) Implements what Mark Forster calls closed lists, which help to define limits on our work, a common complaint about GTD.

What I dislike: 1) Potentially too much forwarding of unfinished items. David Allen makes a strong argument for separate action lists. 2) Risk of cluttering up the mind, esp. from removing the weekly review, Someday/Maybe, and checklists.

Interestingly, once this emerged I recognized similarity to other calendar-centric systems like Bit Literacy (with its scheduling of all actions) and Do It Tomorrow (with its closed lists).

What do you think? Are you using anything similar? Should we create a name for this? ;-)


A sketch of my analysis

This is a bit rough, but I hope it's useful to your comments or critiques. Broken down by workflow phase.
  • collect
    • skip: no. o/w don't know incoming work, clutter (paper, mental), leads to missing work
    • just one bucket? (impossible)
    • don't do mind sweep (head full)
    • reduce (just manages, but still need collection)
    • process
    • skip: no. o/w work unidentified, falls through cracks, etc. maybe combine conceptually with organize?
    • FAT (sure, but less rigorous). the problem: what to do with Act? must go to: do (now), delegate (other), defer (later)

  • organize
    • skip: no. need places; o/w clutter
    • filing: radical: one file (Gmail model), organized say by date. prob: hard to find? time not always best way to index -> very difficult to find paper related to projects
    • filing: no labeler (10%)
    • all actions on calendar? prob: usual GTD, plus project actions hard to track?
    • no projects list, say use project folders themselves for list. prob: not all projects need folders. have to carry folders instead of single list. hard to remind/review next steps
    • no waiting for, say use tickler. prob: none?
    • no tickler, say use calender. prob: none?
    • no someday/maybe: yes, if don't mind not tracking (mind fills)
    • no checklists: yes, but on mind. maybe put in calendar (daily, weekly, monthly, ...)
    • no agendas (keep with projects)

  • review
    • skip daily tickler: yes, if using calendar
    • skip daily calendar: no. prob: would have to look 2 weeks ahead every day, say night before
    • skip daily actions: no, but simpler if all scheduled on calendar
    • skip daily waiting for: yes, say if on calendar

    • skip weekly mind sweep: yes, if done daily
    • skip weekly someday/maybe: yes, if not tracking
    • skip weekly projects & plans: maybe. prob: projects not up to date, actions not happening, blind-sided by problems
    • skip weekly calendar: yes, if done daily
    • skip weekly actions: yes, if done daily
    • skip action support: yes, but might slip through cracks

  • do
    • put on calendar: see above

Reader Comments (35)

Cool! it fits to life purposes,
and i have found interesting simplification for GTD on email management to zero:


January 15, 2008 | Unregistered CommenterMarius

Thanks for the pointers, Marius. You have two lists: Actions (broken into read and other) and Waiting For lists, similar to [ 4 Steps to Banish Email Clutter | http://thinksimplenow.com/productivity/4-steps-to-banish-email-clutter/ ], which also has essentially two lists: Actions (broken into read, reply, and other) and Waiting For (no projects list). Equivalent from that sketched above: Zero ;-)

Thanks for reading.

January 15, 2008 | Unregistered CommenterMatthew Cornell

Hi Matt,
Very interesting and thorough analysis. It reminds me of the system I cobbled together when I worked for a big hotel and got my first Palm Pilot. I lived in Outlook then, kept everything on one 'to-do' list on a legal pad. All phone messages were recorded in a spiral notebook. All customer contacts were loaded live (i.e. during the call) into the CRM. Everything physical that cam my way went into one of three piles on my desk: Today, Tomorrow, Later. The idea was that I had to get through the 'Today' pile each day, and attempt to start on the 'Tomorrow' pile, or do one thing in the 'Later' pile. By the end of the week there should only be one pile, 'Later'.
It worked fairly well, but I never reviewed anything, frequently had to search the offices for files, and (lucky for me) had a shared Admin to help with phone calls and correspondence.
This system could have benefited from an analysis like this, thanks for the ideas.

I agree this is a tough system to do half-way.

IF I had to pick one and only one place to start, it's to have a few collection buckets everything gets dumped in. Then even if you don't do the other parts of GTD, you have a clue where you could find things if you absolutely had to.

This is where David starts his consulting anyway, I think. So it's a plus... and not difficult.

But to get the most out of it, regularly review, projects, lists, filing (paper and electronic) etc., are a must.

January 16, 2008 | Unregistered CommenterChristoph Dollis

Stephen and Christoph - Thanks for your comments.

Stephen: Neat system. Your paper pile system reminds me of The Instant Productivity Toolkit. Summary:

o actions list
o phone log (no action?)
o contacts -> s/w
o no review

Christoph: I agree - I couldn't lose the collection points. And it is a good place to start the process; I do something similar. Homework: Collect required tools and set up collection. During: Everything -> collecting points, then process! Often I have clients do an initial FAT (File Act Toss) pass if lots of paper or email. Summary:

o collection tools: no change
o review (daily? weekly?
o projects & actions lists
o filing: no change

January 16, 2008 | Unregistered CommenterMatthew Cornell

Matt - In the 5D framework, where would you do tasks that require lot of cogitation. For example, there is a white paper in the email, do you defer it and then set up time to review it later?

Please keep up the great work and God speed on your recovery.


January 16, 2008 | Unregistered CommenterBay Fox

Hi Bay-Fox - good question. If you can't do the required action (e.g., read and comment on the whitepaper) in a couple of minutes then, in the system I've sketched out, you'd defer by scheduling the action on the appropriate day. Regarding where to store the email itself (which we'll assume you need to respond to, say), I'd recommend an Action Support folder on the email server. Then, when you come across your action in the future, you'll easily be able to find the email supporting completing the action.

If the action would take longer than one sitting (I usually recommend about one hour max), it'd become a project, ALA GTD: Make an entry on the master projects list ("review XX paper"), break it down into the action steps, then schedule the first one on your calendar.

Does that answer your question?

Thanks for reading, and for the good wishes. Healing proceeds apace - I'll be sans cast next week, which means time to get ready for mountain biking in the spring ;-)

January 17, 2008 | Unregistered CommenterMatthew Cornell

Hi Matt,

Thanks for the great post. I've been thinking for a while about 80/20 unit tests, ie. writing tests for only the parts of a system that are either very important, or very hard to write (and easy to get wrong), or that change a lot. You wouldn't have complete coverage of your code, but with significantly less effort you'd get the most important/used pieces covered... I was wondering what you thought about this? Does this go against the basic principles of test-driven developments? Thoughts? Thanks!

January 17, 2008 | Unregistered Commenterschapirama

Hey Agustin, thanks for the XP question. For those of you who are programmers practicing [ Extreme Programming | http://www.extremeprogramming.org/ ], read on. (More XP-related posts below [1].)

Good question. Certainly for optimization efforts, 80-20 is absolutely smart. The only rational approach, really. That's why profilers are useful. But unit tests... My first reaction is no. Of course having the tests is very important - things can break and you need to know right away (easier to fix then). However, TDD requires starting from tests for *all* code - and you know what a proponent of that I am - no exceptions! :-)

I suppose you could just write tests (post-hoc) for 'important' parts, but I'm sure you've experienced relatively simple code that has a nasty bug, e.g., a sort algorithm you've written, or a stack.

So my thought is: Don't do it, i.e., it does go against the most
fundamental aspects of the system.

However, applying 80-20 to the principles of XP itself is a possibility. I'm sure the experts would say that all 12 (or so) practices are required, but, like with my GTD analysis, there may be wiggle room (either a little or a lot).

Thanks for the question, and reading.

[1] Some XP-related posts:
[ Is GTD the "Extreme Programming" of Time Management? | http://www.matthewcornell.org/blog/2006/01/is-gtd-extreme-programming-of-time.html ] and [ Productivity for Programmers, #2: Efficient vs. Effective | http://www.matthewcornell.org/blog/2007/02/productivity-for-programmers-2.html ].

January 17, 2008 | Unregistered CommenterMatthew Cornell

I am no GTD expert yet (still reading the book). But I have read a lot about the system on the net and I have seen DA's google talk. And actually I like the context stuff. One should not have too many contexts, but the automatic generation of a shopping list and phone list is one of the things that draws me to GTD. The first because I need a way to take it with me (print on paper, pda, mobile) and I don't want it to be too long and the second, because I hate making calls and therefore tend to forget calls I have to make.
The project buckets are nice for my @computer stuff, which equals @work for me. Some things have deadlines, some things get forgotten, if they are buried under 200 other things. So a little structure can help. I will probably try to use this.
I also like the notion that you should not pressure yourself by setting deadlines, that are not necessary. After a day of catastrophes you don't need the computer to tell you that you have not done the stuff you planned to do, except if it really is something that has to be done.
I don't know (yet) about all the tickler stuff and the archiving. But I like me some gadgets, in this case a labeler.
By the way thanks for the analysis, the GTD system seems pretty basic, as promised by DA. I always take these promises with a grain of salt.

January 17, 2008 | Unregistered Commenterdkah

Thanks, Matt. I understand the need for an air-tight system, without leaks. Yet, at the same time, I think it's fair to say that unit tests very rarely cover 100% of your code. If we accept that, I think it makes sense to focus on the 20% that will give you 80% coverage/security.

For example, a while ago we wrote tests for the GUI front-end of our system. It was a painful process in which we had to specify exact string matches with HTML code, one by one. A tiny insignificant change and all the tests had to be fixed --even if the results were still OK. It seems like it was too much work for too little benefit. On the other hand, we had tests for the core modeling portions of our system, which other programmers had written. The existence of the tests allowed me to re-write them from scratch with the security that I wouldn't break anything serious. I think that the kind of 20% effort that gives you 80% of the benefit...

January 17, 2008 | Unregistered Commenterschapirama

Good points - thanks Agustin.

January 17, 2008 | Unregistered CommenterMatthew Cornell

I'm a backsliding GTD! I only seem to stay on top of the system for a day or two and then I backslide. A month or so later my life is out of control and I get back to basics. Every little short cut to working the systems helps. Thanks Matt for a good review of where we can cut a corner or two and still stay on track!

January 23, 2008 | Unregistered CommenterPat Faber-Garey

Pat - I feel your pain. An up and down in chaos is natural daily, getting back on top is the key, as you point out. Thanks for reading!

January 23, 2008 | Unregistered CommenterMatthew Cornell

I'm not sure I understand the value, as you suggest, of eliminating the action lists, and putting all next actions on the calendar - doesn't this nullify the key GTD principle of being able to take advantage of "weird time", as David Allen calls it, and, for example, take advantage of a 15 minute window on the library internet station when unexpectedly waiting for one's spouse to peruse the media section of the library? This happened to me yesterday, and I was very glad to be able to pull up my @internet list, and plug away at a couple of items. There's no way I could have known the day would have gone like this, and therefore couldn't have planned these actions on hard landscape.

It seems that this is a very backwards step to me.

January 27, 2008 | Unregistered CommenterArcanum Acres

Hi Arcanum - Great questions!

Advantages of moving actions -> calendar:
1. one less list
2. simpler selection of action: only do what's on that day (no reviewing a longer actions list)

Nullifying "weird time" (also called "between" moments): Hmmm. I don't think so. If you have extra or unexpected time, just pick one of the daily actions to do right then. Also, I recommed to clients they always carry a reading folder for just such occassions (what David Allen calls the Read/Review folder). Also, it's probably a good idea - like the actions list - to put a mixture of actions on the list: those that take more or less energy or time. Finally, re: your great internet example: I don't think there'd anything wrong with pulling an @internet action from the future...

Again, great points. There's clearly more complexity in creating and managing each day's actions. Much appreciated.

January 27, 2008 | Unregistered CommenterMatthew Cornell

I have a different take on this.

I think that it's becoming more important to teach users how to design their own time management systems. To do that, there needs to be some agreement as to the fundamentals of time management, as a discipline.

If they could be understood, and taught, then GTD and other systems would be seen as one person's system that works for them, and probably won't work for anyone else without modification.

In fact, this is already happening -- I imagine that other than David Allen, few people are using GTD as described, for good reason. It won't work for them because they are unique.

For example, I moved to Jamaica from the U.S. and life here does not lend itself to the same techniques as the ones I used to use. All of the systems I have discovered were created in developed countries, with lots of cultural assumptions built in.

That's not to say they are not valuable -- it's just that there is not a system that another human could invent for me that could do a better job than one I could create for myself -- with the right assistance and information.

The question is, what principles do ALL time management systems share that make them effective and can they be incorporated into a single approach to design any future system for any individual who wants one?

Well, the truth is that this is already what is happening. All of us are cherry-picking from one system or another, from our friends, and using trial and error in order to cobble together home-grown individual solutions.

This is true even for the most devoted GTD'er who is struggling to implement the entire system, finds themself failing, and tries even harder... but cannot succeed... because they are not the inventor of GTD.

We can all succeed however, in creating and adopting our own system, and improving it over time.


February 4, 2008 | Unregistered Commenterfwade

Hi fwade. Good points. I agree re: customizing a system. Re: the discipline of personal productivity ... I'm working on it! ;-) Interestingly, Stephen Covey's doctoral thesis was on this, and went way back. Haven't found the original yet... There are some books that try to summarize all the concepts, but I don't think they abstract and synthesize as much as I'd like. For example, "The 25 Best Time Management Tools & Techniques"

The philosophical underpinnings are a great start... Ideas like keeping our minds clear and, at a higher level, working from the calendar vs. actions list. Needs more thought! You might find this interesting: [ What are the essential habits of GTD? | http://www.matthewcornell.org/blog/2006/07/what-are-essential-habits-of-gtd.html ].

Your point about cultural assumptions is really interesting. I've not thought about that.

> We can all succeed however, in creating and adopting our own system, and improving it over time.

*This* is the essential point - spot on. Starting on the process, and looking at it as an experiment, is exciting. Helping people do this is a major goal in my writing and consulting. Thanks for bringing it up! (In fact, it's why I cheated when asked the ultimate productivity tip - [ The ultimate productivity tip | http://www.matthewcornell.org/blog/2007/05/ultimate-productivity-tip.html ].

Thanks a bunch!

February 6, 2008 | Unregistered CommenterMatthew Cornell

Interesting discussion here.

I agree everyone needs their own system my perspective is different though- there is a base of knowledge that people should start with and build on it using the pieces needed for themselves. The key is start with basic building blocks: Think (goals/planning/long term thinking), Do (processing rules), Enjoy (missing from gtd, it gives motivation and meaning to what needs to be done).

GTD is very valuable but it is hard to implement to perfection because it is David's personal system and there's a lot to it- that's why I wrote [ Dont Get Things Done | http://www.successmakingmachine.com/2008/01/28/dont-get-things-done/ ].

February 7, 2008 | Unregistered CommenterSuMMy

Hi SuMMy,

you say "...GTD is very valuable but it is hard to implement to perfection because it is David's personal system..."

I don't agree with you - GTD is NOT David's personal system, but a set of underlying principles which are ALWAYS true whenever any "system" is working.

I know that it is very difficult for most people to understand the difference between principles and rules (or guidelines), but to understand GTD, it is essential to understand it as a set of principles.

February 7, 2008 | Unregistered CommenterAnonymous


Interesting -- what would you say are the principles of GTD?

And, is your list a standard one? In other words, has David said what they are?


February 7, 2008 | Unregistered Commenterfwade

This post/discussion inspired my post [ The Best Productivity System For You Guaranteed | http://www.successmakingmachine.com/2008/02/07/the-best-productivity-system-for-you-guaranteed/ ]

February 8, 2008 | Unregistered CommenterSuMMy

Hey all - great discussion. Thanks a ton.

SuMMy - I love your three blocks (Think, Do, Enjoy) - very sweet!

Re: "GTD is hard to implement ... because it is David's personal system..." I disagree too. There are fundamentals common to all systems - all the traditional "time management" things like staying on top of your work, handling incoming ('sorting'), making choices ('prioritizing'), etc. Allen tied in the 'free your mind' part, and contributed a nice, tight package. I will say his method, and esp. the flowchart, tends to appeal to the process-minded. I sometimes break it down to FAT or the 5Ds for people it doesn't click with.

Re: the question of "Don't do it if you don't enjoy it" (unfair paraphrase, I know) - Well, sometimes we *do* have to just do it. Work isn't all fun, though adopting a personal method does give people insights into what they've chosen to let into their lives. This then can kick off some important reflection on what should change. Do I *like* going through all my paper inbox items? Nah, not usually. Is it important for me to do so. Yes. Period.

BTW I couldn't read your two articles - the site is down. Feel free to send a reminder to me when they're back.

February 9, 2008 | Unregistered CommenterMatthew Cornell

SuMMy - FAT: File, Act, Toss - a good first start if there's a very large backlog

And I think your 8 ways is a good take - well done.

Thanks again!

February 11, 2008 | Unregistered CommenterMatthew Cornell

Hi Matt,
I couldn't agree more. I tried GTD lite at first...thinking I could take the best of David Allen's ideas and merge it with my own system. It doesn't work.

I think people are tempted to (try) shorting cut it because it can seem overwhelming at first.

I chalk that up learning curve.
That said - once you embrace GTD -- fully -- it's really very simple. It just takes a bit to get your sea legs.

February 13, 2008 | Unregistered CommenterKelly Brown

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.