Scheduling conflict instead of changing units

A

Ali B.

A task has 10 days of work and a duration of 5 days. Because only 1 resource
is working on that task, the unit is 50%. The Task type is fixed work and the
task has a date-constraint ("Finish no later than") on the last day (day 10).


The problem:
When the resource takes one day off (during that task), the resulting
calender exception produces a scheduling conflict instead of increasing the
unit to 56%.

Thanks for any suggestions
 
J

John

Ali B. said:
A task has 10 days of work and a duration of 5 days. Because only 1 resource
is working on that task, the unit is 50%. The Task type is fixed work and the
task has a date-constraint ("Finish no later than") on the last day (day 10).


The problem:
When the resource takes one day off (during that task), the resulting
calender exception produces a scheduling conflict instead of increasing the
unit to 56%.

Thanks for any suggestions

Ali,
Well first of all you're doing a pretty neat trick to get 10 days of
work (i.e. 80 manhours) into a 5 day task with only 50% utilization of a
single resource. How you do dat?

OK, look at it this way, the task is designated as fixed work and you
have applied a finish constraint. Once this task is scheduled, Project
sets up a fixed 4 hours per day over a 10 day period. Now if you change
the resource calendar to let the resource take a day off, Project
requires the task duration to change because of the fixed work schedule.
Since the end date is constrained, its only option is to shift the start
date back by one day. When you think about it in that light, it makes
sense, right......?

John
Project MVP
 
A

Ali B.

Hi John

Thank you for your fast reply. As you already found out, I mixed up work and
duration. But my problem still exists.
Since the end date is constrained, its only option is to shift the start
date back by one day.

I don't agree that this is the only option. The other option would be to
increase the resource units of that task.

I tried to change the task type to 'fixed duration' (because the start and
the end are given), but it didn't help.

Isn't there any way to force project to change the resource units?

Thanks for any reply
 
J

John

Ali B. said:
Hi John

Thank you for your fast reply. As you already found out, I mixed up work and
duration. But my problem still exists.


I don't agree that this is the only option. The other option would be to
increase the resource units of that task.

I tried to change the task type to 'fixed duration' (because the start and
the end are given), but it didn't help.

Isn't there any way to force project to change the resource units?

Thanks for any reply

Ali,
Sorry I forgot an apostrophe on the "its". What that sentence was saying
is that under Project's rules, Project's only option is to shift the
start date back by one day. Project is constrained to operate under a
strict protocol of rules and algorithms, however as users we of course
have many options, so yes, another option is to increase the resource
units - but that is the user's option not Project's. Remember you are
dealing with software, so what may be an "option" in your mind isn't
necessarily an option for the application. It is just the hard reality
of working with a computer application. What we think of a a logical
path isn't necessarily what the software will do - oh what we wouldn't
give for some fuzzy logic.

OK, enough philosophy. So how do you achieve what you want? Since you
changed the ground rules of the original task (i.e. you modified the
working time calendar, thereby effectively changing the task duration -
remember duration is working time). Setting the task up as fixed
duration doesn't help and we already know what Project does if the task
is fixed work. It's not hard to guess what Project will do if we try to
set the task to fixed units, after all, you don't want fixed units.

Here's what you can do. After you have changed the resource calendar,
Project will of course change the duration. Manually reset the duration
to 10 days. This will cause Project to up the work. So re-adjust the
work back to 40 hours. Then Project will increase the unit assignment
level to 56% - exactly what you want.

Although Project's work equation (i.e. duration = work/units) follows a
strict set of rules, there are user scenarios that do not always honor
the constraints of the work equation (i.e your scenario). In those
cases, the task parameters may need to be revised using additional steps
to create the desired result.

No one ever said that project management was easy nor that Project is an
easy application to learn and use. That's why we love it so much - it is
challenging to say the least.

Hope this helps.
John
Project MVP
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top