Due Dates Collaboration

I think that it is possible to give quick and accurate estimations for in-my-area-of-expertise tasks.
I agree that we cannot give considered estimations in the "desperately understaffed" environment where everybody tries to keep his head above the moving sands around. ;-)

Yep. And, just to expand, in a multi-multi-multitasking environment, realistic estimates and intuitive estimates diverge wildly.

For example, there's Gerald Weinberg's rule of thumb that says that if you have five programming projects, you're losing 75% of your time in multitasking, and each project is getting five percent of actual time.

So in a forty hour week, each project will get the equivalent of two hours--IF you only have five projects, and how many people have ony five projects?

Of course, you could work more than forty hours, and many people do, but if you work eighty hours, odds are that each project will get, oh, two and a half hours of work-equivalent, because productivity drops off a cliff after roughly the sixth hour of work each day. In fact, they might go down to one and a half hours of work-equivalent, because true productivity, not just productivity per hour, drops with too many hours. There's evidence that people get more done in a thirty hour week than in a forty hour week.

If just creating that estimate will call for four hours of solid work, then according to that rule of thumb, that estimate will take that project's allotment for two full weeks. And that's the ONLY thing that will get done for that project. And then the estimate itself should account for the project getting one day's worth of work per month.

That sounds...ridiculous. Simply ridiculous. Just ludicrous.

And then it's two weeks later, and you've just barely gotten the estimate done, and you realize it's not ridiculous, and you want to crawl under your desk and sleep the sleep of the depressed for the rest of the quarter.
 
Wow, thank you so much for all the responses! I've needed some time to read through all of them. ;-)

Let me add the following:

1. Due dates are absolutely ok for me if other peoples work depend on them, for example when several following tasks have already been scheduled (or even contracts have been made).
2. It's not that my colleagues are unhappy with me. In fact my colleagues (and also my bosses) really appreciate that I'm a very well self-organized employee (thanks to GTD, especially that I won't forget a single task!).

The issue is, that non-GTDlers don't distinguish between tentative and fixed due dates. They just put notes into their calendar (or project plan) to organize their tasks. That's it. The question is, how to integrate these due dates into my GTD system (and here I'm talking about the tentative due dates from non-GTDlers).

For me the best proposal would be to interpret them as "come back to person X *before* date Y to give status about task Z."
 
For example, there's Gerald Weinberg's rule of thumb that says that if you have five programming projects, you're losing 75% of your time in multitasking, and each project is getting five percent of actual time.
IMHO it's too simplistic. It depends on the rate of project switching. If you do Project1 work on Mondays, Project2 on Tuesdays, Project3 on Wednesdays etc. you lose no time on multitasking. But If you do Project1 work at 9:00 each day, Project2 at 10:00 each day, Project3 at 11:00 each day etc. you probably lose 33% of the time on multitasking.
 
IMHO it's too simplistic. It depends on the rate of project switching. If you do Project1 work on Mondays, Project2 on Tuesdays, Project3 on Wednesdays etc. you lose no time on multitasking. But If you do Project1 work at 9:00 each day, Project2 at 10:00 each day, Project3 at 11:00 each day etc. you probably lose 33% of the time on multitasking.

I don't agree that you lose zero time by switching tasks at day boundaries. A complex train of thought that's sixteen hours old, and that is allowed to marinate without being overwritten even while you're off-duty, is a lot easier to pick up than a complex train of thought that's seven days old, especially since the seven-day-old thoughts have been overwritten four times with four other complex trains of thought, in the same context.

Imagine that you're writing five novels. By Monday evening, Novel 1, Jane and John have just declared their undying love for each other, while facing death at the hands of the villainous shoestring salesman. Tuesday evening, Novel 2, Fred Smith has just finagled his way into the art museum, armed with the keycodes for the room where the sketches for the Mona Lisa are stored. Wednesday evening, Novel 3, the puppy that is the protagonist of our children's novel has just been nabbed by Animal Control. Thursday evening, Novel 4, the Senator has successfully murdered the reporter about to reveal his scandalous past, but the elaborate alibi that he set up with his girlfriend and his barber is falling apart. Friday, Novel 5, the pieces of the scientific puzzle that is the zombie cure are just coming together, as a century-event blizzard looms.

Monday morning, aren't you going to say, "Wait...Jane and who, again?" Wouldn't you be infinitely clearer if you had spent all week with Jane and John?
 
I don't agree that you lose zero time by switching tasks at day boundaries. A complex train of thought that's sixteen hours old, and that is allowed to marinate without being overwritten even while you're off-duty, is a lot easier to pick up than a complex train of thought that's seven days old, especially since the seven-day-old thoughts have been overwritten four times with four other complex trains of thought, in the same context.
I'm a monotasker so there's no point to convince me that MULTITASKING IS BAD. ;-)

Imagine that you're writing five novels. By Monday evening, Novel 1, Jane and John have just declared their undying love for each other, while facing death at the hands of the villainous shoestring salesman. Tuesday evening, Novel 2, Fred Smith has just finagled his way into the art museum, armed with the keycodes for the room where the sketches for the Mona Lisa are stored. Wednesday evening, Novel 3, the puppy that is the protagonist of our children's novel has just been nabbed by Animal Control. Thursday evening, Novel 4, the Senator has successfully murdered the reporter about to reveal his scandalous past, but the elaborate alibi that he set up with his girlfriend and his barber is falling apart. Friday, Novel 5, the pieces of the scientific puzzle that is the zombie cure are just coming together, as a century-event blizzard looms.

Monday morning, aren't you going to say, "Wait...Jane and who, again?" Wouldn't you be infinitely clearer if you had spent all week with Jane and John?
OK, what's your advice? What is the optimal rate for novel-switching? 15 minutes? One hour? Two hours and seventeen minutes?
My advice is: don't switch. Write novels serially. MONOTASK as long as you can.
 
I'm a monotasker so there's no point to convince me that MULTITASKING IS BAD. ;-)


