Elapsed durations

[DavidC]

Hi,

All the commentary and documentation indicates that elapsed duration is
independant of the calendar settings. It is logical then that a task
starting on the 1st of the month and ending 2 elapsed months later, would
then finish on the 1st of the month two months hence. However, I have
noticed an oddity with this function. A task with an elpased time of 5
months and starting on the 8th of the month, actually ends on the 4th of the
month, effectively shortening up the time by 4 days. In reality I am not
overly concerned with this difference, but I have been quized as to why the
difference and have no answer.

Any thoughts please.

regards

DavidC

 

[DavidC]

Sorry, should be 9 elapsed months to give that discrepency. I have tried
using a lag of 9emo, and a duraiton of 9emo, and they both give the same
answer. Start date is 8th october, end date is 4th July, not 8th July as
expected.

regards

DavidC

 

[JulieS]

Hello David,

I believe the definition of an elapsed month is 30 calendar days.
Things get a bit "off" when months have 31 days. If you start a task
on March 1 and enter a 4 emon duration you'll see it end on June 29 --
120 days later but not the last day in June.

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

 

[DavidC]

I suspect you are right with that analysis, it would fit the discrepency. A
pity though that it can't be defined as exactly that a calendar month. Still
good to have some confirmation of what the underlying problem is.

Regards

DavidC

 

[JulieS]

You're welcome David. Bear in mind that Project works with definitions
that are set by the user -- the number of hours per day, the number of
hours per week, and the number of days per month. Those definitions
are there to allow us to use time measurements of larger than an hour
in duration definitions. It's actually the calendar that is odd --
some months having 30 days, some having 31 days and then of course
there's the 28 or 29 day February

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

 

[Steve House]

I'm not sure it IS a problem. Elapsed time is, well, a measure of the
passage of time. Tasks produce deliverables. But deliverables are
generated by the performance of work, not by the passage of time. The
length of time between 15 Feb and 15 March means nothing in terms of what a
task can produce, but the amount of working time between those two dates is
crucial as far as the quantity of deliverable that can be produced. Since
tasks are required to produce an exact measurable quantity of deliverable,
no more and no less, the elapsed time (with certain very rare exceptions) is
a meaningless measure. Elapsed time does not by itself imply the amount of
working time one has in which to create deliverable. So Duration as defined
by working time units, ie, the Working Time Calendar, is all that actually
matters in terms of driving the project forward. If the task is to produce
100 widgets and 1 widget requires 1 man-hour of work, the elapsed time will
be whatever time period encompasses 100 man-hours of work. Specifying the
task by the elapsed time is putting the cart before the horse.

 

[DavidC]

Steve,

Sorry to rake this up after such a long time, but I do have a problem that
needs to be overcome.

A project agreement requires that we order equipment within 5 months of the
end of an activity lets say a statutory authority approval. Hence my sequence
of procurement needs to have a deadline 5 months from the date the stautory
approval is given. However that approval has its own process so the date is
unknown and is in itself a sub project. So I need to have the milestone not
as a hard date but a linked date to the approval.

To complicate matters further I have since found other contractual dates
which effectively extinguish the contract after 6 years, so this project has
a number of deliverables that must be completed before the expiry of the 6
years. Without going into all the details that surround this project, it is
important that I have this milestone in place exactly 6 years after an event,
but using 72emo does not give me six years but 5 years and 11 months
(roughly). I guess what I am wondering is if there is some sneaky way of
having Project calculate a date exatly 6 years froma sepcific activity. The
project is tight for various reasons meaning that I need these dates to be as
accurate as possible and a one month variance causes some consternation among
management.

Any thoughts would be welcome.

regards

DavidC

