I would strongly suggest you try to start thinking of "duration" as dealing
only in working hours and try to force yourself to start calling
conventional date-range clock time "elapsed time." I know it may sound like
it but I'm really not being pedantic - if you persist in defining terms your
own way it will be very difficult for you not to missread almost all the
general PM articles and reference materials you may encounter as well as
Project's own documentation. I may choose to call this thing I'm tapping my
fingers on a "cheese sandwich" if I want but it's going to be very confusing
when I hear everyone else I meet in a users group and the product
documentation itself calling it a "keyboard" <grin>. As I said, this
distinction and the methodologies that derive from it are not unique to MS
Project by any stretch of the imagination - Project follows the ANSI
standard professional PM practices as outlined in the PMBOK in these
regards.
You can use elapsed time in the fields that take duration if you wish.
Simply prefix the units with the letter "e". If I'm using Project's default
standard calendar as the project calendar and enter a task beginning Monday
at 8am with its duration entered as "24h" its finish will be calculated as
5pm Wednesday, three 8-hour day-shift working shifts later. But if I enter
it with the duration units "24eh" its finish will be 8am Tuesday, 1
conventional 24-hour clock day later. Likewise if I have a task beginning
Wednesday at 8am with a duration of 7d it will end the following Thursday at
5pm after occupying 7 8-hour work shifts. But if its duration is entered as
7ed, it will show finishing at 8am the following Wednesday after taking
place over 7 24-hour clock periods. The only downside to this is it will
really screw up any work or cost calculations plus it will show task
beginning at any hour of the day or night or day of the week. Contractor A
finishes his part of the work Saturday at 10pm and your schedule will show
contractor B who does the next task in line beginning his work Saturday
night at 10:01.
If this is really true across the board you could make the predefined 24
hour calendar as your project calendar and on the Tools Options Calendar
menu set "Hours per Day" to 24, "Hours per Week" to 168, and "Day per Month"
to 30. You need to change BOTH the Calendar and the Options page because
changes on one do not interact with the other yet they do need to be
consistent with each other. The options page setting make it so entering
"2d" in the duration field will correspond to 48 hours of duration while
setting the 24 hour calendar to be the project calendar sets it so that all
hours of the day are considered working hours, thus a 48 hour task starting
at 8am will finish after 48 working hours have passed, 8am 2 days hence.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
bob said:
"...the only time progress is made on that task is when Joe himself is
there
doing it."
Or another Joe. That is the primary issue, and obviously, I'm not
explaining
very well.
We have tasks a,b,c,d,e, etc assigned to people, teams, vendors, groups,
whatever. There might be 1,000-5,000 tasks to complete this project in a
year. We don't schedule Joe down to the macro level, hour by hour, but
rather the duration. Joe [the vendor, team, whatever] needs to begin task
b
right after task a is completed, and must finish in X days. [duration]
This provides unfettered access to the site for another
team/vendor/whatever, to begin task c.
Duration is king! We often assign Liquidated Damages of $1,000 - $5,000
per
day if they are late, or prevent the next vendor from access or continuing
the works.
We don't care when they work, how they work, or if they bring in 10 "Joes"
or 50 "Joes".
It does not matter to us. Their access to the site, and their portion of
the
works runs X days, from this date to that date. Our critical path is based
on time--not Joe's working hours or days.
I will look at the calendar and options to see if we can just use
duration.
Thanks again!
bob
"Steve House [Project MVP]" <
[email protected]>
wrote
in message news:
[email protected]...
Your organization may work 24/7 but a person doesn't and in scheduling tasks
it is the hours that the person doing the work will be there that counts.
If Joe is the one doing Task X and he works 8-5, the only hours that
work
on
task X will take place is 8 to 5 and the fact that there are thousands of
other people working after 5pm doesn't mean anything - they aren't Joe
and
the only time progress is made on that task is when Joe himself is there
doing it.
It's not that MS Project is unique in this - the idea that task duration
only involves working time is one of the core concepts of critical path
scheduling whether by computer software or old-fashioned paper and pencil.
You may not have seen it yet but when you link your 5 tasks and indent them
under a summary task you'll discover that durations of subtasks aren't
additive. The duration of a summary task is the number of working time
units between when the earliest child task begins and when the latest child
ends. Consider a summary with 5 subtasks of 1, 2, 3, 4, and 5 days
duration. IF they aren't linked at all, the duration of the summary is 5
days. If they are linked in sequence FS, the summary will be 15 days. But
if you insert a 2 week lag time between tasks 3 and 4, for example, the
duration of the summary will be 25 days. Or if 3 and 4 run in parallel, the
duration of the summary will be 12 days.
Or try this ... create a task that lasts 10 days, starting Monday in one
week and ending the end of the day on Friday the following week. The
elapsed time is a tad under 12 days but the duration is 10 days. Even
clearer, the elapsed time is 248 hours but the duration is 80 hours. Now
use the task bar button to split the task and insert a two week gap in
the
middle. Now the elapsed time will be something on the order of a month,
4
weeks. But the duration? .... still 10 days! That's because the gap is
considered non-working time and simply doesn't exist as far as the
scheduling calculations are concerned.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
It appears that MSProj is based completely on hours in a work day,
days
in
a
week, and no way around it. We work 24/7/365, and factories, shipments,
and
planes don't stop at 5 pm. No matter what we try, we cannot get a 10
day
duration to actually be "10 days". Trying to get weekend into normal work
days causes other problems.
Here is an example of what we need:
taska 10 days
taskb 10 days
taskc 10 days
taskd 10 days
taske 10 days.
[and ignore workdays, workweek, hours, etc]
Now chain them into finish > start links and we hope to see a parent
duration of 50 days. It's probably simple, but we can't do it.
Can this be done?
Many thanks.
) the user has to define.