Handling dependent tasks that are not part of projects

Discussion in 'PUBLIC: Discuss the GTD Methodology' started by Ethan R, Oct 20, 2019.

Tags:
  1. Ethan R

    Ethan R Registered

    Joined:
    Oct 20, 2019
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    For dependent tasks that are part of a project, the general advice seems to be that they should go in project support materials until it's time for them to become next actions. But what about dependent tasks that aren't part of projects?
    For example, let's say I've just signed up for LinkedIn, and I have a next action to fill out my profile. However, I've also just gotten a job offer and I need to decide whether I'm taking it. It would be silly for me to fill out my profile if I'm about to switch jobs, so I decide to wait until I've figured out whether I'm taking the job to do the profile.
    Thus, filling in my profile is no longer actually a next action. But it's also not related to the job decision from a project perspective (say it's under the project "Sign up for LinkedIn" or something). I need to note that the latter is dependent on the former without losing track of it.
    I've considered using the Waiting For list, but I like keeping that purely for people dependencies. I'd like to figure something out that doesn't depend on me just hoping to catch it in Weekly Reviews. Thoughts?
     
  2. Oogiem

    Oogiem Registered

    Joined:
    Jun 3, 2008
    Messages:
    4,805
    Likes Received:
    558
    Trophy Points:
    113
    Gender:
    Female
    So create a waiting for action in the linked in project that says waiting for decision on job off (or project Y to generalize) Then in the job offer project add an action after the decide on job offer, to go check linked in project.
     
  3. AnneMKE

    AnneMKE Registered

    Joined:
    May 27, 2016
    Messages:
    83
    Likes Received:
    59
    Trophy Points:
    18
    Location:
    Milwaukee, WI
    I put those in Waiting For. If separate “people-dependent” waiting-fors are really helpful to you (as opposed to just feeling clean, :) ), you could have two WF lists, one for people and one for the rest.
     
  4. Ethan R

    Ethan R Registered

    Joined:
    Oct 20, 2019
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    Oogiem, I like this solution for situations where both tasks are part of a project, but what about when one of them isn't? Obviously in the example the job offer task would belong to a project, but let's say for the sake of argument it was a standalone task.

    AnneMKE, a separate WF list makes sense to me. There probably wouldn't be too many tasks in this list at one time, as most dependent tasks are part of the same project as their parent task and would just go in project support.
     
  5. Oogiem

    Oogiem Registered

    Joined:
    Jun 3, 2008
    Messages:
    4,805
    Likes Received:
    558
    Trophy Points:
    113
    Gender:
    Female
    The mere fact that there is more than one action, a waiting for item and an action to be taken later makes it a project.

    There is nothing that says a project must be something big. I have tiny project with only 2 actions all the time.
     
    TesTeq likes this.
  6. TesTeq

    TesTeq Registered

    Joined:
    Oct 4, 2003
    Messages:
    4,799
    Likes Received:
    529
    Trophy Points:
    113
    I totally agree. WaitingFor and a linked Next Action make a Project.
    Alternatively you can define a standalone WaitingFor consisting of two parts:
    Wait for [something 1] then do [something 2].
    When [something 1] occurs you just convert this WaitingFor into Next Action by deleting its first part and moving it to Next Actions list.
     

Share This Page