I'm not sure it IS a problem. Elapsed time is, well, a measure of the
passage of time. Tasks produce deliverables. But deliverables are
generated by the performance of work, not by the passage of time. The
length of time between 15 Feb and 15 March means nothing in terms of what a
task can produce, but the amount of working time between those two dates is
crucial as far as the quantity of deliverable that can be produced. Since
tasks are required to produce an exact measurable quantity of deliverable,
no more and no less, the elapsed time (with certain very rare exceptions) is
a meaningless measure. Elapsed time does not by itself imply the amount of
working time one has in which to create deliverable. So Duration as defined
by working time units, ie, the Working Time Calendar, is all that actually
matters in terms of driving the project forward. If the task is to produce
100 widgets and 1 widget requires 1 man-hour of work, the elapsed time will
be whatever time period encompasses 100 man-hours of work. Specifying the
task by the elapsed time is putting the cart before the horse.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs

I suspect you are right with that analysis, it would fit the discrepency.
A
pity though that it can't be defined as exactly that a calendar month.
Still
good to have some confirmation of what the underlying problem is.

Regards

DavidC

 

[John]

Steve,

Sorry to rake this up after such a long time, but I do have a problem that
needs to be overcome.

A project agreement requires that we order equipment within 5 months of the
end of an activity lets say a statutory authority approval. Hence my sequence
of procurement needs to have a deadline 5 months from the date the stautory
approval is given. However that approval has its own process so the date is
unknown and is in itself a sub project. So I need to have the milestone not
as a hard date but a linked date to the approval.

To complicate matters further I have since found other contractual dates
which effectively extinguish the contract after 6 years, so this project has
a number of deliverables that must be completed before the expiry of the 6
years. Without going into all the details that surround this project, it is
important that I have this milestone in place exactly 6 years after an event,
but using 72emo does not give me six years but 5 years and 11 months
(roughly). I guess what I am wondering is if there is some sneaky way of
having Project calculate a date exatly 6 years froma sepcific activity. The
project is tight for various reasons meaning that I need these dates to be as
accurate as possible and a one month variance causes some consternation among
management.

Any thoughts would be welcome.

regards

DavidC

DavidC,
Without trying to analyze your plan and approach, let's just take a look
at the basics of dealing with duration in Project.

Unfortunately "years" is not a duration period that Project accepts.
Further, as you are well aware, Project's calculation of months in the
Duration field is based on an average since each month varies. However,
days and hours are "stable". In other words, 1 year is 365ed (at least
within reasonable resolution). This will work as long as the end date
after 5 years falls on a working day. Otherwise Project will move the
end date to the next normal working day.

Hope this helps.
John
Project MVP

I'm not sure it IS a problem. Elapsed time is, well, a measure of the
passage of time. Tasks produce deliverables. But deliverables are
generated by the performance of work, not by the passage of time. The
length of time between 15 Feb and 15 March means nothing in terms of what a
task can produce, but the amount of working time between those two dates is
crucial as far as the quantity of deliverable that can be produced. Since
tasks are required to produce an exact measurable quantity of deliverable,
no more and no less, the elapsed time (with certain very rare exceptions)
is
a meaningless measure. Elapsed time does not by itself imply the amount of
working time one has in which to create deliverable. So Duration as
defined
by working time units, ie, the Working Time Calendar, is all that actually
matters in terms of driving the project forward. If the task is to produce
100 widgets and 1 widget requires 1 man-hour of work, the elapsed time will
be whatever time period encompasses 100 man-hours of work. Specifying the
task by the elapsed time is putting the cart before the horse.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs

I suspect you are right with that analysis, it would fit the discrepency.
A
pity though that it can't be defined as exactly that a calendar month.
Still
good to have some confirmation of what the underlying problem is.

Regards

DavidC

:

Hello David,

I believe the definition of an elapsed month is 30 calendar days.
Things get a bit "off" when months have 31 days. If you start a task
on March 1 and enter a 4 emon duration you'll see it end on June 29 --
120 days later but not the last day in June.

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



Hi,

