Brandon's Notepad

August 28, 2013

Getting Things Done @Home

Home > My Research > Improvement > Getting Things Done > @Home

My GTD journey began in 2009 at both work and home. I’ve already written three posts about by workplace implementation, but I managed to postpone writing about my home experience until now, over five years later! It was in part because I gained so much more ground at work and at a rapid pace, and I had something exciting to share. At work, I was completely in charge of my workspace and I enjoyed the freedom, time, and energy to establish and use my system at I saw fit. Home was another story. Evenings and weekends were usually filled with family and household obligations. Most evenings, I was too tired to think by the time my “me” time rolled around, and the sheer volume of “stuff” I needed to process was overwhelming. And the worst of it was that, not only must I share a workspace, but I was met with a lot of resistance. To be honest, none of that has really changed much. I tried so many things to make GTD work at home and racked so many lessons learnt, I didn’t have anything worth writing about. Now, I finally have a system that works well.


I have the same basic mail services that most people have (e-mail, voicemail, and snailmail), and like most GTD neophytes, the first thing I did was rush out and buy a physical inbox to collect incoming stuff, both paper and non.

Physical Inbox. I bought a HŌM-branded multipurpose tray from Walmart which is basically an oversized paper tray with angled sides such that the top opening is larger than the bottom. I figured this would be good for holding a lot of stuff, even bulky items within reason, like flashlights requiring fresh batteries or toys in need of repair. I still use the tray, but I put things there myself for the most part. There seems to be this fear that items that go into the box will simply be missed (or even purposely ignored); ironically, because the box is not used as a regular collection place, that is exactly what happens! I don’t expect anything to show up there, so when something is put into the box I may not see it until days or weeks later.

E-mail. Nothing compares to Gmail’s labels and filters. I love opening my inbox and having a good general idea about what’s in it by simply scanning the brightly colored labels. It makes a serious difference when I need to scan but not process my e-mail. The recently added categories (e.g. Social, Promotions, Updates, etc.) are proving to be really useful too.

Voicemail. This albatross, on the other hand, I loathe. E-mail me. Text me. Why are we still leaving voicemails these days? Well, I still have to deal with them, so I usually go straight through the queue and write each call down on a list, including date and time of the call, the number, the caller, the purpose of the call, etc., and then I process the list immediately after hanging up. This takes a little time and attention, so I unconsciously resist this task, often until my mailbox is full and I get text messages and e-mails to that effect. (Again, why not just e-mail me from the start?) On one phone line, I do enjoy automatic transcription of messages delivered by e-mail, but the resulting text is often butchered so badly that it is more a form of entertainment than a productivity tool.

Snailmail. Mail delivered to the house aggregates on the kitchen bar. It is never placed into my inbox lest I miss a bill or a bank statement or some other correspondence that demands my immediate attention. Not that I’m informed about such things — I have to search and re-search the stack periodically to see if anything new shows up. It would be far more efficient and effective to just place all mail directed toward me in my physical inbox and then give me the time to deal with it, but I finally gave up on this crusade. I now consider the kitchen bar an inbox. Hey, at least it’s consistent.

My Chair Isn’t “In”. I have precisely the same problem at home that I had at work when I started using GTD five years ago. The only difference is that at home the problem hasn’t gone away. While it is unfathomable to put something in my physical inbox, it’s perfectly acceptable to place it in the seat of my chair only three feet away. And it isn’t one thing either, but five or six at a time. Want a guarantee that something doesn’t get done? Prevent me from sitting down to work on it. I’m not trying to be passive-aggressive either, I just get very frustrated when I can’t sit down in my own chair, and then I tend to avoid the workspace altogether.

Camera Phone. A picture is worth a thousand words. See something at the store you want to buy later? Snap a pic with your camera phone. A buddy of mine captured his daughter’s class schedule and locker combination when school started the other day just in case they are needed at an odd time. I have a lot of pics of books that I find at bookstores that I want to consider checking out from the library or purchasing online later. I still get backlogged in processing these, but its a great capture tool.


