[yucca]

Originally Posted by jpathomas

I went looking for a replacement and laded at OmniFocus. I listen to a lot of podcasts, I've been listening to Merlin talk about GTD for a couple years I think, so I'm not unfamiliar with the GTD concepts. I have not read Allen's book, but in truth I'm not looking for a new system, I'm looking for new software.

To maximize returns with OF, it is worthwhile to get the book. The further you move away from tactical day-to-day stuff, the more similar (and familiar!) GTD and FC become. However, as you already know, there is huge change in mindset beginning with reviews; and the gulf only gets bigger still with actual task management.

I don't think it is possible to really "get" GTD without the book and without committing to trying it out for at least a few months. The longer you are in FC, the harder it is I think (and I used FC for more than 20 years!).

If you want to try GTD without completely committing, apply GTD religiously to just one significant input. Phones, e-mail or snail mail come to mind. I suggest e-mail as everything is and stays electronic that way. I started with personal e-mail (a month or so while re-reading the book), added work e-mail (another month of rereading the book and rejiggering contexts), and then went whole hog GTD.

I still use the old FC approach for values and for setting life goals, but am entirely GTD at lower levels. Good luck, and hope you find this helpful.

Thank you Yucca, I'll take your advice and read the book.

[colicoid]

First I must say that I am not familiar with Franklin/Covey.

Originally Posted by jpathomas

Question #1 Priority.

Priority in OF and GTD is handled by the order that you put tasks while in planning mode. If a task really is of higher priority than some other task you should tend to the high priority task first (if your context allows it). This is one of the benefits of serial projects. You can still view and complete lower priority tasks, if you want to, by adjusting filters. Flags are a non GTD addition that a lot of people use for priority flagging, but flags can be used in many different ways. Other ways to deal with priority, and get around the fact that OF doesn't support it, includes special priority sub contexts or strict naming conventions paired with searches.

Originally Posted by jpathomas

Question #2 Delegation. I have things on my task list that need to get done, but not by me. I need to track it, it's a step that needs to be completed, but not one that I can complete myself. In F/C I'd mark that as delegated. How can I indicate that I've delegated an action Item in OF? Yes, I could flag it, but I don't want to unflag it later, I want it marked, for all time, as delegated.

OF is a personal task management system and does not support this directly (yet) but there are of course workarounds. I have a special @waiting-for context with a sub context for each person a regularly delegate to. People that I only delegate one or two tasks to I put in the general @waiting-for context. This works extremely well for me.

Originally Posted by jpathomas

Question #3 In Process. Sometimes my task is to call someone, and I end of leaving them a voice mail, and waiting for them to call me back. In F/C I'd mark that item as In Process. In OF it looks like it's either done, or not done.

In GTD I suppose only one task can be in progress at any one time which is the one you are actually working on. All you need to do is to be more liberal about what you call a project; and you won't need an "In Process" flag thingy. E.g.:

1. Phone X and tell him about Y.
You made the phone call and he didn't pick up so you left a voice mail.
The task of phoning is now done and marked as completed but a new task is entered instead.
2. Wait for X to phone me back about Y.

See, you now have a mini project instead. The action involved more steps than you had initially anticipated. This example is of course simplistic but this is one of the major strengths of GTD. No matter how much a small task grows; the system is able to cope.

If it is really important that you actually talk to the guy; voice mail isn't enough. You would reschedule the task and make another phone call in two days or whatever. Util you get hold of him the task is not done. You could make entries in the note field if you want to keep track of failed tries to reach him.

GTD does require you to think differently about certain things reading the book is probably good advice.

Thank for that explanation Colicoid, it adds a few more pieces to the puzzle for me.

In regard to this...

1. Phone X and tell him about Y.
You made the phone call and he didn't pick up so you left a voice mail.
The task of phoning is now done and marked as completed but a new task is entered instead.
2. Wait for X to phone me back about Y.

It seems to me that this one of those places where you can use a context like @Waiting for Return Call? I suppose it would depend on how you keep notes on your tasks.

I would be concerned about making smaller and smaller tasks, but I see your point.

I'll order the book today.

[oschultz]

Phone call follow ups are one of my favorite things about using Omni Focus to track tasks. Often I'll have something like "Call XPerson about X" with a context of "PersonalCalls" or "BusinessCalls". Once the call is made, if I don't get to talk to them, I put a hyphen after the task, use my Textpander program and type "lft" and it automatically writes out "Left Message June 11, 2009" (The date is set up to auto fill the current date) then I change the context to "WaitingFor" and move on to the next task. Now that may seem like a lot, but in practice it only takes seconds and provide and excellent reference system for following up with people. It is very helpful when pushing projects along to say "Yes, I left you a message on the 11th of June and have not heard back." etc.

[colicoid]

Originally Posted by jpathomas

