It's probably no surprise which way I'm leaning in this, so I'll try to come up with something new and useful to say.
The idea that a system-enforced One Next Action somehow saves the user from having to decide which Next Action to proceed with is, I think, objectively inaccurate. The user still has to make this decision -- they just make it earlier on, when they decide which of their project's Next Actions they'll promote into the system. Whether that's a good time to make that decision is a matter of some debate, and I suspect there's enough variance between users and what they're up to that there'll be people on all sides of the fence.
All that being said, I can think of at least one core GTD artifact which actually does promote this sort of linear approach. And that artifact, my friends, is the checklist.
And, yes, a checklist doesn't need to be a strictly-ordered list of Next Actions (indeed, now that I look around a bit, I realize with a bit of a shock that most of my checklists are not ordered at all; hunh) but it is a very common implementation, which I think is worthy of some consideration.
Cheers,
Roger
The idea that a system-enforced One Next Action somehow saves the user from having to decide which Next Action to proceed with is, I think, objectively inaccurate. The user still has to make this decision -- they just make it earlier on, when they decide which of their project's Next Actions they'll promote into the system. Whether that's a good time to make that decision is a matter of some debate, and I suspect there's enough variance between users and what they're up to that there'll be people on all sides of the fence.
All that being said, I can think of at least one core GTD artifact which actually does promote this sort of linear approach. And that artifact, my friends, is the checklist.
And, yes, a checklist doesn't need to be a strictly-ordered list of Next Actions (indeed, now that I look around a bit, I realize with a bit of a shock that most of my checklists are not ordered at all; hunh) but it is a very common implementation, which I think is worthy of some consideration.
Cheers,
Roger