As if collection didn’t have enough woes, I suffer from two serious downstream problems: no space and no time. The space constraint affects organization. Let’s say I find a child’s toy in my physical inbox in need of repair but I cannot complete the job in the moment. I have two choices: put it back into the inbox (wrong!) or allocate a space for it on my desk or credenza. The latter happens and not only does the room start to look cluttered, but I eventually run out of space to work! I have found no solution for this problem so far. The constraint on my time available to process does have a workaround: I stuff it all in my bag and take it to work where I can process at lunch. This really only works for paper, but it is an effective workaround.


Processing and organizing are almost the same activity in my opinion. Short of trashing it, an item always requires filing and/or the creation of at least one reminder in the system. I like to get rid of things, so I try to work electronically as much and as often as possible.

Google Calendar. As a user of Gmail, it makes perfect sense to use Google Calendar too. It works well, has a clean interface, and integrates well with other tools (such as Pocket Informant, about which I plan to write later). I eventually set up a family Gmail account and started using the Google Calendar in lieu of the calendar on the fridge. Since Android has permeated our household in the last few months, it has become much easier to live according to one shared calendar.

ThinkingRock. I have tried a lot of GTD software “solutions” (for which I’ve already started posting reviews) and I finally decided to use ThinkingRock exclusively for organizing projects, action lists, etc. I found it somewhat by accident. I downloaded the Android app (along with several others) and I quickly passed it off as inadequate. When I later started to delete the apps I wasn’t using, I thought I might give it one more look. That’s when I read that the app is just a simple front-end that syncs up with the full desktop application. The screenshots alone told me that the desktop program probably fulfilled most (if not all) of my requirements for a proper GTD system. What’s more, I consider the data in my GTD system as very sensitive, so I don’t particularly like it being in the cloud. This app saves data locally, and when I sync up the tablet, I can leave my laptop safe at home.

The Right Contexts. My post on Well-formed Context Lists is the most popular page on my ‘blog to date by a large margin. Taking my own advice, I’ve identified these contexts based on access and resources available/required:

  • @HomeOffice: At home with time to spare
  • @Garage: At home, in or near the garage
  • @Work: At place of employment with time to spare
  • @Commute: On the road, somewhere between home and work
  • @Errand: On the road, but not between home and work
  • @TBD: Used for upcoming actions when context is not yet clear

I find myself (or can easily place myself) in these contexts frequently. What may not be obvious is that the locations are not simply locations, but the gear available in those locations as well, and I choose contexts as appropriate. I know, for example, that I have a scanner at home and a reliable fax machine at work, so I don’t feel like I have to have contexts like @Scanner or @FaxMachine.

The Tickler File. The good ol’ tickler file did not survive at home. As it turns out, I don’t have a lot of items at home to incubate, and since most decisions are family decisions, a personal tickler doesn’t make much sense. For many events, we make a soft commitment to ourselves to attend, mark the date on the shared calendar as optional, and then decide to break the commitment if something else more important comes up. I suppose David Allen would consider this as one way of feeling ok about not doing something because we know what it is we are not doing.

Labeled File Folders. David Allen’s logic concerning hanging file folders and file cabinets really influenced me. I purged the house of hanging folders a long time ago, opting instead for basic manila file folders held in cardboard folder holders (Fellowes Banker Box brand if memory serves). I also invested in a personal labeller. Despite Allen’s advice, this one is battery-powered for convenient use throughout the house. Since I always keep boxes of AA and AAA batteries in stock, I wasn’t too worried about running out of juice at an inconvenient time; besides, batteries seem to last forever in this thing. The labeller is shared, also despite his advice, but it stays in my office when not in use, so I don’t recall at time when it wasn’t there when I really needed it. Family records are stored in our one file cabinet, personal records that only I care about are stored in file boxes, and a small set of folders that I use very frequently or in holders next to my desk.

Reference. As I’ve already mentioned, I like to work digitally as often as possible. I will admit, I’ve always been a bit of a packrat (or is ‘compulsive hoarder’ more politically correct?). In recent years, with storage space becoming more precious as the family grows, I’ve come to terms with the idea of scanning things to which I’ve attached some sentimental value, like old school work. It has been a constant cycle of sorting and combining stacks of paper, purchasing additional storage containers, and preparing for batch scanning, but I’m finally about ready to plough through it all and free up a lot of space. Meanwhile, new stuff is digitized almost from the start.