OK, what's your advice? What is the optimal rate for novel-switching? 15 minutes? One hour? Two hours and seventeen minutes?
My advice is: don't switch. Write novels serially. MONOTASK as long as you can.

Monotask. Yes. Exactly.

But if the employer won't allow that, then it's necessary to acknowledge the absolutely disastrous effect that multitasking will have on productivity. Pretending it's not there just leads to Lucy and the chocolate factory.
 
The issue is, that non-GTDlers don't distinguish between tentative and fixed due dates. They just put notes into their calendar (or project plan) to organize their tasks. That's it. The question is, how to integrate these due dates into my GTD system (and here I'm talking about the tentative due dates from non-GTDlers).

For me the best proposal would be to interpret them as "come back to person X *before* date Y to give status about task Z."
I would phrase it "Waiting for person X to give status about task Z due date Y". These are waiting fors in your GTD system and therefore need reviewed weekly, not just chased up near the stated due date. The weekly review is important because plans can change, the task may have altered or not even be needed any more, or *gasp* even finished ahead of schedule.

One other thing... are you absolutely sure you need to keep track of all these tasks? If you're keeping track of a joint project that you don't own, you've done your bit on and you don't need to do any more with then maybe it would be better keeping it out of your system altogether.
 
But if the employer won't allow that, then it's necessary to acknowledge the absolutely disastrous effect that multitasking will have on productivity. Pretending it's not there just leads to Lucy and the chocolate factory.
My take on this: I "acknowledge the absolutely disastrous effect that multitasking has on productivity" so I don't pretend. My professional skills allowed me to choose employers who understood the value of monotasking and - as an employer - I understand it too.
 
It sounds like this discussion has veered into the evergreen subject of time estimates. In my experience, almost everyone comes up with a "typical" time estimate, without thinking about the variance of that estimate. One easy way to build this in:

estimate = (minimum + 2*typical + maximum)/4
 
@treelike: In my example, person X is the project owner and I'll have to perform task Z for it. The proposal was about how to integrate that single task in my GTD system if possible without setting hard due date Y.
 
@treelike: In my example, person X is the project owner and I'll have to perform task Z for it. The proposal was about how to integrate that single task in my GTD system if possible without setting hard due date Y.
Why are you avoiding hard due dates? Because you know they are unrealistic? So person X is insane?
 
@mcogilvie: It's not about time estimates, but tentative vs. fixed due dates. (Although your formula for estimates looks great! ;))

Thanks! Let me suggest that the use of "tentative" and "fixed" may be a bit misleading. Really, these should be "agreed" and "firm". Firm means it can't move. Everybody should have a clear understanding of what this means. If you can't remember when a deadline is firm, put that word in the project or action entry. I find I don't need to do this. If I agree to a deadline, I have an obligation to meet it, or to discuss the matter with the people I made the agreement with. GTD is about being responsible, so you can be free. None of this "sorry I didn't get back to you." You own your agreements.
 
@treelike: In my example, person X is the project owner and I'll have to perform task Z for it. The proposal was about how to integrate that single task in my GTD system if possible without setting hard due date Y.
Ah, OK apologies for misunderstanding. In that case your proposal seems reasonable to me, if you mean incorporating the tentative date into the next action or project statement for the task.

From earlier....
2. It's not that my colleagues are unhappy with me. In fact my colleagues (and also my bosses) really appreciate that I'm a very well self-organized employee (thanks to GTD, especially that I won't forget a single task!).
It's curious that they have not picked up on your GTD habit then, no?
 
@TesTeq: I'm not avoiding hard Due Dates if they are really fixed (or "firm" - meaning, they really cannot move.) I just want to keep my calendar free from tentative dates so that it doesn't get diluted.

@mcogilvie: "agreed" dates are in fact "firm" dates for me (because somebody expects something from me at that specific date, and no single day later).

@treelike: actually some have (incl. my boss), but far from all. ;) And I don't want to convert them all to use GTD. Everybody should do what works best for him or her. This topic really is about collaboration between GTDlers and non-GTDlers. And I think the Due Dates topic (and keeping your calendar clutter-free) is where GTD is most different from other task management systems.
 
@TesTeq: I'm not avoiding hard Due Dates if they are really fixed (or "firm" - meaning, they really cannot move.) I just want to keep my calendar free from tentative dates so that it doesn't get diluted.

@mcogilvie: "agreed" dates are in fact "firm" dates for me (because somebody expects something from me at that specific date, and no single day later).

@treelike: actually some have (incl. my boss), but far from all. ;) And I don't want to convert them all to use GTD. Everybody should do what works best for him or her. This topic really is about collaboration between GTDlers and non-GTDlers. And I think the Due Dates topic (and keeping your calendar clutter-free) is where GTD is most different from other task management systems.
Let's be less abstract. If I am responsible for a visitor to my department, that is a hard deadline, because announcements have been sent, a plane ticket purchased, et cetera. If I am planning to finalize the visitor's schedule the day before arrival (not uncommon), that is a pretty hard deadline. However, if I had some emergency that day, I would turn the schedule over to other people, and it would get done. On the other hand, suppose I agree to discuss an issue at the next monthly meeting of a committee, but for some reason not all the information needed is available. The issue can be delayed a month. I inform those who need to know, take necessary actions, reschedule, and move on. I can treat these agreements differently because I understand the difference between them and react appropriately in both cases. The idea of appropriate reaction is basic to GTD, often captured as mind like water.

