M
MissionChris
How is it possible to set the "duration" days to be actual days, not just
working days?
working days?
M
Mike Glen
Hi Chris,
Welcome to this Microsoft Project newsgroup
You can add a prefix e for elapsed duration eg 10 edays.
FAQs, companion products and other useful Project information can be seen at
this web address: http://www.mvps.org/project/
Hope this helps - please let us know how you get on
Mike Glen
MS Project MVP
Welcome to this Microsoft Project newsgroup
You can add a prefix e for elapsed duration eg 10 edays.
FAQs, companion products and other useful Project information can be seen at
this web address: http://www.mvps.org/project/
Hope this helps - please let us know how you get on
Mike Glen
MS Project MVP
S
Steve House [Project MVP]
As Mike said, you can use elapsed time rather than working time by prefixing
the unit with "e" as in "3ed" for 3 elapsed days. But you should do this
with a very clear understanding of what it means and what the problems in
developing a valid schedule are that it will cause you. When you use
elapsed time, you are NOT measuring the duration - duration is *defined* as
the number of working time units between when the task starts and when it
ends. Other time measurements might be interesting and/or useful but they
are *not* duration and calling it so doesn't work any better than calling
an apple an orange makes its flavour tart and citrusy.
Duration is more important than elapsed time in calculating the schedule
because paradoxically we are doing the exercie in order to detemrine how
long it will take, the elasped time, between when we can start work on the
project and when we will have completed it. But work on the project's tasks
only proceeds when the resources required to do it are physically present
and able to do them, the only time that counts, in other words, is scheduled
working hours. The project produces a finite deliverable and requires a
specific amount of work to create it. So the length of time by the calendar
on the wall to complete the required work depends not only on the AMOUNT of
work but the RATE at which it is being performed, how many hours out of each
day will actually be productive. If my project is to build 100 widgets,
the number of calendar days it will take me depends on how many widgets a
day I can build and that is directly affected by the number of hours a day I
work at building widgets. If I can build 1 widget an hour and work 2 hours
a day, 5 days a week it will take me 10 weeks to build the 100 widgets. If
I work 2 hours a day 7 days a week, it will take a bit over 7 weeks to build
them. If I work 8 hours a day 5 days a week it will take 2.5 weeks to build
them. If I work 24 hours a day, 7 days a week it will take about 4+days to
build them. All for the same 100 widgets. And that's why you really should
reconsider your plan of using elapsed time instead true duration - if you go
ahead with that idea, it ignores the rate at which work can take place and
makes it impossible to predict how long it's going to take to deliver your
required output.
the unit with "e" as in "3ed" for 3 elapsed days. But you should do this
with a very clear understanding of what it means and what the problems in
developing a valid schedule are that it will cause you. When you use
elapsed time, you are NOT measuring the duration - duration is *defined* as
the number of working time units between when the task starts and when it
ends. Other time measurements might be interesting and/or useful but they
are *not* duration and calling it so doesn't work any better than calling
an apple an orange makes its flavour tart and citrusy.
Duration is more important than elapsed time in calculating the schedule
because paradoxically we are doing the exercie in order to detemrine how
long it will take, the elasped time, between when we can start work on the
project and when we will have completed it. But work on the project's tasks
only proceeds when the resources required to do it are physically present
and able to do them, the only time that counts, in other words, is scheduled
working hours. The project produces a finite deliverable and requires a
specific amount of work to create it. So the length of time by the calendar
on the wall to complete the required work depends not only on the AMOUNT of
work but the RATE at which it is being performed, how many hours out of each
day will actually be productive. If my project is to build 100 widgets,
the number of calendar days it will take me depends on how many widgets a
day I can build and that is directly affected by the number of hours a day I
work at building widgets. If I can build 1 widget an hour and work 2 hours
a day, 5 days a week it will take me 10 weeks to build the 100 widgets. If
I work 2 hours a day 7 days a week, it will take a bit over 7 weeks to build
them. If I work 8 hours a day 5 days a week it will take 2.5 weeks to build
them. If I work 24 hours a day, 7 days a week it will take about 4+days to
build them. All for the same 100 widgets. And that's why you really should
reconsider your plan of using elapsed time instead true duration - if you go
ahead with that idea, it ignores the rate at which work can take place and
makes it impossible to predict how long it's going to take to deliver your
required output.