Breaking the duration - start date /end date relationship

[Balroc]

I'm trying to define a task that can occur in a wide time window relative to
the work effort involved. Let's say that I have a design spec that's
drafted and then sent out for review. The review period is 30 days and I
want to assign tasks for people to read the spec and approve or deny it.
There's 3 people and I want to assign them each a task with a 1/2 day
duration to do this action, but I don't care when they do so in the 30 day
review period. If I set up the task with a .5d duration and start/end dates
that are 30 days apart, project will either change the start/end dates or
increase the duration. How can I get past this?

TIA

 

[Jack Dahlgren]

I'd not bother to model tasks of less than a day of duration.
It sounds as if the review is not time critical so why bother putting it in
the schedule?

-Jack Dahlgren

 

[Balroc]

It's a hypothetical scenario. Make it a 5 days of review over a 30 day
window.

 

[Jack Dahlgren]

Then set duration to 30d and work to 5d. It should give a units of 17% or
so.

-Jack Dahlgren

 

[Steve House]

You're trying to redefine the metrics that Project uses, calling an apple an
orange. Duration is BY DEFINITION the amount of time between when the task
begins and when it ends, with intervening non-working time periods as
defined in the working time calendar deducted. (A task beginning 8am 02
June and ending 5pm 27 June has a 20 day duration, not 25, because the
weekends don't count.) Your example task is neither 1/2 day task nor a 1.5
day task, it is a 30 day task and you simply have to live with that. Work,
on the other hand, is the amount of the duration that the resource(s) spend
in observable physical acvitity on the task. Work and duration are related
to each other based on the rate at which the resource converts time into
work, that is, the assignment units, through the identity W=D*U. Your
example is of a 30 day duration task has 6 weeks elapsing between start date
and finish date task requiring 12 man-hours of work resulting in a resource
assignment level of 12 man-hours/240 hours/3 resources =1.6%

I think when you say it has a 30 day review period you really mean 30
calendar days, ie the month of June, and not 30 duration (working) days. If
so, the real number for your task would be more like: Start 02 June, End 30
June, Duration 21 days, Work 12 hours, Units 2.3%

You'll do a much better job of scheduling if you abandon altogether the idea
of duration as being the "window of opportunity" within which the resource
should work on the task and instead get more proactive and precise: "Joe,
that widget will be ready for you to work on next Tuesday - it should take
you a about a half-day - is that right? - so can I tell Mary you'll for sure
be passing it on to her no later than Thursday?" Durations, IMHO, should
represent your best estimate of what it WILL take, not the maximum that it
COULD take. So your example task would become a 1/2 day task able to start
02 June with a deadline of 30 June.