On the other hand, your issue seems tactical: how do I remind myself how firm a deadline is? I have multiple calendars, with multiple colors. A big event I'm involved in might be an all-day event on my "Information" calendar. A visitor's scheduled talk is actually on a calendar I'm subscribed to, even though I may or may not have responsibility for that visitor. I have two calendars in different light colors, "Tentative" to hold a time slot, and "Maybe" for optional. Perhaps you could use two or more calendars for your preferred levels of firmness. Or have due dates only on your lists for less firm due dates, with due dates on your calendar for the more firm. Do what you have to do to get things off your mind, trusting that you will deal appropriately with them. Your systems will evolve with you as you gain experience.
 
@sparkle: If I understand correctly, your question is how should you handle working in a group where the group leader asks for target dates which you feel you don't need and will clutter your calendar because you practice GTD, unlike others in the group.

When I'm in situations like that, I offer a realistic completion date and add it to my calendar because an agreement that includes a date is a hard landscape item. It's that simple.

This hasn't caused my calendar to feel cluttered or otherwise undermined my system. Quite the opposite: it increases my confidence in my system by providing me with information that I need, when I need it. Yes, sometimes it means I need to renegotiate agreements and move things around in my calendar. Trust me: this is OK, and won't break your GTD system.

Also I would suggest thinking about the possibility that asking for completion dates isn't just about helping group members stay organized. The person running the project needs some way to know what to expect and when. He or she is likely accountable to someone else, like a person even higher up in the organization, or customers, or investors, or somebody who won't be satisfied with hearing that "it'll get done when it gets done." So offering completion dates and managing them is not only consistent with GTD, it's also good teamwork.
 