Evernote. Evernote is my primary reference tool. I have tons of links and snippets organized into notebooks, tagged as appropriate. I usually draft my posts on Evernote as well. The Android app is awesome, though I did lose a lot of work once when a syncing glitch fried one of my entries. Inspired by The Secret Weapon, I briefly considered using Evernote to fully implement GTD, but decided against it because, being a general-purpose tool, it lacks a certain solidity. I felt the same way about TiddlyWiki before it. Unrestrained customizability can be a very bad thing. At a minimum it is a distraction, but I think it intrinsically compromises the trustworthiness of the system — and if a GTD system must be anything, it must be trusted. In addition, I found it more calming psychologically to have separate tools dedicated to specific tasks. This is my reference tool, period.

Brandon’s Notepad. Of course, this site is also part of my reference collection — that’s why I created it! I draft posts in Evernote, but they are deleted once posted so that there is only one source for a particular topic.


The frequent review of commitments is probably the hardest habit to keep and the biggest stumbling block for most GTDers, myself included. Thankfully, this is where ThinkingRock really shines. At the end of my post on Commitment Management I discuss making the weekly review stronger by shifting the focus off of next actions and onto projects. In ThinkingRock, I use the project tree in the lower-left corner of the project view to drive my reviews. That way, I don’t waste time reviewing the granular details of every related action, especially since I do sometimes plan out a few key steps in advance and not just the next one. Having immediate access to success criteria for both project and action is also invaluable. Any actions that happen to be unrelated to any project show up in the ‘Single Actions’ tab in the same window pane, and I do review those, primarily to see if I need to force myself into a particular context during the coming week.


Not a lot of magic here. Doing is doing is doing. Here are a few observations, though.

Queues. I’ve found that a lot of GTD doesn’t have to happen if I establish queues for myself. Reconciling receipts, entering contact info, ripping CDs, and other tasks can be queued up for batch processing. In substance, this isn’t much different from any other list of actions, except that a reminder doesn’t need to exist for each receipt, business card, or CD. The location of the queue is usually driven by storage requirements, and that may or may not be in the most favorable context. For example, I can usually carry my unreconciled receipts and statements with me to work on at lunch time, but I cannot carry my entire CD collection with me for ripping. Working through queues usually requires no reminders once the ball gets rolling, a possible exception being for those tasks for which I want to dedicate a regular time on the calendar, say, each week.

Recurring Reminders. I made the mistake of setting a bunch of recurring reminders, only to find that they are not very effective. Creating the action “Replace HVAC filter”, which should recur every month, sounded like a great idea, but the cycle never seemed to be very stable. Part of the problem was that the replacement itself was not necessarily the next physical action. I would usually wait to buy a new filter until it was time to replace it, so the next action should have been “Buy HVAC filter”. That worked in those months of heavy air-conditioner usage, but in the Spring and Fall usage tapers off and we can go two or maybe even three months between changes. At this point, the monthly recurrence doesn’t make much sense. The next action could be “Inspect HVAC filter”, but the schedule will still be disrupted by delays of one or two weeks here and there. The point is not to avoid using GTD (or even calendars in general) for such reminders, but that recording the next occurence of an action may be best triggered by the completion of the current one and not by a date-driven algorithm.

Closure. It does feel good to mark actions as done. If I can’t do so immediately (or at least on the same day), I make sure to do so during my review. Sometimes I know exactly what the next action should be and sometimes I don’t, but taking the time to cross off an action greatly increases the chances that I’m going to figure it out real quick and keep things moving by creating the new action in the system.

February 14, 2013

Getting Things Done: Commitment Management

Short URL:
Home > My Research > Improvement > Getting Things Done > Commitment Management

I wrote this post for anyone who struggles to make GTD work.

When I read another’s work on the topic of GTD and the entire focus is on ‘next-actions’, it is evident to me that the person writing has either never actually read the book or needs to read it again, perhaps several times, because the point of the GTD system was missed entirely. Though David Allen’s tricks for reminding us about what needs to be done are the most visible and heavily discussed elements of the approach, the tricks themselves are not the primary focus of GTD.

