I recently moved a load of actions from a project (things to write about in my tech blog) [1] into my Someday, Maybe Never project, and then it suddenly struck me that maybe it wasn’t a project at all, but a context. It makes sense if you think about it from the Contexts view - when you’re executing, you just look at the context you’re in at the time (calls, errands etc) and because you’ve never given one of your active contexts to the actions, you never see them in your current context context.  read more »

In one of the recent podcast interviews I did with David Allen, we talked about procrastination and how he tries to get people — especially knowledge workers — back to just “cranking widgets.”

I love this term, because, in his humorous way, David captures how any thing we want to accomplish in this world eventually has to manifest itself in an intentional physical activity. Seemingly over-huge super-projects like “World Peace,” “Cancer Cure,” or “Find Mutually Satisfying Vehicle for Jim Belushi” all still come down to physical actions, such as picking up a phone or typing an email.

And David is wise, in that interview, also to highlight the importance of what he refers to as a “‘look-into’ project,” which just means that even deciding if a project is interesting and useful to undertake can be a project in itself. It also means that, even with an outcome of “deciding,” that meta-project still consists solely of physical actions. In this case, it’s the physical actions that help you locate the additional information you’ll need to make a timely and wise decision about whether to proceed at all. In sum, no matter what, it all still should come back to widgets and how they get cranked.

Like a lot of you, I’ve struggled with how you turn “thinky work” into physical action widgets, but here are a few of my favorite task-verbs to get you started in the right direction. They’re presented here in a rough approximation of the order in which I use them in my own “look-into” projects:  read more »

As we’ve noted before, GTD contexts lose a lot of their focusing power when either a) most of your work takes place at one context (e.g. “@computer”), or b) you start using contexts more for taxonomical labeling than to reflect functional limitations and opportunities. As you may have discovered, these problems can collide catastrophically for many knowledge workers, artists, and geeks.

Part of what makes the Natural Planning Model so attractive are the decisions that can be guided by contextual limitations (“I’m near a phone” vs. “I’m at the grocery store” vs. “I’m at my computer”). While it’s definitely a kind of “first world problem” to have, facing the unlimited freedom to chose from any of a bajillion similar tasks from similar projects with similar outcomes is not nearly as fun as it first sounds. Consider the contextual hairballs of certain jobs and tasks:  read more »

Herewith for your approval, a few handy tricks I’ve been discovering for getting the most out of the peerless Omni Outliner Pro/kGTD combo.

And don’t forget — as noted last week — through the end of this month, when you buy any OmniOutliner product from the OmniGroup site, you can use the checkout code 43FOLDERS to get 25% off your order. Disco!

1. “Hiding” fallow projects

In last Thursday’s podcast, “Fallow Projects and the Bread Crumb Trail”, I mentioned how I like to move stalled or clinically-dead projects off my immediate radar screen; it makes it so much easier to focus when only actionable stuff is being tracked actively. Anyhow, lots of people asked for more details on that, so here you go.

In kGTD, you want to create a holding pen for these sick animals by generating a new top-level Project and calling it, say, “Fallow Projects #” (or whatever you prefer, but do include the “pound”) then scooting all those moribund projects thereunder. Cool enough, but, here comes the nifty.  read more »

Putting Geeks in Context

43folders.com - One way around the geek’s problem with GTD contexts? Step away from the computer. (4:37)

More at Odeo.com…

Not all tasks are created equal. Our to-dos all differ in priority, complexity, time requirement, and context, so it’s probably daft to always capture and expose them in an identical way. I have a little trick for dealing with this that’s been working really well for me.

Back in the day, my to-do list was an egalitarian nightmare of inefficiency — verb-centric “next actions” through they all were, I commonly faced a task list that looked something like this:

• call Alice about Foo project
• fix line 125 of bar.php
• fix line 349 of bat.php
• take out kitchen recycling
• buy milk
• buy index cards
• sweep the decks

Now, the problem here might be self-evident to you smarter people, but I was missing an important concept: there is such a thing as too granular a task to track as its own event. In this instance, I was cruftifying my landscape with items that were way too detailed or tiny and, consequently, I’d turned my task list into an undoable roller coaster of un-focus. Just as “projects” are composed of “tasks,” I like to think that “tasks” themselves can often be collected into silos of small “mosquito tasks.” And my solution, as ever: text files and alarms.  read more »

What context do I put my Next Actions in? :: MarkTAW.com

Mark Taw consistently provides some of the most lucid and realistic productivity advice I’ve come across. Today he eloquently addresses a common question of beginning Getting Things Done nerds.

If you have 15 lists, but they’re all full of things that you can do from the same starting point, you have 14 too many lists. It doesn’t matter if it’s a phone call, email, or going to the printers to pick up your business cards, your lists should contain no more detail than that. And don’t complain to me that your list would be too long that way, breaking it up into more lists doesn’t give you any fewer Next Actions, it just lets you procrastinate some of them more by putting them on a list you’ll ignore entirely.  read more »