I would be concerned about making smaller and smaller tasks, but I see your point.

Finding perfect granularity is one of the hardest things, but that is not about the system - that is about you. :)

[whpalmer4]

Originally Posted by oschultz

Phone call follow ups are one of my favorite things about using Omni Focus to track tasks. Often I'll have something like "Call XPerson about X" with a context of "PersonalCalls" or "BusinessCalls". Once the call is made, if I don't get to talk to them, I put a hyphen after the task, use my Textpander program and type "lft" and it automatically writes out "Left Message June 11, 2009" (The date is set up to auto fill the current date) then I change the context to "WaitingFor" and move on to the next task. Now that may seem like a lot, but in practice it only takes seconds and provide and excellent reference system for following up with people. It is very helpful when pushing projects along to say "Yes, I left you a message on the 11th of June and have not heard back." etc.

If you want to do this all with Omni-supplied bits, you could simply do cmd-| to insert a short date/time string such as 6/14/08 1:09 PM - see Insert Time Stamp under the Edit menu for other format options. I stumbled on it while looking for something else, and find it very handy when documenting my phone interactions with companies that are shall we say less successful than Omni at providing great customer support...

[colicoid]

palmers comment made me remember:
For some special types of tasks that goes back and fort a lot I keep a history in the notes field rather than turning them into projects. The only thing with that is that you must remember to look at the notes field.

I work for a software company where I manage the release of a product and one important task is to make sure the bugs are fixed. The go through the following phase usually.

1. Bug found
Entered into OF with a context @not assigned. Small description of how to reproduce, who found it etc. in notes field.
2. Prioritized
Reordered in planning mode and possibly get red flag if not optional.
3. Assigned
I assign it to developer X by sending him an email. I put a context of
waiting for:X.
4. Bug fixed
X emails me that he has fixed the bug. Naturally, I don't believe him so it needs to be reviewed by someone else. "Fixed by: X" goes into notes field.
5. Review
I email the bug to developer Y and ask him to verify the solution. I put VFF: (Verify Fix For) infront of the bug description and I drop it into context @waiting for:Y to indicate that Y is now working on that bug.
6. Reviewed
Developer Y reports that it was a nice solution.
I mark the task done and put "Reviewed by Y" in the notes field.

Then of course there are variations to this and the bug wasn't fixed etc. The thing is that I have to deal with this very quickly and don't have time to fiddle with projects and making new tasks. So keeping a history in the notes field works fine here. Besides keeping the bug description in the task description gives me very nice lists in context and planning mode.

For all other stuff though I do it the normal way.

[whpalmer4]

Hmm, it must be a barrel of laughs working somewhere where the rate of bug discovery is so high you don't have enough time to click the "add action" button :-)

I can see some advantages to doing it your way, however. If you're looking at an action list covering lots of bugs, you do have the whole history right there without having to back to the project. For my bug tracking, I usually keep the notes on the project itself so that they are still visible even in Next Action view. Unfortunately, they aren't so easily gotten when in a context view unless one does focus/switch, which is pokey on my machine. If I had to go to a bug scrub meeting and discuss the status of dozens of bugs in a short time, having a compressed view like yours would be very nice, I think. I'm not completely convinced the steps to maintain it that you described are appreciably more efficient than what I do, but I'll wholeheartedly agree that it isn't important that I be convinced of that :-) I discuss it only because I've found hearing how others use the tools very helpful in developing my own workflow, and the more variety the better.

[colicoid]

In this particular situation the question is; many projects or many tasks?

I really wanted to use GTD-canonical many-projects approach for the bug system but found it impractical in many ways.

Originally Posted by whpalmer4

Hmm, it must be a barrel of laughs working somewhere where the rate of bug discovery is so high you don't have enough time to click the "add action" button :-)

It is a fair amount yes :), most of them small but it is a pretty large product. For each bug though the number of interactions multiplies and causes me quite a bit of work. For example when the reviewer comes back with "it was not fixed", do you uncheck the "fix bug" task or do you add a new "fix bug".

The UI of OF lends itself more to having hundreds of tasks on the screen rather than hundreds of projects.

In the many-projects approach the need for folders will arrise.
I really dislike dropping folders and it is hard to add a new project into the correct position in a folder structure using the quick entry.

Using the many-projects approach, whenever I create a new bug I would put the bug description in a project rather than in a task. This will give me hundreds of projects with a task called "fix bug" or something similar. This in turn will force me to use "group by project" in context mode which will become a right mess with the long project names and some deeply nested folders. I also cannot complete a bug in context mode and I cannot jump to a project from context mode. (Command-alt-R), I can only to a task so if there are no tasks left in a project I have to go to planning mode and search for it.

I certainly don't think I have nailed this workflow yet. Any advice that would help to improve it is very welcomed.