All the commentary and documentation indicates that elapsed duration
is
independant of the calendar settings. It is logical then that a
task
starting on the 1st of the month and ending 2 elapsed months later,
would
then finish on the 1st of the month two months hence. However, I
have
noticed an oddity with this function. A task with an elpased time
of 5
months and starting on the 8th of the month, actually ends on the
4th of the
month, effectively shortening up the time by 4 days. In reality I
am not
overly concerned with this difference, but I have been quized as to
why the
difference and have no answer.

Any thoughts please.

regards

DavidC

 

[DavidC]

John,

Thanks. It is so obvious now. I keep trying to think of using the longest
time period for duration, but of course it can cause calculation problems
given the averaging of days in a month.

Sorry to have bothered you on such a mundane thing.

Regards

DavidC

Steve,

Sorry to rake this up after such a long time, but I do have a problem that
needs to be overcome.

A project agreement requires that we order equipment within 5 months of the
end of an activity lets say a statutory authority approval. Hence my sequence
of procurement needs to have a deadline 5 months from the date the stautory
approval is given. However that approval has its own process so the date is
unknown and is in itself a sub project. So I need to have the milestone not
as a hard date but a linked date to the approval.

To complicate matters further I have since found other contractual dates
which effectively extinguish the contract after 6 years, so this project has
a number of deliverables that must be completed before the expiry of the 6
years. Without going into all the details that surround this project, it is
important that I have this milestone in place exactly 6 years after an event,
but using 72emo does not give me six years but 5 years and 11 months
(roughly). I guess what I am wondering is if there is some sneaky way of
having Project calculate a date exatly 6 years froma sepcific activity. The
project is tight for various reasons meaning that I need these dates to be as
accurate as possible and a one month variance causes some consternation among
management.

Any thoughts would be welcome.

regards

DavidC

DavidC,
Without trying to analyze your plan and approach, let's just take a look
at the basics of dealing with duration in Project.

Unfortunately "years" is not a duration period that Project accepts.
Further, as you are well aware, Project's calculation of months in the
Duration field is based on an average since each month varies. However,
days and hours are "stable". In other words, 1 year is 365ed (at least
within reasonable resolution). This will work as long as the end date
after 5 years falls on a working day. Otherwise Project will move the
end date to the next normal working day.

Hope this helps.
John
Project MVP

I'm not sure it IS a problem. Elapsed time is, well, a measure of the
passage of time. Tasks produce deliverables. But deliverables are
generated by the performance of work, not by the passage of time. The
length of time between 15 Feb and 15 March means nothing in terms of what a
task can produce, but the amount of working time between those two dates is
crucial as far as the quantity of deliverable that can be produced. Since
tasks are required to produce an exact measurable quantity of deliverable,
no more and no less, the elapsed time (with certain very rare exceptions)
is
a meaningless measure. Elapsed time does not by itself imply the amount of
working time one has in which to create deliverable. So Duration as
defined
by working time units, ie, the Working Time Calendar, is all that actually
matters in terms of driving the project forward. If the task is to produce
100 widgets and 1 widget requires 1 man-hour of work, the elapsed time will
be whatever time period encompasses 100 man-hours of work. Specifying the
task by the elapsed time is putting the cart before the horse.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs



I suspect you are right with that analysis, it would fit the discrepency.
A
pity though that it can't be defined as exactly that a calendar month.
Still
good to have some confirmation of what the underlying problem is.

Regards

DavidC

:

Hello David,

I believe the definition of an elapsed month is 30 calendar days.
Things get a bit "off" when months have 31 days. If you start a task
on March 1 and enter a 4 emon duration you'll see it end on June 29 --
120 days later but not the last day in June.

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



Hi,

All the commentary and documentation indicates that elapsed duration
is
independant of the calendar settings. It is logical then that a
task
starting on the 1st of the month and ending 2 elapsed months later,
would
then finish on the 1st of the month two months hence. However, I
have
noticed an oddity with this function. A task with an elpased time
of 5
months and starting on the 8th of the month, actually ends on the
4th of the
month, effectively shortening up the time by 4 days. In reality I
am not
overly concerned with this difference, but I have been quized as to
why the
difference and have no answer.

