Question about "Due Dates" in a team scenario

[ChuckBerry]

Hi there,

If I understand correctly - GTD recommends not assigning "due dates" to actions, unless it is absolutely necessary (such as a customer meeting scheduled for a specific day).

I initially had a hard time buying into this, but slowly realizing the benefit of this approach when managing personal tasks.

My question is this:
* Before GTD, I used to assign tasks to people in my team and ask for an ETA. The ETA was our informal "contract". Of course, subject to re-negotiation as soon as priorities change, new tasks emerge, etc. If it was not re-negotiated, I used to check with them on that date to ask about the status.
* Does GTD recommend that I do *not* ask for ETA when assigning tasks to people in my team, and that people in my team should *not* commit to a due date for their deliverables?

Thanks!

[Moka]

My team when not assigned with due dates can do anything but not those tasks

I decided to always assign due dates even when they not needed.

[mcogilvie]

My question is this:
* Before GTD, I used to assign tasks to people in my team and ask for an ETA. The ETA was our informal "contract". Of course, subject to re-negotiation as soon as priorities change, new tasks emerge, etc. If it was not re-negotiated, I used to check with them on that date to ask about the status.
* Does GTD recommend that I do *not* ask for ETA when assigning tasks to people in my team, and that people in my team should *not* commit to a due date for their deliverables?

DA recommends that you act appropriately. While the language of your first point sounds very flexible, "commit to a due date for deliverables" is not. As a manager, you will help your team by giving clear guidance on priorities and deadlines: "We need this by XX because..." or "I'd like to have this by YY because..." Of course, some team members and some tasks may require more guidance: "I'll check back with you after the trip to ZZ to see if the parameters have changed."

[clango]

I think the point is to evaluate when it is the right time to start a certain action to be safe that by the due date I produced the desired outcome.

So, I'd focus more on start date keeping the due date as a part of the outcome.

[CJSullivan]

Of course, if you're managing a team project that has a critical path, you'll want to be cognizant of those dates and manage deliverables accordingly.

I may be wrong, but it seems to me that managing a project and just having loose deliverable dates is a recipe for disaster!...

[ChuckBerry]

Hi Moka, mcogilvie, clango, CJSullivan: Thank you very much for your replies, I appreciate it.

Have a nice weekend!

[cwoodgold]

There are other ways to communicate priorities. For example:

"What were you planning to work on in the next few days? ... This is more important than any of those things. I'd like you to work on this first, please, and get it back to me as soon as possible."

"See if you can fit this into your schedule, although it's lower priority than projects A and B."

"How much actual work time do you think it would take you to do this? ... Never mind: I'll get someone else to do it. I need you to focus your energy on A and B."

"As soon as you've finished A, I'd like you to work on this and get the results to me
before you start on B."

"This is important. I suggest you spend at least 50% of your time on it until it's
completed."

Also, as mcogilvie suggested, it's good to give the actual reason why you need it soon.
"As soon as we have this from you, these three other people and I will be able to
start on this project we've been eager to get going on ..."

Also, after you actually receive the results, thank the person, publicly give them
credit and give them some information about how you've used it.
"Thanks. This is just what I wanted. Now I can start on ..."
"By the way, that stuff you gave me last week was really useful because ..."
"This has been a team effort; I'd like to thank the following people who
contributed ..." Then they may be more willing to do stuff for you the
next time.