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.