Changing duration inhibited by Cost Resource's "inherent" duration

[Matt Barsotti]

I have Project 2007, and have put together a file using multiple Work
Resources and Cost Resources. Some tasks have both types assigned to them,
with hours assigned to the Work resources and dollar values assigned to the
cost resources.

The problem arises when I edit the duration of the task. If I lengthen a
given task, all is well. If I shorten it, the "entry" table of the Gantt
chart shows that the duration has been shortened, but it still maintains the
same start and end dates and the same visual bar length -- both of which
conflict with the new duration.

I traced the problem to show up on the Task Usage view with Summary Table,
where it shows that yes indeed, the duration and start and end dates have
been correctly adjusted for the Work Resources, but not for the Cost
Resources, which maintain their original start and end dates. These are the
dates for the task as set prior to resource assignment.

Manually shortening those dates in this view fixes the problem. However, it
more or less eliminates the ability to visually manipulate the Gantt chart
bars, look at resource allocation leveling, etc, since the bar length does
not correspond to the task durations.

Task settings are basically fixed-duration, non-effort-driven, prorated
accrual.

Is there a toggle that I'm missing to allow the Cost Resources to stop
inhibiting normal task duration editing?

Thanks

 

[Dale Howard [MVP]]

Matt --

This is a bug in Microsoft Project 2007. It is definitely a shortcoming of
using this potentially powerful new feature. Sorry.

 

[Matt Barsotti]

Dale,

Thanks for cutting to the center of this one so quickly. I've found a work
around, albeit a less-than-preferable one. I've simple turned all those
time-scaled costs to Material resources, with the entered units intended as
the dollars of expense, and using the rate for those resources to scale them
up for burdening and fee. It works OK, but the two decimal limit has always
hindered the precision of that kind of thing. Close enough for the time
being, but I do look forward to some type of patch that will fix the error...

Thanks