Commitment Management

In subsequent works, Allen refers to meaning overload as a major personal-performance problem, as opposed to the oft-cited information overload. The first step of GTD processing, when something is retrieved from the inbox, is to determine what the thing is, and only then can a decision be made as to what should be done about it. In other words, we must first apply meaning to the thing and determine if we have some commitment to fulfill. The commitment may be limited to keeping the item in reference or it could entail some action, and no commitment at all is a good sign that the item is trash. Projects are commitments that (as defined by Allen) require more than one physical action to complete. Furthermore, the weekly review is supposed to be a time to re-examine the commitments we’ve made to ourselves and to others, and to renegotiate them if necessary. And, a completed next-action may or may not denote the fulfillment of a commitment; indeed, most do not when doing project work — only the last action(s) required truly terminate the project. GTD begins and ends with the commitments, and the next-actions are the vehicle for moving toward fulfilling them. This is what sets GTD apart from to-do lists and other traditional task-management systems. GTD is really about managing commitments, not just actions.

I personally believe that this one misunderstanding is the single largest source of frustration felt by those who have tried GTD and failed to glean value from it. Negative testimonials range from simple claims that GTD just doesn’t work (ubiquitously qualified, “well, not for me at least”) or that it is a waste of time, to more exasperated outcries that GTD has “ruined lives” and is the “product of a mad man”. The system’s complexity is a common complaint, but I think that is a symptom of the real problem (because honestly, GTD is only as complicated as you need it to be). No, I think that many of these folks were not using GTD to manage commitments at all, but were focused solely on next-actions. They’d fallen back into managing to-do lists.

The Software Made Me Do It (Wrong)

One way to learn how to do something new is to start tinkering with the tools of the trade. This may not be the most time-efficient, cost-effective, or physically safe method, depending on the skill you want to learn, but despite all that, trial-and-error continues to be one of mankind’s most popular methods of instruction. And these days, tools of the trade almost invariably include software applications.

The problem is that most of the GTD applications offered today do not focus on commitments either. Almost all are task-management apps (i.e. to-do lists) with an added context field to make them “GTD compliant”. Some provide the ability to categorize tasks by project, though these are usually just free-form text fields or (better) items in a drop-down list. Needless to say, this works fine for recording next actions, but this model does not address commitments explicitly.

A Better Mousetrap

What should a GTD application look like? Let’s attempt to answer this question by applying a systems approach, deriving functional requirements from David Allen’s writings.

Consider first what happens when an item — I will call it an artifact — is retrieved from the inbox for processing. Allen sums up the imputation of meaning to the artifact in a single question, “What is it?” And, to borrow one of Allen’s super-simplistic examples, assume the artifact is a mailer for an upcoming stage performance that you’ve been wanting to see. Any good GTD practitioner will tell you that it is time to identify the next physical action required to move toward seeing that show, right? The underlying assumption here is that a you’ve actually committed to attending a performance, the decision-making process taken for granted. Here are some questions that may have contributed to the committment:

  • Why am I considering this committment? What’s to gain? To lose?
  • Am I available or do I have a prior commitment to honor?
  • Who should I invite? Are they available as well?
  • What will it cost? Is it a good deal? How will this affect the budget?

Notice how these same questions could be asked with respect to any potential commitment. Answering the first question is a cognitive expression of desired outcome and the other questions concern generic constraints: time, people, money. Capturing the considerations made regarding this decision may prove useful if the commitment must be renegotiated or broken at a later time.

Now, assume that the decision to attend the performance has indeed been made. Since tickets are available online for purchase immediately (in less than two minutes), the next physical action is to drop off an appropriate suit or dress at the dry cleaners. The questions that arise as this action is discerned also help identify constraints but the considerations made are operational, not tactical:

  • What must be performed exactly?
  • Who is assigned the task?
  • Must it be done on/before/after a certain time and date?
  • How long might it take?
  • Under what conditions must the action be completed? In what context?

