I'm a big believer that the duration should be an estimate of the actual
time it will take a task to complete once it starts and is NOT the total
time you're allowed to do it in. If I have a task that can start June 10
and is due July 10, is going to take 8 hours to do, and I expect that the
resource will devote their full attention to it once it starts, that defines
a task with an 8 hours duration NOT 1 month, a resource assigned 100%, a
scheduled start of 10 June, a scheduled finish of 11 June ( or start 10 June
8am, finish 10 June 5pm) , and a deadline of 10 July. How strongly I
communicate to the resource that they need to start it on time on 10 June
depends on whether there are tasks dependent on it - if so I'm going to be
pretty firm they need to start on time. If not, say there's another
parallel task that doesn't finish until July 10 anyway, I'm still going to
*schedule* this task to start June 10 but not worry so much about whether it
starts on time. But in any case, remember you're not just listing deadlines
with a project plan - you determining when the work needs to be done in
order to finish the project in the most efficient and expeditious manner and
if you can get it done before the deadline so much the better (that way you
have a safety cushion to absorb the inevitable delays). Resources don't
tell you when they're going to work on tasks. *You* tell *them* when they
need to work on them. Likewise, you don't tell project what dates a task
will occur on - you give it the info on how long a task will take, what
other tasks it's dependent on, and when the resources are available to work
on it and it calculates and reports the dates you're going to get, the
required work schedule you communicate to the resources