Any thoughts please.

regards

DavidC

 

[John]

John,

Thanks. It is so obvious now. I keep trying to think of using the longest
time period for duration, but of course it can cause calculation problems
given the averaging of days in a month.

Sorry to have bothered you on such a mundane thing.

Regards

DavidC

DavidC,
You're welcome and you don't have to apologize for posting a legitimate
question. That's why this newsgroup exists.

John
Project MVP

Steve,

Sorry to rake this up after such a long time, but I do have a problem
that
needs to be overcome.

A project agreement requires that we order equipment within 5 months of
the
end of an activity lets say a statutory authority approval. Hence my
sequence
of procurement needs to have a deadline 5 months from the date the
stautory
approval is given. However that approval has its own process so the date
is
unknown and is in itself a sub project. So I need to have the milestone
not
as a hard date but a linked date to the approval.

To complicate matters further I have since found other contractual dates
which effectively extinguish the contract after 6 years, so this project
has
a number of deliverables that must be completed before the expiry of the
6
years. Without going into all the details that surround this project, it
is
important that I have this milestone in place exactly 6 years after an
event,
but using 72emo does not give me six years but 5 years and 11 months
(roughly). I guess what I am wondering is if there is some sneaky way of
having Project calculate a date exatly 6 years froma sepcific activity.
The
project is tight for various reasons meaning that I need these dates to
be as
accurate as possible and a one month variance causes some consternation
among
management.

Any thoughts would be welcome.

regards

DavidC

DavidC,
Without trying to analyze your plan and approach, let's just take a look
at the basics of dealing with duration in Project.

Unfortunately "years" is not a duration period that Project accepts.
Further, as you are well aware, Project's calculation of months in the
Duration field is based on an average since each month varies. However,
days and hours are "stable". In other words, 1 year is 365ed (at least
within reasonable resolution). This will work as long as the end date
after 5 years falls on a working day. Otherwise Project will move the
end date to the next normal working day.

Hope this helps.
John
Project MVP

:

I'm not sure it IS a problem. Elapsed time is, well, a measure of the
passage of time. Tasks produce deliverables. But deliverables are
generated by the performance of work, not by the passage of time. The
length of time between 15 Feb and 15 March means nothing in terms of
what a
task can produce, but the amount of working time between those two
dates is
crucial as far as the quantity of deliverable that can be produced.
Since
tasks are required to produce an exact measurable quantity of
deliverable,
no more and no less, the elapsed time (with certain very rare
exceptions)
is
a meaningless measure. Elapsed time does not by itself imply the amount
of
working time one has in which to create deliverable. So Duration as
defined
by working time units, ie, the Working Time Calendar, is all that
actually
matters in terms of driving the project forward. If the task is to
produce
100 widgets and 1 widget requires 1 man-hour of work, the elapsed time
will
be whatever time period encompasses 100 man-hours of work. Specifying
the
task by the elapsed time is putting the cart before the horse.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs



I suspect you are right with that analysis, it would fit the
discrepency.
A
pity though that it can't be defined as exactly that a calendar
month.
Still
good to have some confirmation of what the underlying problem is.

Regards

DavidC

:

Hello David,

I believe the definition of an elapsed month is 30 calendar days.
Things get a bit "off" when months have 31 days. If you start a
task
on March 1 and enter a 4 emon duration you'll see it end on June 29
--
120 days later but not the last day in June.

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



Hi,

All the commentary and documentation indicates that elapsed
duration
is
independant of the calendar settings. It is logical then that a
task
starting on the 1st of the month and ending 2 elapsed months
later,
would
then finish on the 1st of the month two months hence. However, I
have
noticed an oddity with this function. A task with an elpased time
of 5
months and starting on the 8th of the month, actually ends on the
4th of the
month, effectively shortening up the time by 4 days. In reality I
am not
overly concerned with this difference, but I have been quized as
to
why the
difference and have no answer.

Any thoughts please.

regards

DavidC