> without solid understanding of who owns what.
I think this is the root problem right here. But I donít think itís inherently related to GTD implementation details. Weíre pointed in the right direction, but I think it might be worthwhile to wallow in the details a bit.
Letís start with what GTD has to say about delegated tasks, waiting-for, and delegate projects:
Once you've decided on the next action, you have three options: [Ö]
2: Delegate it. [Ö] If the action will take longer than two minutes, ask yourself, Am I the right person to do this? If the answer is no, delegate it to the appropriate entity.
[Ö]If you do delegate an action to someone else, and if you care at all whether something happens as a result, you'll need to track it. [Ö] You'll see that a significant category to manage is "Waiting For."
Delegated Projects: If you're a senior manager or executive, you probably have several projects that you are directly responsible for but have handed off to people who report to you. While you could, of course, put them on your "Waiting For" list, it might make better sense to create a "Projects -- Delegated" list to track them: your task will be simply to review the list regularly enough to ensure that everything on it is moving along appropriately.
And letís consider what youíve told us about your process:
> I put a name of the subordinate and write in the notes section all her delegated projects (I have 3 direct reports now). Against each one I put a task (it could be a bunch of next actions) for the next week.
This sort of behaviour -- ďI delegate this project to you, and hereís your next actions for the weekĒ -- is classic micromanagement and/or miscommunication. It shows up everywhere, so donít feel too bad about it. Itís pretty much inevitable that this will result in that lack of a solid understanding of who owns what.
The good news is that it should be fairly straightforward to resolve. It just requires a couple of things:
1. A decision about who is going to generate next actions: you, or your subordinate? (Or jointly is also an option, but it can be tricky.)
2. Understanding and agreement with the above decision between everyone involved.
Either decision is fine. And it doesnít need to be written in stone; after a period of time, you may feel like you can hand-off the details of next actions to your subordinate. But note that decision must also be clearly communicated and understood.
Once thatís all cleared up, the GTD implementation is easy. If youíre producing and delegating the next actions, theyíre in Waiting For. If itís up to the subordinate, itís a Delegated Project.
After all that, I suppose I should also answer your specific questions:
> 1. How often do you check your @Waiting list?
I usually go through it two or three times a day. Once in the morning, to remind me of whatís around and what might come in during the day. Once after lunch, when thereís still time to bother people about specific things. And once at the end of work, to see if anythingís running late that I might need to deal with tomorrow.
2. Do you put follow up Next Actions into the system or follow up straight from @Waiting list when reviewing it?
Most of the time thereís either nothing to be done or itís a less-than-two-minutes task to check in on it. Usually the only time thereís a Next Action generated is when I actually receive whatever it is Iíve been waiting for.