Re: 24 hour calender 7 days a week in 3 team shift
- From: Assist <Assist@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 30 Sep 2007 23:27:00 -0700
1 day duration is 24 hours.
"Steve House" wrote:
Question about your calendars. Remember durations are *always* stored and.
processed internally in hours to the nearest 1/10 minute. Units such as
days, weeks, etc are provided as a convenience but are converted upon entry
and the "hors per day" etc setting on the calendar options page are the
conversion factors used. So when you say a task has a duration of "1 day"
are you thinking that task lasts 8 hours or does it last 24 hours? In other
words, if that 1-day duration task starts Monday at 8am should the schedule
have it end Monday at 5pm or Tuesday at 8am?
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
"Assist" <Assist@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:477ED1E9-4591-48A1-BEEB-8B975E2418A5@xxxxxxxxxxxxxxxx
Thanks a lot for your replies !
We use AMIGO to manage work cards on the different jobs. (We like to dig
data out of AMIGO and import it into MS Project, but thatâ?Ts another
story).
We like to show the big picture in a Gantt chart. So a C-Check on a
specific
aircraft is one task. We are trying to use MS Project to show witch
aircraft
is worked on (in which hangar) from start date to end date as one task.
We also want to show what kind of resource % that is needed. We like to
show
the Gantt Chart on a big screen in the hangar as a service information to
the
mechanics. At this point we won't use project to manage the mechanics
detailed tasks. If we need to hire in extra mechanics we like to know
when,
how long and how many.
The question to us is how can MS Project calculate the need of resources
correct?
Example:
Project Calendar: 24/7, 8h/d, 40h/w, 30d/m
Task name: MS-AMM, C-Check
Duration: 10 days
Start date: 1-Oct-2007
Deadline is 10-oct-2007
Work: 2760h, Fixed work
Resource: Mechanics
Resource Calendar: I hope we can use one resource calendar, 24/7, 8h/d,
40h/w and 30d/m.
Resource name: Mechanics (There is only one kind of resources)
Unit: 12000% (120 mechanics) (+ hired-in mechanics if needed)
Regards,
Brian
"Steve House" wrote:
No no, not saying that at all! Quite the contrary - IMHO Project is an
excellent tool to use for this sort of thing. The periodic maintainance
of
an individual aircraft can very easily be viewed as a project with
observable start and ending times and a unique deliverable being created.
But Project - as does adopting formal Critical Path Methodology in
general,
even when done by paper and pencil - sometimes requires a fresh approach
in
the way one looks at work and scheduling within your organization. For
example, it may be you're not presently looking at your manpower
scheduling
at a fine enough detail to effectively manage the individual workers and
their individual tasks. "Inspect Engines" is not detailed enough.
"Inspect
#1 Engine" is getting better. "Drop # 1 Engine (2 hours)," "Remove
Cowling"
(1 hour), "X-ray #1 Engine's Main Turbine Blades" (6 hours) etc etc is
getting close. Idealy it needs to get down to the point you can use
Project's task list and calculated schedule to determine that an A&P
mechanic needs to show up at a specific location at a clearly
identifiable
date and time with the appropriate parts and tools required to do a
specific
task on a specific part of the airplane and he will be forecast to have
completed it by another specific date and time so that a) you know when
he
can move on to something else that needs his skills to proceed; and b)
whoever has to do the next thing in line after him in that part of the
airplane knows when the first mechanic will be done and out of the way so
that HE can show up ready to do his part of the job.
HTH
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
"Assist" <Assist@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:128D7A03-3B66-4F3D-9B56-DF08FD853AA6@xxxxxxxxxxxxxxxx
Lets see if I got i right.
Generaly this is not what project is designed for. Do you recoment not
to
use Project for this kind of tasks?
"Steve House" wrote:
One thing to consider. The duration of a task is not normally the
"window
of opportunity" within which the task must be done. Rather it's
length
of
time between when work on the job physically commences and when it is
complete. For a simple example, imagine an incoming aircraft
requiring
only
a single maintenance item that requires 1 person to perform 8
man-hours
of
work. The plane arrives tomorrow morning and must be completed within
10
days. The nature of the work is such that once he starts on it, the
resource must focus 100% of his effort on that specific job - he
can't
'multitask' that activity with other responsibilities. That task is
NOT
a
10 day duration task. Rather it is a 1 day duration task with a
completion
deadline 10 days out. If he CAN multitask and split his time 50/50
between
that task and something else (and you choose to schedule him for both
of
them), it is a 2 day task with the resource assigned 50% and a
deadline
10
days out, and so forth. If two people can share the task with each
devoting
their full effort towards it, then each of them is doing 100% effort
and
each performs 4 hours of the 8 total required and it's a 1/2 day
duration
task with a deadline 10 days out. In each case it is either a .5 or 1
or
2
day duration task occurring within a 10 day window between when it
could
start and when it must be done. It's generally assumed that you
always
want
to schedule it to start AND END as early as possible within that
window
and
would never want lower the resource effort level in order to spread
the
duration to fill the time to the deadline unless you have no other
choice -
your objective is to "git 'er done" as soon as you possibly can that
is
consistent with the other priorities falling outside the project's
universe
and that can be done with the manpower available .
Tasks are always observable physical activity of some sort being
performed
by a resource. The duration is simply the time period over which an
observer will see action taking place on that specific activity as
distinguished from the time period over which he 'might' see activity,
if
you get the difference.
HTH and best of luck
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
"Assist" <Assist@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:97945B6F-BE44-4743-B218-F1E15EB1D948@xxxxxxxxxxxxxxxx
Hi Steve
Extremely fine answer. I will try out your ideas and get back with
my
results.
A little more info:
Our line of business is in aircraft maintenance, and strongly
regulated.
We
work 8 hours in 3 shifts. The effective work is about 7 hours or
less
in
one
shift. The mechanics is out of the team for vacation.
We know the amount of man-work-hours for every maintenance task and
we
have
the aircraft on the ground for max. amount of days (by contract with
customer). So the only variable is resources internally and
externally.
Regards, Brian from Assist
"Steve House" wrote:
If your resource calendar shows 24 hours per day working hours,
that
mean
that ONE man working 100% will perform 24 man-hours of work during
24
hours
of duration. A total of 2760 man-hours of required work to
complete
the
task spread over a duration of 10 24-hour days means that each day
276
man-hours of work will need to be accomplished. 276 hours/24 hours
per
man
= 11.5 men are required, thus 1150% resource units. It also
implies
that
none of them will get any time off for the full 10 day period and
that's
not
likely - machines might work like that but humans simply can't do
it
and
survive! It's not for nothing that around 6 to 8 hours per day is
the
defacto standard workday - that's a biologically driven limit to
human
endurance for 100% functioning beyond which productivity plummets
into
the
toilet and accident rates soar. IMHO it's an incredibly bad
practice
to
routinely schedule people for 10, 12, or 14 hour days and from a
purely
economic standpoint a firm or manager that does it formally or
informally
is
shooting themselves in the foot, incurring long term costs that far
exceed
any short term gains. But I digress.
I feel very strongly that the project calendar should NOT reflect
the
hours
of business of the organization. Rather, it should reflect the
work
hours
of ONE typical generic resource because a task breakdown is down
down
to
the
level of a task being a package of work done by ONE resource or
resource
teak working together and when you add a task to your project you
want
it
to
be scheduled reflecting that reality. The 24 hour project calendar
says
that work proceeds on all tasks 24/7 but that not usual in most
project.
Since tasks are typically assigned to one person and one person
typically
only works about 8 hours per day, the task schedule should reflect
that
it
proceeds at the rate of 8 hours per day between start and finish.
Likewise,
the resource calendar should NOT be a 24 hour calendar because the
resource
calendar for Joe Resource reflects Joe's personal working schedule
and
no
human being works 24/7 for days on end without a break, without a
meal,
without even a nap or what have you yet that's exactly what the 24
hour
calendar says is your physical reality. If you have 3 shifts
covering
in
total the 24 hour period, you have not one resource calendar but
three -
one
for days, one for swing, and one for grave. If you have a grouped
resource,
like a group of 15 welders and different members of the group work
on
each
shift - say 7 on days, 6 on swing, and 2 on grave - you would have
- Follow-Ups:
- Re: 24 hour calender 7 days a week in 3 team shift
- From: Steve House
- Re: 24 hour calender 7 days a week in 3 team shift
- Prev by Date: Re: Load leveling splits tasks
- Next by Date: Re: Progress lines
- Previous by thread: Re: Load leveling splits tasks
- Next by thread: Re: 24 hour calender 7 days a week in 3 team shift
- Index(es):
Relevant Pages
|
