A Daily Review Habit

“Falling off the GTD wagon” (or any task system for that matter) can be all too easy and all too disrupting.  Especially, when you’ve grown used to a system, the gradual loss of trust in that system can come with feelings of anxiety, the need for constant damage control, putting out fires, losing follow up tasks, losing communication trails, losing the state of projects, and more.

To keep a system useful, it needs to be reviewed regularly. I often say that I’m not sure a system even exists unless it is reviewed.

Getting Things Done author, David Allen, suggests weekly as an optimal frequency. I used to review my entire system weekly and had done so for several years. At times, the review process would take me about 1-2 hours. I’d often feel quite positive about doing a review as I know how on top of things I can feel.

But, that is a chunk of time.  I can easily see how a person would lose the interest in review especially at times, for example, when things are very heavy or very light. At those times, you may think either, “I have no time” or “Why bother?”, respectively. The problem is that work ebbs and flows, and you can get hit with a whole bunch at once.

Nowadays, I do both a daily and a weekly review, which interestingly saves me time. The Daily Review takes about as long as my coffee takes to brew in the mornings. The Weekly Review is more centered on system blindspots and now takes about 20-30 minutes.

The Daily Review

My Daily Review includes:

  • Clearing the Inbox,
  • Reviewing any projects that are in the Review indicator, and
  • Making sure my flagged projects are appropriate for the day.

Generally, I use the iPhone to do this:

Morning Mini-Review - Before & After

Detailing the process, I:

  • Examine my calendar to review my scheduled meetings and appointments.
  • Acknowledge any tasks that are due soon as noted from the Forecast view.
  • Process the Inbox to “0”
  • Review all projects requesting review, thereby bringing that number to “0”. Note that this is a different method of Review than what I was doing when writing in Creating Flow with OmniFocus. At that time, I was doing the Weekly Review session only. Now, I do this aspect of the review daily.
  • Review the Land & Sea project as needed. I set its review reminder to every other day, so it is examined very regularly as part of this Daily Review.
  • Examine the Dashboard and decide if it supports me for the day.
  • Process the Inbox to “0” again, as needed.

If I want to be more thorough, I may also:

  • Review my Communications perspective
  • Review my Filing perspective

When I can sit with my tasks and calendar with a sense that they will support me and nothing else comes to mind, about my day or otherwise, I can then pause and decide on what to do next.

This can seem like a lot, but when you’re practiced, all of this can take only a few minutes.  Even if you work from a simpler set of lists, maybe only a single todo list, the same applies.  Examining the list and waiting until nothing else about it comes to mind can be a powerful way to help you move through your day smoothly.

 

My Current OmniFocus Dashboard “Recipe”

My workflow has, in general, shifted towards a session-focused style, as is evident from my recent post.  Essentially, that just means that my dashboard of tasks number only a few (about 5-8, give or take) and each represents a session of work. They are not very specific tasks and are more orchestrating in nature.  This means that my choices of what to do next are simple.

In addition, I tend to work by habit. In other words, I often work on a project over multiple sessions.  Similarly, my routines for maintenance are also a matter of recurring sessions.

As a result, my Dashboard has largely become a series of repeating tasks, using the “Defer Another” function.  Tasks repeat at different frequencies – daily, weekly, monthly, or other.. My current Dashboard “recipe” includes the following:

  • 1-3 “Land & Sea” tasks daily (“Land & Sea” Project)
  • 1 Office Filing task on weekdays, (“Routine : Home & Office” Project)
  • 1 Home Filing task on Fridays, (“Routine : Home & Office” Project)
  • 1 Weekly Review task on Fridays, (“Routine : Home & Office” Project)
  • 1 Family Agenda review everyday, (“Routine : Home & Office” Project)
  • 1 Develop: Music task everyday, (“Music & Artistry : Music & Artistry” Project)
  • 1 Morning Communications on weekdays, (“Routine : Home & Office” Project)
  • 1 Afternoon Communications on weekdays, (“Routine : Home & Office” Project)
  • 1 Financial Maintenance task monthly, (“Routine : Home & Office” Project)
  • Rare odds & ends when they do not fit in the above.

Each task links to a custom perspective or project.

