Re: Actual Work moving to future

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Scott McClure (Scott_D_McClure_at_msn.com)
Date: 03/10/04


Date: Wed, 10 Mar 2004 08:18:06 -0800

OK, still trying to understand this setting -- If I uncheck it, MSP will
still update % Complete and % Work Complete (yes, we understand the
difference) when we enter Actual Work (again, through Pro, not PWA), right?
Our problem continues to be that the values entered aren't always the values
we find when we next open the project. Still a bit confused (nothing new
there!).

BTW, where we have multiple resources on a task it is because of different
working calendars, not different skill sets. We organize by speciality shop
(Airframe, Sheet Metal, Hydraulics, Electric) so that by your definition we
are probably OK.

Thanks,
Scott

"Steve House" <sjhouse.remove.this@to.send.hotmail.com> wrote in message
news:ux1cWpjBEHA.464@TK2MSFTNGP11.phx.gbl...
> What that setting will do is when you post progress it disconnects task
> level progress entries from recording the work performed (and vice versa).
> Remember, for MSP % Complete refers only to duration, not work. But %
> Complete and % Work Complete entries do interact if that checkbox is
turned
> on. In a nutshell, if I have a 40 hour task with 40 man-hours of work (1
> resource) and I update the progress to show 50% done, by default Project
> will record 20 hours duration has gone by and also that 20 man-hours of
work
> has been done. But if I clear that checkbox and then set the task to 50%
> done, it will show 50% complete but will continue to show that no actual
> work has been performed - I've broken the connection between the duration
> progress and work progress entries and have to manually update the work in
a
> second entry.
>
> IMHO, "one task per resource" does not necessarily mean "one task per
> worker." I think of resource in that context as meaning skill set. We
may
> have several individuals who work together as a team, side-by-side on the
> same shift, like a welder and his apprentice, and then the team is the
> resource, not the individuals in it. But one way or the other,
multi-shift
> scheduling isn't a big problem if you keep your ducks in order. I have a
> task that I figure will take 24 man-hours to complete. My project
calendar
> shows a day shift, 8 hour work day. I input the task and it starts Mon at
> 8am and finishes Wed at 5 pm - 3 days shifts in length. I put Billy Bob
on
> it who works day shift. Task still shows starting Mon at 8 and finishing
> Wed at 5, no change. But if instead I assign it to Billy Bob and also
Lucy
> and Ricky, Lucy working Swing and Ricky working Graveyard, the task now
> shows Starting Mon at 8 and finishing Tues at 8. But it's still 3 days,
ie,
> 3 shifts duration. The elapsed time changes because the task works
> continuously with no down time but the duration does not because it still
> takes 3 8-hour working days worth of working time to complete.
>
> --
> Steve House [MVP]
> MS Project Trainer/Consultant
> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>
>
> "Scott McClure" <Scott_D_McClure@msn.com> wrote in message
> news:evVvqGjBEHA.3784@TK2MSFTNGP10.phx.gbl...
> > Thanks, Steve. This has been a useful discussion although I think we
got
> > off the track of my original problem (Project moving actual hours
around).
> > While I wish we could assign Billy Bob and get to one task per worker,
> > neither of those items is practical here. Still, what you have
discribed
> is
> > about how we are operating.
> >
> > I believe someone on this thread or a similar one mentioned the
"Updating
> > Task Updates Resources" check box (currently checked in our projects).
> > Maybe this will help.
> >
> > Thanks again,
> > Scott
> >
> > "Steve House" <sjhouse.remove.this@to.send.hotmail.com> wrote in message
> > news:OR%23yG2gBEHA.2404@TK2MSFTNGP11.phx.gbl...
> > > It's not as bad as it sounds. You really can use a typical resource
as
> > the
> > > Project calendar so tasks prior to having their resource assigned will
> > show
> > > up int the schedule as a reasonable approximation to where they'll
land
> > when
> > > the resource that works them is assigned at the resource calendar
> assumes
> > > control of their scheduling. So you have 6 or 7 shifts. Set up 6 or
7
> > base
> > > calendars that conform to each shift. Select one, the most common
shift
> > or
> > > perhaps a conventional 8-5 M-F calendar, to be the Project calendar.
> When
> > > you enter Billy Bob in the task list, you designate the base calendar
> that
> > > conforms to his shift as his base calendar. You end up with a
resource
> > > calendar for each resource table entry but that's the way it's
supposed
> to
> > > work. Remember the WBS is supposed to decompose the tasks down to the
> > level
> > > of granularity of "one task - one resource" generally speaking. If
you
> > have
> > > a group of workers who aren't differentiated by name, example
custodians
> > > perhaps, you may have a resource named Day Shift Custodians, another
> named
> > > Swing Shift Custodians, and another named Grave Shift Custodians.
> > >
> > > The most imprtant point is to remember that the Tools Options Calendar
> > > "Hours per ..." settings are really only conversion factors. The only
> > time
> > > they enter into things is when you enter a duration as "X days" - that
X
> > has
> > > to be converted to hours, thence into minutes before being stored in
the
> > > database and back again when displayed in a duration field. If you
mean
> > the
> > > task will take 40 hours duration, 4 days if assigned to a 10 hour per
> day
> > > worker versus 5 days when assigned to an 8 hour per day worker, simply
> > enter
> > > the duration as hours to start with and you'll bypass the whole issue.
> > Yes,
> > > you may see a task beginning on Monday at 8am and ending Thursday at
7pm
> > as
> > > a "5 day task" and another beginning Mon at 8am and ending Fri at 5pm
> also
> > > showing 5 days (assuming you've set 8 hours per day in the calendar
> > option)
> > > but so what? The dates and times they start and finish will be
correct,
> > the
> > > summary task above them, if any, will show the correct total duration
> and
> > > elapsed time for that phase or deliverable, and the Project Summary
task
> > > will show the correct total duration and elapsed time for the Project,
> > plus
> > > all the work calculations will show the correct man-hours. You'll
even
> > see
> > > it end on Thursday evening if you assign it to a 10 hour per day
worker
> > and
> > > then if you reassign it to an 8 hour a day worker it will shift to
> finish
> > on
> > > Friday evening.
> > >
> > > --
> > > Steve House [MVP]
> > > MS Project Trainer/Consultant
> > > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> > >
> > >
> > > "Scott McClure" <Scott_D_McClure@msn.com> wrote in message
> > > news:%23MRVaGgBEHA.2348@TK2MSFTNGP09.phx.gbl...
> > > > Steve,
> > > >
> > > > All well and good except that we have probably 6 or 7 different
shifts
> > > here.
> > > > Of the 300 or so guys we are trying to schedule, some work 4-10s
M-T,
> > some
> > > > 5-8s Days, some 5-8s Eves, some 4-10 eves T-F ... you get the idea.
> > Most
> > > > (maybe 40%) work 8:00 to 4:30 with a 1/2 hours lunch so that's what
> > we've
> > > > set the Calendar to. In other words, there is no way to make the
> > calendar
> > > > options "foloow suit" with a typical resource. As is said around
> here,
> > > > "everything is standard except the specials and everything is a
> > special!"
> > > > BTW, we may have two (or more) different shifts assigned to the same
> > task.
> > > > Thus I *think* I'm left without a workable recommendation. True?
> > > >
> > > > Thanks,
> > > > Scott
> > > >
> > > > "Steve House" <sjhouse.remove.this@to.send.hotmail.com> wrote in
> message
> > > > news:OXu8Z6mAEHA.1796@TK2MSFTNGP12.phx.gbl...
> > > > > The Project Calendar should, IMO, conform to a generic "typical"
> > > > resource's
> > > > > workday and the Tools Options Calendar fields should follow suit.
> The
> > > > > "hours per day" entry really is only a conversion factor used when
> > > > inputting
> > > > > or displaying durations. Project stores all durations in the
> database
> > > in
> > > > > minutes. If I say a task is "3 days duration" how many minutes do
I
> > > mean
> > > > it
> > > > > should take? The Calendar Options page field "Hours per day"
> answers
> > > that
> > > > > question. It should conform to the number of working hours in a
> > > "workday"
> > > > > as defined in the base calendar selected to be the Project
Calendar.
> > If
> > > > > your resources are on the property for a total of 10 1/2 hours
> > including
> > > a
> > > > > 30 minute lunch break, the Project Calendar (Tools,
> ChangeWorkingTime
> > > then
> > > > > Project, ProjectInformation) should show hours of work perhaps as
> > > > 0800-1300
> > > > > and 1330-1830 for a workday of 10 hours and non-working time in
the
> > > middle
> > > > > of 1/2 hour (note the elapsed time is 10 1/2 hours) and the "hours
> per
> > > > day"
> > > > > entry would show 10 hours (non-working time such as lunch is NOT
to
> be
> > > > > included). Think of the old adage "A day's work for a day's pay!"
> > > That's
> > > > > what we're defining here - how many man-hours worth of sweat are
we
> > > paying
> > > > > for when we schedule a day's work on the project?
> > > > >
> > > > >
> > > > > --
> > > > > Steve House [MVP]
> > > > > MS Project Trainer/Consultant
> > > > > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> > > > >
> > > > >
> > > > >
> > > > > "Scott McClure" <Scott_D_McClure@msn.com> wrote in message
> > > > > news:OszQ8sVAEHA.580@TK2MSFTNGP11.phx.gbl...
> > > > > > Steve,
> > > > > >
> > > > > > Thanks -- I'll check again but I wasn't very clear about the
> > calendar.
> > > > It
> > > > > > shows a *total* of 10 1/2 hours with a 1/2 hour break. That is,
> > they
> > > > are
> > > > > > on-site for 10 1/2 hours including their lunch time.
> > > > > >
> > > > > > So our Calendar options say the default hours per day are 8, per
> > week
> > > > 40,
> > > > > > and days per month 20. Of course, we have people working all
> kinds
> > of
> > > > > > different shifts. In this case, their calendar says 6:00am to
> > 12:00pm
> > > > and
> > > > > > 12:30pm to 4:30pm. Friday is a non-working day. Because of the
> > > > different
> > > > > > shifts there is no way I can get the options page to match all
> > > > resources.
> > > > > > Is this somehow casuing my problem? If so, is there anything I
> can
> > do
> > > > > > (short of rescheduling everyone which would make life a lot
easier
> > on
> > > > me)?
> > > > > >
> > > > > > Scott
> > > > > >
> > > > > > "Steve House" <sjhouse.remove.this@to.send.hotmail.com> wrote in
> > > message
> > > > > > news:ePNS3URAEHA.212@TK2MSFTNGP12.phx.gbl...
> > > > > > > Look again at your alignment between the hours per day in your
> > > > resource
> > > > > > > calendars and the hours per day in the Calendar Options page
> that
> > > > > defines
> > > > > > > the relationship between a duration "day" and the hours in
that
> > day.
> > > > > You
> > > > > > > said the resources are doing a 10 1/2 hour day with 1/2 hour
for
> > > > lunch.
> > > > > > > Does that mean they're on the property for 11 hours such as
8am
> > till
> > > > 6pm
> > > > > > > with a 30 minute lunch somewhere in there to give 10 1/2 hours
> of
> > > > actual
> > > > > > > *working time* in their day or are they at work for 10 /1/2
> hours,
> > > > 8am -
> > > > > > > 530pm, with a 30 min lunch for a total working time during the
> day
> > > of
> > > > 10
> > > > > > > hours? The "hours per day" and "hours per week" entries in
the
> > > Tools,
> > > > > > > Options, Calendar page should conform to the *actual* working
> > hours
> > > > > *only*
> > > > > > > with the lunches, etc backed out. Don't know if this is the
> > problem
> > > > but
> > > > > > > it's the first thing I'd check.
> > > > > > >
> > > > > > > --
> > > > > > > Steve House [MVP]
> > > > > > > MS Project Trainer/Consultant
> > > > > > > Visit http://www.mvps.org/project/faqs.htm for the FAQs
> > > > > > >
> > > > > > >
> > > > > > > "Scott McClure" <Scott_D_McClure@msn.com> wrote in message
> > > > > > > news:esnoQfV$DHA.2412@TK2MSFTNGP12.phx.gbl...
> > > > > > > > Background: Our tasks are effort-driven and fixed units.
> > > > Constraints
> > > > > > are
> > > > > > > > avoided. Our resources are groups of skills with 100% = 1
> > person.
> > > > > The
> > > > > > > > calendar for the resource shows a 10 1/2 hour day with a 1/2
> > hour
> > > > > lunch.
> > > > > > > We
> > > > > > > > are running PS and MSP2002.
> > > > > > > >
> > > > > > > > We enter our actual work centrally via a slightly modified
> Task
> > > > Usage
> > > > > > > screen
> > > > > > > > in Project Pro.
> > > > > > > >
> > > > > > > > Problem: Sometimes, for reasons we don't understand, when a
> > time,
> > > > say
> > > > > 1
> > > > > > > > hour, is entered for a task, the software breaks that time
up
> > and
> > > > > moves
> > > > > > > some
> > > > > > > > of it to the next day. In this case the day we are
entering
> > > takes
> > > > .8
> > > > > > and
> > > > > > > > the next day (the future) gets .2.
> > > > > > > >
> > > > > > > > We had thought this might be because the resource was tapped
> > > out --
> > > > > out
> > > > > > of
> > > > > > > > available hours for the day. In this case the resource has
6
> > > units
> > > > > > > > available or 60 hours. When the 1 hours was split into
today
> > and
> > > > > > > tomorrow,
> > > > > > > > the result of adding that 1 hour to the resource would have
> > > resulted
> > > > > in
> > > > > > a
> > > > > > > > total reported labor of 32 hours. This sort of blows theory
> > one.
> > > > > > > >
> > > > > > > > Now, the previous day 69 hours were reported. Question:
does
> > this
> > > > > > affect
> > > > > > > > how actual hours are accepted for subsequent days? If so,
> how?
> > I
> > > > > know
> > > > > > > that
> > > > > > > > MSP thinks minute-to-minute but even if the entire 9 hours
> were
> > > > moved
> > > > > > into
> > > > > > > > today this still would have only resulted in 41 (of 60
> > available)
> > > > > hours
> > > > > > > > used.
> > > > > > > >
> > > > > > > > This is most frustrating to our data-entry person and
prevents
> > us
> > > > from
> > > > > > > using
> > > > > > > > a macro to automatically load the actual hours from our work
> > order
> > > > > > system
> > > > > > > > because we don't trust what MSP will do with it.
> > > > > > > >
> > > > > > > > Is there any way to resolve this???
> > > > > > > >
> > > > > > > > TIA,
> > > > > > > > Scott McClure
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Relevant Pages

  • Re: Actual Work moving to future
    ... > level progress entries from recording the work performed. ... I think of resource in that context as meaning skill set. ... > shows a day shift, ...
    (microsoft.public.project)
  • Re: Actual Work moving to future
    ... Remember, for MSP % Complete refers only to duration, not work. ... resource) and I update the progress to show 50% done, ... shows a day shift, 8 hour work day. ... >> Project calendar so tasks prior to having their resource assigned will ...
    (microsoft.public.project)
  • Re: Actual Work moving to future
    ... Remember, for MSP % Complete refers only to duration, not work. ... resource) and I update the progress to show 50% done, ... shows a day shift, 8 hour work day. ... >> Project calendar so tasks prior to having their resource assigned will ...
    (microsoft.public.project)
  • Re: Actual Work moving to future
    ... duration hours have elapsed and vice versa, ... >> What that setting will do is when you post progress it disconnects task ... >> shows a day shift, ...
    (microsoft.public.project)
  • Re: Actual Work moving to future
    ... duration hours have elapsed and vice versa, ... >> What that setting will do is when you post progress it disconnects task ... >> shows a day shift, ...
    (microsoft.public.project)