@mcogilvie: Thanks for your example. Let me think about this further:

Assume the visitor is coming this friday, so it's a hard deadline for all tasks needed to prepare the visit.
Furthermore assume, you had a meeting 3 weeks ago about let's say purchasing new software tools your team colleagues might need. You've agreed to take the action to identify which tools might be useful. You've said, you'll need for this task 4 weeks.
As it happens, this deadline is exactly the same date your important visitor is coming. But you didn't knew this before.

My point is: the visitor is a hard deadline. Perfectly ok. The tools are a "weak" deadline. You knew in advance that it wouldn't matter to postpone the date some days (or even weeks).

But now, you've both dates in your calendar "competing" with each other (let's further assume you're really busy this week an can only concentrate on one of these two issues). Of course, you can re-negotiate them or mark them with different colors in your calendar.

However, I want my calendar to be clean and simple and to reduce the possibility for these kind of situations in advance, if possible. I would like to have the tools tasks on my next action lists where I can intuitively decide, what to do next (without having fixed dates). That's how I do it with all my personal tasks (and it works great!).

But I agree to @bcmyers2112, that for good teamworks sake, the best common solution might be to include completion dates for these "collaboration tasks", although it's different from how I handle my personal tasks.
 
However, I want my calendar to be clean and simple and to reduce the possibility for these kind of situations in advance, if possible. I would like to have the tools tasks on my next action lists where I can intuitively decide, what to do next (without having fixed dates). That's how I do it with all my personal tasks (and it works great!).

I'm not sure I understand. Are you saying you feel that agreeing to a due date means you can only manage the action on your calendar? That's not what I'm suggesting. I would advise you to include an action with an agreed-to completion date in one of your next actions lists so you can review it alongside all of your other actions.

And I'm using the term "calendar" for simplicity's sake. If you are using a digital list manager that allows you to set a due date for an action, you can manage it there rather than putting it in your calendar if that would be easier for you.

You needn't give up on choosing your work actions based on situational factors and intuition merely because you've agreed to a due date. While I take due dates into account when reviewing my next actions, I don't always work on things with a due date first. Oftentimes things without an explicit due date take priority.
 
@mcogilvie:

My point is: the visitor is a hard deadline. Perfectly ok. The tools are a "weak" deadline. You knew in advance that it wouldn't matter to postpone the date some days (or even weeks).

But now, you've both dates in your calendar "competing" with each other (let's further assume you're really busy this week an can only concentrate on one of these two issues). Of course, you can re-negotiate them or mark them with different colors in your calendar.

However, I want my calendar to be clean and simple and to reduce the possibility for these kind of situations in advance, if possible. I would like to have the tools tasks on my next action lists where I can intuitively decide, what to do next (without having fixed dates). That's how I do it with all my personal tasks (and it works great!).

Two thoughts:

David Allen says the calendar is for hard landscape. By that criterion, The visitor goes on the calendar; the tools deadline does not.

At some points, individual preferences on gtd tools matter, and they can matter a lot. I use list software (Omnifocus) that supports both due and deferred dates, and I use both often. Project due dates are inherited by next actions, but are overriden by next action due dates. When combined with a good weekly review (1 hour this weekend!), I find that's enough for me to have a good awareness of what's coming my way. Of course, that's not the only way to go. A PA for a top executive in an Outlook environment might have 5-10 items on his or her calendar that have to be handled today one way or another.
 
Top