changing remaining duration changes actual work?

[Adam Bennett]

Has anybody noticed an issue with the actual work recorded against a project
changing when the remaining duration is changed?

Here's the scenario we've encountered:
The project plan is setup and baselined and actual work gets applied to the
project (we're using non-managed time and tasks are typically setup as fixed
duration - effort driven). After the project has been finished, we want to
"close out" the project by changing some of the meta data fields and marking
all tasks 100% complete.

To mark the tasks 100% complete, we've been changing any remaining work that
still exists on the project down to zero. However, not all tasks are marked
at 100% with this method, so we were also changing the remaining duration
down to zero as well. When doing this though, we noticed that some actuals
are changing.

I was just curious if this was an identified issue and/or what is the best
practice for marking tasks as 100% when using non-managed time.

Thanks for the help!
Adam

 

[Frederick]

Good day Adam,

Yes, absolutely, that is the case for us too. I have been told several times
this is "normal behaviour which respects the rules that Work = Actual +
Remaining and Duration = Work / Units (safe for split tasks and tasks with a
work contour other than "Flat").

As well as if you change the following other items in the plan you will
"disturb" existing actual effort:
- Manually Changing Actual Work (which may also change the "Work contour"
and in the same token, change your Duration)
- Manually Changing % Complete
- Manually Changing Actual Duration
- Adding an Enteprise Resource Pool resource to a completed task which has
actual effort on other resources (this assigns actual effort to the new
resource if the task was in "Fixed Work" or "Fixed units", and does not
affect "Fixed duration" tasks...)

For the specific situation you are reporting, the workaround we identified
is horrible but seems to work:
1) add “1 hour†to the Remaining Work for a resource,
2) change the finish date and then
3) remove the 1 hour so that the remaining will be 0 and the percentage
completed will be 100%

If anyone else has a better solution, I would LOVE to hear it.

Cheers,

 

[Gary L. Chefetz [MVP]]

Adam:

How is it possible for a fixed-duration task to be effort-driven? On one
hand, you're saying that this task is going to take X-days no matter how
many resource hours we give it.. Then, on the other hand you're saying that
the task is effort-driven, meaning that if you add more resources, the
duration will shorten. So, you've set up your tasks in a conflicted state to
begin with and now expect Project to figure out what's supposed to happen
when updates are processed.

This type of confusion is typical and indicates a lack of understanding of
the scheduling engine and its most basic concepts. You're also planning by
duration but tracking by hours, another conflict in your approach. You need
to understand that with Project you get to pick two of three values: 1)
work, 2) resource units, and 3)duration, and that Project will always
calculate the third. When you setup a task as fixed-duration and then apply
a resource, the system will always calculate or recalculate work if you're
applying a resource to started fixed-duration task. This includes actual
work. Further, the system distributes actual work like cream cheese on a
bagel when you apply it to fixed-duration tasks. It will distribute work and
actual work across the duration, past, present and future, until the bucket
you've created overflows and it will then extend the duration of the task.
Similarly, if you start changing duration of a "so called fixed-duration
task" (in your case a misapplied construct) the system has to redistribute
or recalculate work and actual work, because you're telling it to.

So, if you're going to keep planning durations, then you need to turn off
effort driven on your tasks and you should consider managing the work values
so your durations do not change unexpectedly. Otherwise, you might consider
a fixed-unit task type, estimate effort and allow Project to calculate the
durations. IOW: Effort planning along with effort tracking will likely yield
the results you expect, but will require the extra step of effort estimating
and the mental leap of allowing Project to calculate duration. The latter is
often difficult for many organizations to swallow, particularly in absence
of a fundamental understanding of the scheduling engine.

 

[Adam Bennett]

Frederick
Thank you for the reply. That is very helpful. I knew about % complete
changing actuals but didn't know about some of the others. Very helpful.

Thanks!
Adam

 

[Adam Bennett]

Hi Frederick
One other question for you regarding this. When making one of the changes
you listed below that affects the actuals within the plan, do you happen to
know if these changes are published out to the Work field on the server when
you have NOT checked the "Overwrite protected actuals" in the Repub
Assignments function?

I know that the Protected Actual Work wouldn't be overwritten, but I'm
wondering if the Work would be. I'm trying to troubleshoot a data
discrepancy in PWA vs OLAP and I'm wondering if OLAP reports on Work instead
of Protected Work and if the above scenario overwrites Work, that may be my
problem.

Thanks in advance for any help!
Adam

 

[Michael Brown]

Gary,

Unless I misunderstand something, one of the options that's readily
available for a given task is to set it up as Fixed Duration, effort driven.
For example, I set up a task that is 5 weeks long and has 200 hours of effort
in it. If I throw one resource at that task (assuming 40 hours per week), it
will tell me I need 100% of that resource. If, instead, i throw 2 bodies
onto the task, the system will split the work between the two, at 50% per
resource.

We seem to run into a very similar situation as noted above. I have a fixed
duration task (non effort driven in this case). Hours are tracked against
the task thru PWA and then imported. If the resource - on his or her "My
Task" page, changes the remaining effort and/or the finish date to reflect
more (or less) time is needed, Pro seems to redistribute the ACTUAL hours in
ways other than the way they were entered on timesheets. In TOTAL the hours
come out correctly, but they're redistributed between the days as if the
countouring is spreading the actual hours differently than it was entered.

 

[Gary L. Chefetz [MVP]]

Michael:

I'm not sure what you're asking of me. Your experience does confirm the
behavior I describe. When you apply work to a fixed duration task, the
system tries to distribute it across the duration of the task.As you update,
it redistributes. Fixed-Duration is a rarity in real life scenarios and much
overused by project managers who want their schedule to reflect their
desires rather than calculated values.

--

Gary L. Chefetz, MVP
MSProjectExperts
For Project Server Consulting: http://www.msprojectexperts.com
For Project Server FAQS: http://www.projectserverexperts.com