And, of course, there are types of habitual work that do not appear above. For example, I also have the clients I see throughout the day, so I often check on my @Office : Agendas context in the morning.  Clients are scheduled in the calendar.

Also, these tasks are not forced.  For example, a particularly busy day with clients means I may not make it to a Land & Sea project that I thought I could have. If that occurs too often, though, it is likely time for me to re-evaluate my workload. In that way, I use my understanding of how the system is stressed to consider where to make adjustments in my general workflows.

Stats reports for OmniFocus

OmniFocus is very much an app about doing.  It’s not designed with graphical reporting in mind.  Here’s a neat app, though, put together by Thomas Schoffelen, that shows a list of open tasks, and completed tasks from the last 7 days, last 3 months, and completed per weekday.

 

Omnifocus stats

A Principle of Completable Lists

We can have any number of types of task lists, be they a perspective, a context, or a project. Some lists stick around: the daily list, phone calls to make, things to file, agenda items, and more. They fill up, we clear them, and they fill up again.

Two questions we can ask when approaching any list are:

  • Do I intend to complete this list?
  • If so, how often?

These questions are useful because completable lists affect us differently. When we can arrange a list to be completed regularly, we effectively create a reliable channel of work. Whatever we throw in there, so long as it isn’t large enough to clog the system, has a good chance of being done.  As soon as one task starts to stick around though, other tasks tend to stall, too, and soon we’re wading through cobwebs.

We can consider a Principle of Completable Lists:

Lists that are sensed as readily completable within an easily envisioned time frame are more enticing, readily done, and resistant to procrastination.

These lists tend to be short, easily envisioned, with tasks that are either made of habit or are themselves easily envisioned. For example, I use the Dashboard as a completable daily list. I hope to finish it by the end of the work day, though it is not always possible. When it is not, I consider what about it needs adjusting, be it that the tasks are not clear enough, or perhaps that I have taken on too much and need to delay or drop some things.

If we wish to make a list completable, then we need to pay extra attention to its tasks. Consider for each task:

  • Is it appropriate for this list?
  • Is it clear and specific enough? I.e. Is it broken down to the point of confidence?
  • Would it be useful to convert it to to repeating task? I.e. Is it better broken down in time, perhaps performed over several sessions of work?
  • Is there something that needs to happen before this task?
  • Is a next action actually scheduling a time for the task itself?
  • Is it well written?
  • Is it too large for this list? (E.g. would it benefit being converted to a Land & Sea project.)
  • Is it an actual action?

Notice that these questions are just as appropriate for use during review sessions. And of course for the entire list:

  • Are there too many tasks?
  • Can I imagine actually doing all of these tasks in the time frame I intend?

 

Getting more Focused with OmniFocus & Links by Hotkey

Jesse Hollington recently wrote a great post called Getting more Focused with OmniFocus. He’s totally got the Grouping Tasks by Session down, complete with a really nice hotkey/script.

The script takes a link in a task and executes it. So you can have a link to a perspective, application, URL, etc and go straight there with a key command. He uses Fastscripts to set the hotkey.  I don’t own that software, so I linked it up using Keyboard Maestro.  Here’s my setup:

 

Keyboard Maestro - Go to LInk

Being Deliberate with Task Wording

How we word our tasks can make a significant difference in how we approach them. For example, several rules of thumb may be:

  • Start with a verb
  • Maintain both simplicity and clarity when possible
  • Act as though you are delegating the task to someone else. (In fact, you are delegating to your future self.)

In the last post, Grouping Tasks by Session, I showed my Dashboard Perspective:

Dashboard Perspective - 2016-03-15

 

On Twitter, Brandon Pittman asked me what’s the difference between “Read book” and “Read: book”. I said, “not much,” but in hindsight, I realized that there is some rhyme/reason to the nomenclature. The syntax can also be useful to highlight my intentions in several ways.

A Structure of Task Words

The structure is a single verb followed by a colon, for example “Process: X”. I originally picked up this task-writing style from Tim Stringer at Learn OmniFocus. He tends to use it for working with perspectives.

