I'm not saying 60 hour weeks never occur but the "normal" work week in North
America for white collar and most blue-collar workers has been 40~44 hours
since the 1930's. Europe is a bit less with a normal work week in the
mid-30 hours in a number of areas. That's not to say the industries
themselves only work 40 hours a week - an airline operates 24/7, for
example, but they do it with multiple shifts that for full time ground
personel are typically ~40 hours a week, while flight crews are less by
regulation. Scheduling individuals to work 60 hour weeks week-in and
week-out for a long period of time IMHO is really pushing the physical,
mental, and emotional endurance of the workers. Interestingly, the average
worker productivity in countries such as Germany (with a normal work week of
35 hours and 4-6 weeks paid holiday annually) is considerably higher than in
countries such as the USA or Canada with their higher work loads and shorter
holidays. In other words, a more human oriented working environment, one
that realizes that work is only one aspect of the employee's life values,
actually pays off in higher productivity, giving you more more output for
your labour cost dollar. More output for the same cost is usually a good
business decision, right (all other things being equal)? <grin> In any
case, it's usually a wise practice in project scheduling to hang on to your
available overtime as an emergency reserve - with 60 hours as your normal
week, what will you do if you get behind the 8 ball and find need an
additional 20 man-hours in one week to make deadline? Because you've
already used 20 hours of OT for the schedule BEFORE the emergency developed,
getting that 20 additional hours you now need will require you work the
resource a total of *80* hours. While 60 hours is admittedly doable, 80 is
going to burn out your workforce real quick and may simply turn out to be
impossible to get. Asking for it too often is going to send your turnover
through the roof, increasing your costs dramatically. More importantly from
a planning point of view, by basing your schedule on the maximum possible
work hours your resources physically CAN do, you have removed the
flexibility you might need to call up additional hours later to fix problem
situations that might come up, you've painted yourself into a corner with no
hours in reserve for those contingencies that are certain to arise.
Given that you do want to use 60 hour weeks, I'd create a calendar to use
for the Project calendar that shows just that - regular hours of work are 10
hours per day, 6 days a week with variations of it for the resource
calendars. When you set the hours don't forget to include the meal breaks
etc - ignoring 30 or 60 minutes a day that the calendar calls working time
but really isn't adds up in short order to distorted durations and work
estimates. To take into account the fact that in a given day 8 hours are
straight time and 2 hours are overtime, with Saturday 10 hours of overtime,
I'd use a loaded rate that represents that total cost as an adjusted
standard rate. Costs in Project are estimated costs anyway, NOT the same
thing as costs in a payroll or time and billing programs and frequently are
adjusted costs pro-rated for planning purposes, not actual pay-rates as show
up on paycheques. For instance, an engineering department may have 10
people ranging in salary from $50k for a new hire up to $100k for a senior
team leader but for budget planning purposes they are all costed at a
standard annual $75k, a weighted figure that includes salary, benefits,
hiring cost, training costs, facilities overheads, etc. So if your resource
gets $10 per hour straight time and OT of $15 per hour, for example, his
weekly rate is (40*10) + (20*15) or $700 per week. Use that value as the
standard rate, $15 as the OT rate so it will include the actual cost of
hours in excess of 60 at the $15 each those additional hours do cost. Yes,
you'll be off a little from what you'll find at the end of the project when
you add up all the pay stubs but you'll be close enough for planning
purposes. Generally speaking +/- somewhere around 10~20% is considered
really close.
The task types of fixed duration, fixed work, and fixed units do work but
you need to know where they kick in and where they have no effect. One of
Project's prime directives is that Work = Duration * Units. In basic
alegbra, such a linear equation relates an independent variable, a dependent
variable, and a constant. Until resources are assigned to a task, that
equation's terms are essentially blank and "fixed duration" etc has no
meaning. When we assign resources, Project assigns values to all three of
those terms. Typically we have estimated the duration and specified units
that represent the percentage of the resource's working time that will be
spent on this particular task (typically 100% unless he needs to work on
something else simultaneously) and Project then calculates the man-hours of
work. If we now edit any of these values, we need to tell which term
Project should recalculate and we do that by specifying whoch one to hold
constant. If we're editing the resource units - he was 100% but we realize
he needs to be somewhere else 4 hours a day, we can tell Project to hold the
duration constant and revise the man-hours (fixed duration) or hold the
man-hours constant and revise the duration (fixed work). Which is correct
depends on the reason for the edit - do we need him on spmething more urgent
part of the day and we'll live with the fact that it'll take longer to get
this task done or have we initally overestimated the amount of work this
task requires but we really don't need to get it done in a shorter time so
we'll leave the duration as is and return our fellow to the "available pool"
for the 4 now uncommitted hours a day. If you're not doing something that
*changes* (as opposed to setting initially) one of the values of work,
duration, or units AFTER resources are assigned, the task stype setting has
no effect.
Simlarly, effort driven or non-effort driven ONLY has impact when you add or
take away bodies from a task. I have one resource and I add a second, what
happens depends on the effort-driven setting. But if I have one or two or
whatever and simply edit the W, D, or U values for one or more of them the
effort driven setting is irrelevant. Only when adding or taking away people
does it do anything. Effort driven means that if I have one guy on a task
and add a second person, the total man-hours required remains the same and
now is spread between 2 people instead of all being done by one, hence the
duration drops. Non-effort driven means that adding the second resource
increases the total man-hours required and so the duration stays the same.
Adding a second painter to work alongside a painter already assigned would
usually be effort driven, adding a 3rd person to attend a one hour meeting
already scheduled for 2 people would generally be non-effort driven -
whether it's 2 or 3 people in the audience it's still is a one hour
presentation.
I hope this helps and gives you some food for thought ... more than happy
to field any questions or clarify id I've missed the boat
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
Dave Bell said:
Hello Steve, I found the first paragraph of your response to be pointed
and, although not entirely helpful, appreciated. However, the second
paragraph of your response seems to indicate a rather provincial and
uniformed world view. A signifigant portion of the civilized nations of the
world derive their GDP from industries which typically work 60-hours per
week. Some examples you may have heard of which operate this way: The Big
Dig, The Hoover Dam, The Alaska Pipeline. So, lets assume I've a good
reason for wanting to operate this way. Is this something Microsoft Project
is set up to do?
What I am trying to do with Microsoft Project 2000 is to use a resource
loaded schedule to help bidding jobs and then use the same resource loaded
schedule for tracking of job progress and tracking of actual job-hours. As
job progress is tracked I would like Project to produce a forecasted
resource (job-hour) cost as well.
At this point I am only loading the schedule with personel as the
resource. Eventually I would like to load equipment as well. So, what I am
working towards in the short term is a labor cost for bid purposes, an as
built labor cost and a projected total labor cost based upon percentage of
task/project progress.
The underlying reason for my attempt to use Microsoft Project in this way
is for ease of communication with Superintendents, Foremen and other field
personel. The visual nature of Microsoft Project (Gant Charts etc) makes
understanding the labor bid budget for a particular job verses the actual
labor used and projected cost very easy to understand. Essentially,
pictures are easier to understand than numbers for some people, myself
included.
I generally bid jobs based on a 60-hour work week; 10-hours per day, six
days per week. The first 8-hours of any day worked, when the total number
of weekly hours for that emloyee is less than 40, is calculated as Microsoft
Project's "regular time rate." The last two hours of any day in which the
total weekly hours is less than 40 is calculated at the "overtime rate."
Also, any day in which the resources weekly hours already worked are greater
than 40 would be calculated at the overtime rate. For example, Monday
through Friday an employee will get 8-hours straight time per day and
2-hours overtime per day. Saturday would then be 10-hours overtime.
I have tried setting the calendar to count saturday as a work day and then
setting the hours per day at 10 and hours per week at 60. We have also
experimented with 8-hours per day, 40-hours per week, 5-days per week and
many other permutations of the calendar possibilities.
Thus far I have had the best results using a "fixed duration" task which is not effort driven.
I have been unable to force Project to allocate resources based upon our
hour per week and hour per day regular time and overtime constraints. Also,
Project does not seem to be truly of "fixed duration."
I have many very detailed questions about Project. However, these few
paragraphs are a rough overview of what we are trying to use Project for and
a rough idea of where our questions lie. I are not sure how detailed to
should get with this letter at this point; don't want to overwhelm you with
poorly worded and detailed questions, yet. Perhaps Project is simply not
the right tool for our purposes.
I have recently tried using "as built" data from Excel and then pasting
this data into Project. Perhaps this avenue of attack is most productive?
Any advice you have is much appreciated. Just let me know if more detail
or clarification of what we have done and what our questions is needed.
