@Longstreet -- For me, that requirement that you promptly figure out the next action and reclassify the project is a huge advantage. I promise myself that I will define my next remaining action before closing a project folder.
But you could give yourself the "always figure out next action" requirement no matter how you use GTD, right? That could be useful regardless.
@context -- yes, I can see how this action+project approach would be problematic for someone working from multiple locations or with multiple next actions to take.
I guess I'm lucky in that my productive life is at a computer with a phone next to me and my contacts nearby. I do use a naming convention for my next actions so all similar actions get grouped together: "call", "email", "visit" (for the people who never reply to emails...). So depending on what mode I'm in, I can knock out a set together.
It's conveniently rare in my case that I run into situations that have multiple next actions. I'm also lucky in that I haven't run into any issues with branching.
One branching point: delegating a sub-project. I just kept the email where I sent the person the information in the same folder, then used that as the basis for calendar reminders to follow up with the person. If I get status updates, those go in the folder and revise my reminder (and possibly my next action)
Rarely, I do need branching for sub-projects: made a duplicate folder (again with a cross-reference) just so I have the history of that branch up to that point. For whatever reason, I haven't run into trouble (yet) with this approach. I can definitely see how it could get out of control for frequent or multi-branching, though; I'd lose a sense of what's going on with the overall project.
@everybody -- thanks again. If I ever end up in a "power user" situation I can see how doing it the other way around would make more sense, so all your explanations help!
Reply With Quote
Bookmarks