Actual Work - Converting to Decimals

[Tammy]

We use MSP 2003. We are using it to track actual time for all tasks entered.
We are using a resource pool (not sure if this matters). When we enter the
actual work, for some tasks, for some resources, it changes the numbers to
decimals after the plan is saved and closed - we do not see it actually do
this during entry. We NEVER enter decimals. This is very frustrating to the
PM's.

Help!

Thanks,

Tammy

 

[JulieS]

Hi Tammy,

A couple of things to help us help you.
What service pack do you have installed to Project 2003?
How are you entering actual work -- what view?
Can you isolate what is in common with the tasks where actual work is
changing? Are they all fixed units, fixed work, or fixed duration?
Where do you see the actual work showing as decimals -- what view?

Julie
Project MVP

Visit http://project.mvps.org/ for the FAQs and additional information
about Microsoft Project

 

[Tammy]

Julie,

-I'm unsure about the service pack.
-We are entering in a Time entry view we customized, in the actual work row.
Each week, we get actual time from our team and enter it in each of their
tasks. For tasks with no time that week, we enter a zero to push the time
forward. However, I believe we have seen hours in the "actual work" field
push forward too. Shouldn't this field only be for actual hours?
-I have not yet isolated the difference in which hours are changing and
which ones aren't.
-We use Fixed work for all tasks.
-We see the decimals in actual work and work in our time entry view. Also,
according to our PM's, the actual work from past entries changes as well.

Thanks Julie!

Tammy

 

[JulieS]

Hi Tammy,

Is the Time entry view based upon the Task Usage or Resource Usage
view?

When you are entering hours are you entering hours zoomed out to a
weekly basis or are you entering hours day by day?

If you are entering work zoomed out to a weekly view, it's very likely
to see decimals appear when you zoom back into a daily view. For
example, a task originally with 3 weeks duration scheduled to start on
Monday with a single resource assigned at 100%. Scheduled for 40
hours per week, 8 hours per day.

If I zoom out of the Task Usage or Resource Usage view to show weekly
information and enter 32 hours for the first week, project will spread
the 32 hours across the week duration and enter 6.4 hours of work per
day.

Julie

 

[Tammy]

Julie,

It is based on the Resource Usage view.

We enter for a week's worth of time. We don't zoom out to the days of the
week, we enter only per week and that is where the decimals are showing up.
And, they are not showing up when we enter the time, only after we save and
close the plan and go back into it.

Are you saying below that it has to do with what is calculating by day
behind the scenes? I don't know that I still understand why it is adjusting
our weekly entries. And why for some tasks and not for others? Maybe it has
to do with our understanding of "Actual Work" We believe that actual work is
what we enter as actual work only, no adjustments being made. How else are
we to track how much time was spent and if we are on task?

Tx!

Tammy

 

[JulieS]

Hi Tammy,

Well, based upon your comments and some experimentation of my own, I
can't come up with a good reason why actual work would be changing.
I've personally never seen actual work change after the fact. It may
be due to the resource pool issue, although again, I've never seen
Project change actual work when connected to a pool file.

Scheduled work *might* change if the projects were set to level
automatically.

When your PMs enter actual data, are they entering the data into the
subproject file or into a master project (consolidated). Is it
possible the files are being changed by someone other than the PMs?
Does the issue occur if they open the subproject file and enter data,
save, close, and re-open?

The comments I made about decimals appearing in actuals occur if you
zoom *in* to less than a weekly view after entering actuals. Project
will spread any actual work entered across the entire zoom area. For
example, entering actual work zoomed out to a weekly basis will spread
the entered actual work over each day in the week, possibly resulting
in decimal values on the day.

If PMs are not entering information other than the actual work per
week, their values should not be changing. However, it they are
modifying other values (actual finish or actual duration) that
certainly could account for the changes.

I'm sorry, but without seeing the files it's tough to guess. (Even
seeing the files it may be tough to work out the details.) The files
may have minor corruption although again, I've never seen values
change after the fact.

Sorry I can't be of more help. See if you can isolate whether the
issue is happening with only specific resources or only on specific
tasks. If it is only with specific resources, is there anything
different about those resources? -- different working schedule. If it
is only with specific tasks, is there something unusual about those
tasks -- task calendar etc?

There aren't any resource assigned to summary tasks are there?

Julie

 

[Tammy]

Hi Julie,

Thank you again for giving this so much thought.

To try to answer your questions...
1) We do not use leveling because of a single resource being assigned to
multiple project plans via the resource pool.
2) We enter actual hours into each individual MSPP. Each project has its
own plan...no master projects. We have about 25-30 plans hooked up to the
resource pool utilizing about 170 available resources.
3) As we can not use leveling, the PM's do go into their plans after data
entry into actual work and make adjusments to the "finish" (not actual
finish) dates because MSPP sometimes adjusts it for them after actual work
time entry, thus pushing tasks out past the needed finish date.
4) In reviewing the resources as well as the tasks, there doesn't appear to
be a rhyme or reason to some tasks making decimal adjustments and some not.

Thanks again Julie,

Tammy

 

[JulieS]

Hello Tammy,

It's number four in your list below which is accounting for the
decimal percentages

By changing the Finish dates on tasks project is constraining the
tasks with a Finish No Earlier than constraint. Project is then
recalculating how to fit the actual work entered into the new dates.

You can see pretty easily what is going on with a simple experiment:

Create a 1 week duration task starting today and scheduled to end on
May 16.
Assign 3 resources (Bob, Julie, Tammy) to the task each working 40
hours at 100% unit assignment.
View the Resource Usage View and show actual work. Zoom out to show 1
week in the minor unit.

Enter 23 hours of work for Bob in week one. Because Bob worked less
than the forty hours he was scheduled for, project took the remaining
17 hours and spread them out into the week beginning May 11. The
finish date of the task is now Wednesday May 14th at 9:00 AM. The
remaining work has extended the end date of the task.

If I go back to the Gantt chart view (or any task view) and change the
finish date to Friday, May 16th, Project selects the 16th at 9:00 am
as the finish date of the task. I do get a message warning me that
the "Actual finish date is before some of the previously entered
timephased actual work values. If I click OK, project changes Bob's
actual hours to 18.98 hours because it is ending the task at 9:00 am.

In order for Julie & Tammy to complete their 40 hours, the assignment
units have increased to 121%.

I suggest that if your PMs want to change the scheduled finish of the
task, they modify remaining work, not change the Finish date If
your PMs are not viewing time as well as dates, I'd suggest turning
that option on. (Tools > Options, View tab and select a date format
that shows time.)

I hope this helps. Let us know how you get along.

Julie
Project MVP

Visit http://project.mvps.org/ for the FAQs and additional information
about Microsoft Project