The following Entity-Relationship Diagram (ERD) represents one way in which the information gathered above could be logically organized. (ERDs are used by analysts to map real-world concepts in a way that facilitates the design of relational database tables and other data structures.) The attributes for the “Commitment” and “Action” entities were derived from the questions above, or more correctly, from the anticipated answers.

As indicated, these entities share a particular relationship: a commitment is a promise to do some action (or combination of actions), and an action fulfills (in part or in whole) one and only one committment. Strictly interpreted, “next action” implies that only one can be defined at a time, so a one-to-one relationship would be appropriate; however, this is not necessarily efficient or practical, especially for complex commitments. It is possible to have concurrent “next” actions as long as they are independent, and these actions may differ in context, and assignee as well, so the argument that a person can only do one “next action” at a time goes out the window.

Based on this description of the data, our hypothetical GTD application could function as follows:

  1. The user must be able to create new Commitments and mark them as fulfilled as appropriate.
  2. A desired outcome gives rise to a new Commitment; thus, this field is always required.
  3. To promote immediate discernment of “next actions”, at least one Action is required for unfulfilled Commitments.
  4. When an Action is marked complete, the user must either create a new Action or mark the Commitment as fulfilled.
  5. Next actions are assigned to self by default, or may be delegated.
  6. Action context is always required.
  7. Action duration is never required. Use of this field is encouraged.
  8. Action due date is never required. Use of this field should be limited.
  9. A Commitment list must be provided with enough detail to facilitate weekly review.
  10. Action lists must be provided for each context with enough detail to facilitate Action selection in the moment.
  11. Artifacts (soft copy) may be attached at any time.

This list of functional requirements is for illustration only and admittedly informal and incomplete, but it drives home the idea that the software can drive good GTD practices instead of obscuring them.

The GTD application described above doesn’t just encourage proper use of GTD principles, it enforces them. Notice, for example, that the Action entity has no priority attribute. This was omitted on purpose, as the prioritization of actions is antithetical to GTD practice at its core. The inclusion of this field, incidentally, is another indicator that most GTD apps are not properly designed. An extended task management application would have already included this attribute as part of its existing model, and the inclusion of this field in new GTD applications is easy to rationalize “just in case you wanted to use it” or “because it is such a common feature”. But then, challenging the effectiveness of traditional systems with common features is exactly what GTD does.