There are several words I now tend to use to start tasks, each with their own cautions. I do not use this convention all the time. They do tend to show up more in the Dashboard perspective, or areas I visit with regularity. The following is a list of how I sometimes write my tasks and my intentions behind them:

  • “Develop:” or “Continue:” are useful words to continue a project where I do not know how long it will last. Most any creative work can fit in this mold. The task often is repeating with a link to materials of the work, a context, or a perspective dedicated for that project.

Example: “Develop: Music piece”

The task repeats. Every session that I feel I have done enough ends by marking the task complete.  The task then appears again at the repeat frequency. When the work itself is complete, I delete the task.

  • “Consider:” is useful for considering if I want to do something. I have a dedicated context for considered tasks, but I can also have considered tasks sprinkled elsewhere.

Example: “Consider: Continue arranging photos” (unflagged, repeating, in @File & Flow : Home context.)

Once the work is considered, whether actually done or not, it can be marked as complete. See also the post on the considered task for an in-depth look at its use and cautions.

  • “Process:” Indicates a series of tasks that are generally memorized and should be completed in one session if possible.

Example: “Process: (some track of music)” means to do all the editing, mixing, and transfer to a Dropbox folder marked for review.

Example: “Process: Communications” means to review the Waiting for list, clear my phone, emails, and text messages, and make all needed calls, emails, and text messages.

Caution: This term is most useful for fully practiced work, where you know the methods and materials involved. If it needs to be left incomplete before ending its session, consider writing an additional task to mark where you left off.

  • “Review:” is useful to look over a list. I can do none, some, or all of it.

Example:“Review: Office Filing” – flagged and repeats on weekdays. I have in mind the intention of clearing the list every few days or so, but I do not have to do all of it when I see it. I make that decision during each work day. If I feel I have done enough filing tasks for the day, I mark the “Review:” task complete. I anticipate seeing it again on the next workday.

Caution: One needs to acknowledge the intention of the list. If a list never completes, is too large to review in a single setting, or is completed too slowly, is this acceptable? If not, adjust the list so that trust for its use is maintained.

  • “Clear:” is similar to “Review”, “Clear” tends to refer to a list. However, instead of doing none, some, or all of it, my intention is to do all of it.

Example: “Clear: Home Filing” which is flagged and repeats on Fridays. I aim to complete the task by the end of the weekend.

Caution: Lists that we intend to complete in a span of time tend to take the greatest skill and finesse. For example, a daily list (like the Dashboard) is intended to be completed within the day. All of the skills of drafting tasks, setting repeats, acknowledging what can and cannot be done, etc. come into play.

  • “Practice:” is specific to the practice perspective. These are pieces of music that I am either composing or learning. I set them at some Defer Another interval, practice it on the day it shows up, and mark it complete. Periodically, I’ll change the repeat interval depending on how well I feel I know the piece.

Example: “Practice: Toccata in D Minor” unflagged, defer another set to q3 days, @Piano.

  • “Arrange:” means that I plan to re-arrange where the task sits in a project.  This is useful if I send a task to a project from the Inbox, but I know that I want to change its position because of sequential groups of tasks.

Caution: These tasks are best addressed as soon as possible.  Otherwise, the system decays quickly.

It should be stressed that, with the exception of “Arrange:”,  these terms are mostly useful for habitual tasks, usually representative of larger projects, areas of focus, or commonly visited lists.  They are also in an evolving state of use.

To Finish or Not to Finish (a List)

There is certainly overlap between some terms. For example, “Read: …” is just another version of “Continue: …” or “Develop: …”.

Other terms, though, such as  “Clear” and “Review”, highlight an important distinction of how we can approach our lists. Some lists are meant to be completed in a period of time. Some lists are not. But it is the acknowledgement of the intention that is most important. The lists themselves do not care.

For example, I have @Laptop as a context. There are presently 84 tasks in it. It would be ridiculous for me to actually work from the context directly. I know that.  But, I still find it to be a very useful context when paired with focus and/or workflow perspectives. If I focus on a particular project, I can see a small number of @Laptop tasks. Suddenly, clearing the tasks makes sense.

As another example, I maintain the @File & Flow tasks as a list that I wish to complete within the span of days. Any task that sits there longer is either poorly placed, not broken down enough, or I need to consider whether it is a larger task than I originally considered or admitted to myself.