Handling dependent tasks that are not part of projects

[Ethan R]

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?

 

[Oogiem]

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

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.

 

[AnneMKE]

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.

 

[Ethan R]

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.

 

[Oogiem]

let's say for the sake of argument it was a standalone task.

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]

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.

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.