[For those who might’ve noticed the discrepancy, the reason why the minimum number of Actions related to a Commitment is zero is that the application may save the Commitment data before the first Action is created. In fact, it may be necessary to do so for technical reasons. I wanted to avoid complicating the model with a gerund entity. So, we’ll let requirements #3 and #4 be enforced by the application, not the database. Yes, this is really a design consideration and I’m getting ahead of myself, but it’s always better to prevent design flaws than to have to fix them later.]

On Artifacts

In the book, David Allen uses artifacts in two basic ways. The first and most obvious is as an indicator that something needs to change because it isn’t “what it should be and where it should be”. This results in either immediate action or a promise to one’s self to take action later (i.e. a commitment). The second is as a reminder. Slipping that mailer into the tickler file or putting the needed file folder under the car keys by the front door are ways in which the artifacts themselves become reminders. But an artifact is not the same as a commitment.

Some ‘GTD’ applications are available that convert e-mails into next actions. These are usually “add-ons” or “plug-ins” to popular e-mail platforms. This approach is based on the premise that there is a one-to-one relationship between e-mails and next actions. It’s not always that clear-cut. I may have a dozen e-mails that are informative in nature and that indicate in aggregate that I have the responsibility or wherewithal to effect a change. Which, if any, do I use to spawn a new next action? None fit the bill, but that doesn’t eliminate the commitment.

Having said that, I am intrigued by the mechanism. Using e-mails, scans, camera phone pics, or other digitized artifacts is very efficient method for not only recording evidence that solidifies commitments, but also recording details that may be crucial to completing a next action. For example, not too long ago, I picked up a shipped order at a major electronics retailer. When the clerk asked for a printout of the sales receipt e-mail, I simply showed it to him on my tablet. His comment was, “Man, we really need to add the barcode to those e-mails!”

Mousetrap Revisited

While the functional requirements above describe an adequate system with a proper relationship between commitment and action, any GTD practitioner will notice that a few key features are missing. There’s no calendar, “Waiting For” list, or tickler file. So how can one delegate next actions, defer the assignment of meaning to an artifact to a later time, or define the “hard landscape”? Obviously, the data model could be expanded and these functions added, but I think a little abstract thinking can go a long way.

A Next Action item on a context list is, in essence, a reminder. Indeed, the context list concept is simply David Allen’s trick for placing reminders to do things in places where they will be seen at the appropriate time. Calendar entries and tickler files are no different. They are similar in their attributes too. Modifying the requirements above to replace the Action entity with an abstracted Reminder entity, here is a new ERD and set of requirements:

  1. The user must be able to create new Commitments and mark them as fulfilled as appropriate.
  2. A desired outcome gives rise to a new Commitment; thus, this field is always required.
  3. To promote constant progress, at least one Reminder is required for unfulfilled Commitments.
  4. When a Reminder is cleared, the user must either create a new Reminder or mark the Commitment as fulfilled.
  5. To reduce noise and boasting, cleared reminders are removed from view.
  6. Assignee is always required for “Next Action” Reminders, assigned to self by default, and is not available on other Reminders.
  7. Context is always required for “Next Action” Reminders and not available on other Reminders.
  8. Duration is never required, and is available on “Next Action” and “Calendar Entry” Reminders.
  9. Date is required on “Calendar Entry” and “Tickler” Reminders, and not available on “Next Action” Reminders.
  10. A Commitment list must be provided with enough detail to facilitate weekly review.
  11. Context lists must be provided, listing “Next Action” Reminders with enough detail to facilitate ad hoc decisions.
  12. A “Waiting For” list sorted by assignee must be provided to present delegated “Next Action” Reminders.
  13. Calendars must be provided, including daily, weekly, and monthly views.
  14. A Tickler File must be provided, listing all “Tickler” Reminders for the current day.
  15. Artifacts (soft copy) may be attached at any time.

Now it’s a matter of presenting reminders on appropriate lists. The context lists show next-action Reminders just as before. The calendar view could be a simple listing grouped by date or a traditional analog calendar. The tickler would be the same as a calendar listing, but limited to ‘today’, and the same date field would drive both. The first model above allowed for the delegation of Actions to assignees, and those action Reminders could be presented on a “Waiting For” list; in fact, looking ahead a bit to design, assignment of an “Next Action” Reminder to someone other than “me” could force the value of the context field to an otherwise-unselectable “delegated” context, guaranteeing that the action will never be visible on both the “Waiting For” list and some other context list at the same time.

Notice that a Reminder cannot have both a date and a context. This is one way in which extended task-management systems fall far short in promoting good GTD. According to Allen, next actions should happen as soon as possible — that is to say, as soon as the conditions are right: context, energy level, available time, etc. — and calendar items must happen on the designated day/time or not at all. One is very flexible and the other very rigid. The model above forces the user to choose only one way to manage the Reminder.

Various enhancements can be added in the design phase. For example, objected-oriented design and implementation would undoubtedly lead to a Reminder class and various subclasses for next actions and the like. Such a superclass could permit the user to create custom Reminder types as well. But, for the purposes of this posting, I will leave those considerations to others.

Toward A Stronger Weekly Review

The weekly review seems to be a big sticking point for many folks, for both GTD practitioners and for those who have given up. David Allen is adamant in all of his writings about the power and absolute necessity of the weekly review. But when next actions are the focus and Friday afternoons are spent doing nothing more than browsing calendars and context lists, the results can include boredom, frustration, lack of direction, despair, and a flood of ‘blog posts denouncing the promised virtues of GTD.

Shift the focus to commitments and then the real tough questions can be asked:

  • Why has this project not moved in the last week?
  • Are the right (types of) reminders in place?
  • Are the next action reminders in the right contexts?
  • Are there hidden dependencies between these actions?
  • Who should I call right now on the “Waiting For” list?

These questions cannot be answered by a cursory review of scattered reminders. Remember that the commitment is, as Allen would phrase it, a stake planted in the ground to which related activities are tethered. Keep the commitments on the top of mind and avoid getting lost in the details.

Blog at