• If you are new to these Forums, please take a moment to register using the fields above.


No announcement yet.

Structuring events in a project

  • Filter
  • Time
  • Show
Clear All
new posts

  • Structuring events in a project

    From what I understand structuring events in a project is discouraged in GTD. This means no automatic sequencing of tasks and not dependent tasks. The idea is that you find your next actions on your weekly review or you think of checking for the next task after completing one.

    This seems like a counter-productive approach. One of the goals of GTD is to make things automatic so you don't have to think about what you might be missing. On this basis I have used Life Balance in the past and currently Omnifocus to manage my GTD. I use their ability to set up dependent and sequence tasks to set up my project and then let the tasks flow automatically. I still do a weekly review but it is not necessary to keep the project moving along. This way I avoid a problem if I complete my task on a Monday but don't do my review until Friday.

    Why is treating projects like a project manager would frowned upon in GTD?

  • #2
    Why is treating projects like a project manager would frowned upon in GTD?
    I've never heard David Allen say to not use "project managers".

    He simply suggests to not put your dependent or "future" or dependent actions on the same lists you are looking at your choices for "Next Actions", as if they can all be done now. Those are completely different choices and if you blend them all, you then have to be willing to slog through what's a choice now versus in the future, unless the list clearly delineates what's Next versus Future/Dependent. Make sense?

    If you do use something like OmniFocus, which will allow to capture both Next and Future/Dependent actions related to a project in one place, David also suggests that you should be flexible to what will "show up" intuitively that's your best Next Action. The best plans may never predict every microscopic step that will show up, or changing winds about which course to take. So even though you've identified something as the "B" that comes after "A", you may find there is a step in between those that you didn't plan to take that makes more sense. So just don't hold yourself to a rigidity with your plans.

    One other thought that I've heard David say often over the years is to plan as much as you need to to get your mind off the project. So if that means sitting down at the start of the project and planning out the 472 steps you will need to take, then do that. Or, if all you have your attention on is the Outcome (what does done look like) and what's the first Next Action (what does doing look like) then only do that.

    Does that help?



    • #3
      Originally posted by beirne View Post
      From what I understand structuring events in a project is discouraged in GTD.
      This is covered in Chapter 3, especially the 'Organizing' section:
      (...) Organizing usually happens when you identify components and subcomponents, sequences or events, and/or priorities. What are the things that must occur to create the final result? In what order must they occur? (...)
      This is the stage in which you can make good use of structuring tools ranging from informal bullet points, scribbled literally on the back of an envelope, to project-planning software like Microsoft Project. When a project calls for substantial objective control, you'll need some type of hierarchical outline with components and subcomponents, and/or a GANTT-type chart showing stages of the project laid out over time, with independent and dependent parts and milestones identified in relationship to the whole.(...)

      -- GTD, pgs 74-75
      You might find it useful to review that section of GTD with an eye for how sequences of events and dependent actions are addressed.



      • #4
        Kelly and Roger,

        Thanks for the clarification. I have been listening to the makers of software that claims to be GTD-compliant who say that structuring events like Omnifocus would be against GTD. I'm glad to get back to the source to find out what is correct. I've basically been doing this part OK, which I'm glad to hear.



        • #5
          Yup. Lots of wonky interpretations out there. Many good intended, I'm sure, and others intended to sell software that was built a certain way.

          Really, just follow your gut about what's best and next for you.

          Happy to answer questions here on the DAC forums. It's what we're here for.