Eric asked a question about workflows in doctoral programs, especially with OmniFocus and Scrivener. I’ll deal with Scrivener in another post, but I had to make some significant adjustments to my OmniFocus workflow in order to handle the doctoral program.
Wisdom of the Due Date
I have read and heard several task management experts who warn against excessive use of the “Due Date.” In summary, the argument goes something like this: if you assign due dates to everything, you won’t be able to trust your system to know when things are actually due. For example, if I assign a due date to “Get a Haircut” for February 28th at 5:00 p.m., it’s hard to make the argument that this deadline should receive the same weight as “Pay Income Taxes” on April 15th at 11:59 p.m. If I don’t get around to getting my haircut on 2/28, I’ll probably live.
I have come to believe that this is, in general, very good advice. There are many tasks in my system that don’t need a due date, and so I don’t assign one to them. For example, I have a task in my system right now to go to some of my old notebooks and ensure that I capture any research questions that I’ve listed in them. I’m hoping to do that this week, so in OF, I flagged them. But I’ve not assigned a due date to that task. If I decide to worry about it another week, I’ll defer the task so that it will show later (more on defer further on).
But I did discover a HUGE bug in that system. Sometimes I need a due date so that I can effectively plan to complete a project for a specific date.
For example: if my dissertation proposal defense was on 2/28, there are several checkpoints along the way that also need to be met. Each task within the project needs to be completed along a timeline to get the project done on 2/28. So while these technically don’t have due dates, they can’t all be pushed up against the final day.
In truth, I ended up giving most things on my task list a due date during the Ph.D. During weekly planning sessions, I would assign due dates for anything related to school or work, and due dates for home projects that I needed to make sure were done. During the week, I had to let go and follow my system - if something had a due date, I treated it like a REAL deadline. I didn’t afford myself the luxury of thinking, “Well, this must be one of those fake due dates.”
So I reached the point where I used my weekly planning sessions to map out a week, assigned due dates to anything that needed to get done, and then followed the plan during the week.
Courses as Projects
In my day job, I treat each course I teach as a project of single-action items. In much the same way, I created a project for each course in my Ph.D. I arranged each course as “sequential actions” and listed all of the readings, papers, and assignments from the course, and flagged all of the items. The benefit of this arrangement was that in my “Next Action” perspective, only the next action for each course would show up. I also set defer dates for things that I couldn’t do until a specific point in the semester.
Next Action Perspective
I have a perspective called “Next Action” that takes any available flagged tasks, and arranges them by due date. If I’ve flagged any items that don’t have due dates, they also appear (at the bottom of the list). The perspective looks like this…
Since all of my coursework had due dates, all of my available next actions in each class showed up in this perspective. If a task was deferred, it wouldn’t show in the “Next Action” list until it became available. Creating a plan where the “Next Action” list was useful for the entire week took some planning during the weekly review - but it was so nice to be able to look in one perspective and follow the plan. Items with no due date fell into the “important but not urgent” category, I was able to tackle those as I had time and energy.
One major evolution during my Ph.D. was in the use of Contexts. When I started, I was using contexts in terms of energy. That was a mistake. I needed to be able to group actions. So I ended up with a set of contexts that were verbs, not nouns.
Verbs like “Read, Write, Edit, and Contact” were crucial. Not only did it organize my activity, but it also helped organize my energy. When I was too tired to write, I could read. When I was out of ideas, I could edit. When I had time to shoot some emails or make calls, I could check out the Contact context. I also discovered lots of use for contexts like “Plan, Develop, and Explore.”
Capturing and Weekly Reviews are Key
The two most important GTD practices of my Ph.D. were Capture and Weekly Reviews. I used Siri and the email drop to capture the bulk of my tasks. At the beginning of each semester, I processed the syllabi to ensure that I had a rough skeleton of the courses.
Weekly planning was the other indispensable part of my workflow. Every Sunday - every single Sunday - without fail - I set aside at least an hour to review my next week. I made a plan I could follow, and arranged tasks with due dates that made sense for the tasks I needed to complete. I even planned meals, and selected what podcasts I would listen to on my drives.
I also did daily reviews. I quickly learned that this was not a time to negotiate my due dates; instead, it was a time to orient myself to the plan for the day. Once I had my orders, I executed.
What I’m Still Doing
In the months since finishing the Ph.D., I’ve discovered that I have a lot more breathing room, and fewer deadlines for projects. This means that I’m seeing a lot fewer due dates; but I still use them more than I did before going back to school. The biggest change has been in my contacts. I’ve also adopted a naming convention for tasks to use Lee Garrett’s Kanban approach to OmniFocus(genius, Lee!), but I am hoping that the new OmniFocus 3 with tags will give me the same functionality without using the naming convention.
Image Source: http://bit.ly/2sc3gQ7