Tasks duration (errors?)

A

AB

I have a task that I want to start on March 1st, 2007. I know it should take
4 month... so I enter that too. Now, MS Project 2003 shows the end of it
June 6th, 2007, while I was expecting it to be July the 1st. Why is it doing
it? How many (working) days does Project assign to 'month'?

I had to put 17.4 weeks -- 52.14/12*4 = 17.4 (weeks-per-year /
months-per-year * 4 months) 365 days)/ (7 days/week)-- to get it right, but
I don't think this should be the right way to do it....

Thanks
 
J

Jan De Messemaeker

Hi,

Sorry but Project only uses one unit of time for its calculation, the
minute.
You have to define what you mean by "a day" , "a week" and "a month".
You can find and change that definition in Tools, Options, Calendar
Do also verify whether the definition for a day ois consistent with the
working time: if not you may get soem unexpected results.
HTH
 
S

Steve House [Project MVP]

The number of working days Project considers a "month" is set in the Tools,
Options menu, Calendar page. The default is 20 days. So if you enter a
task's duration as "4 months" Project says that it is 80 working days. At 8
hours per day that means the duration is 640 working hours. It then begins
at the task's start date and time and counts off 640 working hours as
defined in the working time calendar to come up with the finish date.

Project's task durations should almost always measured and recorded in
working time hours instead of elapsed clock time hours. Think about it a
sec and you'll see why. The task only proceeds when someone is there doing
it. If it will require 16 hours to complete it, will take more elapsed time
to get it done when you only work on it in drips and drabs than if you work
on it in one continuous block. The only thing that counts towards
completing it is the time you spend actively do it.

HTH
 
A

AB

Steve, thank you for your answer.
I fully agree with what you say. My problem was that 20 working days
per months didn't match the rest of my project... I re-defined it to 22
(actually 21.72, without taking vacations and days off). So now when I "say"
4 months, it actually shows 4 calendar months (or 88 working days).


Thanks again for your comments...

AB

Steve House said:
The number of working days Project considers a "month" is set in the Tools,
Options menu, Calendar page. The default is 20 days. So if you enter a
task's duration as "4 months" Project says that it is 80 working days. At 8
hours per day that means the duration is 640 working hours. It then begins
at the task's start date and time and counts off 640 working hours as
defined in the working time calendar to come up with the finish date.

Project's task durations should almost always measured and recorded in
working time hours instead of elapsed clock time hours. Think about it a
sec and you'll see why. The task only proceeds when someone is there doing
it. If it will require 16 hours to complete it, will take more elapsed time
to get it done when you only work on it in drips and drabs than if you work
on it in one continuous block. The only thing that counts towards
completing it is the time you spend actively do it.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


AB said:
I have a task that I want to start on March 1st, 2007. I know it should
take
4 month... so I enter that too. Now, MS Project 2003 shows the end of it
June 6th, 2007, while I was expecting it to be July the 1st. Why is it
doing
it? How many (working) days does Project assign to 'month'?

I had to put 17.4 weeks -- 52.14/12*4 = 17.4 (weeks-per-year /
months-per-year * 4 months) 365 days)/ (7 days/week)-- to get it right,
but
I don't think this should be the right way to do it....

Thanks
 
S

Steve House [MVP]

But what about February? or leap years? Given any arbitrary date, exactly
1 calendar month later won't always be 22 working days later (or 20 or 21 or
any other number you might come up with). Why do you want to say that a
task lasts 4 calendar months anyway? In terms of predicting when it will
finish given the date it starts, the only thing that counts is the amount of
time a worker spends actively engaged in the task and calendar elapsed time
spans don't convey any information about productive time.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



AB said:
Steve, thank you for your answer.
I fully agree with what you say. My problem was that 20 working days
per months didn't match the rest of my project... I re-defined it to 22
(actually 21.72, without taking vacations and days off). So now when I
"say"
4 months, it actually shows 4 calendar months (or 88 working days).


Thanks again for your comments...

AB

Steve House said:
The number of working days Project considers a "month" is set in the
Tools,
Options menu, Calendar page. The default is 20 days. So if you enter a
task's duration as "4 months" Project says that it is 80 working days.
At 8
hours per day that means the duration is 640 working hours. It then
begins
at the task's start date and time and counts off 640 working hours as
defined in the working time calendar to come up with the finish date.

Project's task durations should almost always measured and recorded in
working time hours instead of elapsed clock time hours. Think about it a
sec and you'll see why. The task only proceeds when someone is there
doing
it. If it will require 16 hours to complete it, will take more elapsed
time
to get it done when you only work on it in drips and drabs than if you
work
on it in one continuous block. The only thing that counts towards
completing it is the time you spend actively do it.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


AB said:
I have a task that I want to start on March 1st, 2007. I know it should
take
4 month... so I enter that too. Now, MS Project 2003 shows the end of
it
June 6th, 2007, while I was expecting it to be July the 1st. Why is it
doing
it? How many (working) days does Project assign to 'month'?

I had to put 17.4 weeks -- 52.14/12*4 = 17.4 (weeks-per-year /
months-per-year * 4 months) 365 days)/ (7 days/week)-- to get it
right,
but
I don't think this should be the right way to do it....

Thanks
 
B

Baby Dork

Steve... I'm sorry to jump in during your conversation however; I have a
question concerning time entered. Most of my Projects last at least 10
years, are defined by multiple "Tiers" and have well over 250 tasks (per
Project) that have no commonalty within any of the task names.
Unfortunately, (maybe for me) the dates that I enter have to be reflected
EXACTLY the way I enter them (because “Uncle Sam†said so) - MSP cannot
calculate/recalculate them in anyway. With that said, what should be entered
as far as the "20" days worked within a month so that MSP doesn't change my
dates? Am I ___ out of luck?

It would be awesome if you could answer my next question as well (I have
faith in you Steve). One of the other problems that I'm experiencing has to
do with linking tasks between Projects. I’ve created a Master Project by
combining four separate Projects through importing (this was what someone
told me to do within this group). Many of my tasks are used multiple times,
which seems to confuse MSP when linking/grouping occurs (could be that I’m
confused as well). What I ultimately need is to be able to see only the
“Basic†overall Project when first viewed. If the person viewing the Project
needs further definition of a task, they should be able to “click†on an icon
(whatever) and all of the other tasks/subtasks that pertain to the first open
up below it. I hope this makes since.
"Sorry about the display name"
Steve House said:
But what about February? or leap years? Given any arbitrary date, exactly
1 calendar month later won't always be 22 working days later (or 20 or 21 or
any other number you might come up with). Why do you want to say that a
task lasts 4 calendar months anyway? In terms of predicting when it will
finish given the date it starts, the only thing that counts is the amount of
time a worker spends actively engaged in the task and calendar elapsed time
spans don't convey any information about productive time.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



AB said:
Steve, thank you for your answer.
I fully agree with what you say. My problem was that 20 working days
per months didn't match the rest of my project... I re-defined it to 22
(actually 21.72, without taking vacations and days off). So now when I
"say"
4 months, it actually shows 4 calendar months (or 88 working days).


Thanks again for your comments...

AB

Steve House said:
The number of working days Project considers a "month" is set in the
Tools,
Options menu, Calendar page. The default is 20 days. So if you enter a
task's duration as "4 months" Project says that it is 80 working days.
At 8
hours per day that means the duration is 640 working hours. It then
begins
at the task's start date and time and counts off 640 working hours as
defined in the working time calendar to come up with the finish date.

Project's task durations should almost always measured and recorded in
working time hours instead of elapsed clock time hours. Think about it a
sec and you'll see why. The task only proceeds when someone is there
doing
it. If it will require 16 hours to complete it, will take more elapsed
time
to get it done when you only work on it in drips and drabs than if you
work
on it in one continuous block. The only thing that counts towards
completing it is the time you spend actively do it.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I have a task that I want to start on March 1st, 2007. I know it should
take
4 month... so I enter that too. Now, MS Project 2003 shows the end of
it
June 6th, 2007, while I was expecting it to be July the 1st. Why is it
doing
it? How many (working) days does Project assign to 'month'?

I had to put 17.4 weeks -- 52.14/12*4 = 17.4 (weeks-per-year /
months-per-year * 4 months) 365 days)/ (7 days/week)-- to get it
right,
but
I don't think this should be the right way to do it....

Thanks
 
S

Steve House

A couple of different issues. Project is a tool to develope schedules -
you don't tell it dates, it tells you dates. If you already know the
dates when tasks will occur, Project is redundent. Of course, reality
has to modify that posture just a shade and the dates you're trying to
input are the dates on which someone has determined the tasks are
supposed to occur. So what does it mean if Task X is supposed to occur
on 01 Feb but Project insists on scheduling it on 15 Feb? It means that
according to the links in your plan, etc, there are certain things that
have to happen, some preparatory work that MUST be completed in order
for Task X to begin, and unfortunately that work won't be done until 15
Feb. No matter how badly you want it to start on the 1st, no matter how
mission critical it is that it start on the 1st, Task X CAN'T start on
the first becase the required resources aren't there or the parts
haven't arrived or a crucial preparatory process hasn't been completed
or something like that. The solution is not to try to force Project not
to change the date and display the desired date - the solution is to
figure out what is going on before that task that is the hangup, address
that bottleneck, and get the prep work done earlier, on time to let the
task start on the 1st as it should. Maybe a critical part is taking 3
weeks to fabricate and by calling in overtime you can get it done in 1
and a half weeks. Maybe the vendor of a certain component has it on
backorder so you have to find another vendor. Remember, Project is
telling you what it is you must do in order to insure you get the
schedule you need by telling you the schedule you will be able to
successfully achieve IF you organize the work the way you've told
Project you're going to do it. If it's telling you it's not going to
work out, believe it and change the way you've organized the work.
Managers are like battlefield commanders - they deploy resources in the
manner that best achieves the required objectives - Project is
forecasting what you'll get if you go with your present deployment
plan - if it doesn't achieve the objective, change the order of battle.

The "20 days per month" setting won't affect you need. That is simply a
conversion factor - project stores all its durations in minutes, so when
I say a task will last "3 months" how many working time minutes is that?
That's all that setting controls.

Can you be a little more explicit what you need with what you're asking
about in your last paragraph?
--
Steve House
MS Project MVP
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Baby Dork said:
Steve... I'm sorry to jump in during your conversation however; I have a
question concerning time entered. Most of my Projects last at least 10
years, are defined by multiple "Tiers" and have well over 250 tasks (per
Project) that have no commonalty within any of the task names.
Unfortunately, (maybe for me) the dates that I enter have to be reflected
EXACTLY the way I enter them (because "Uncle Sam" said so) - MSP cannot
calculate/recalculate them in anyway. With that said, what should be entered
as far as the "20" days worked within a month so that MSP doesn't change my
dates? Am I ___ out of luck?

It would be awesome if you could answer my next question as well (I have
faith in you Steve). One of the other problems that I'm experiencing has to
do with linking tasks between Projects. I've created a Master Project by
combining four separate Projects through importing (this was what someone
told me to do within this group). Many of my tasks are used multiple times,
which seems to confuse MSP when linking/grouping occurs (could be that I'm
confused as well). What I ultimately need is to be able to see only the
"Basic" overall Project when first viewed. If the person viewing the Project
needs further definition of a task, they should be able to "click" on an icon
(whatever) and all of the other tasks/subtasks that pertain to the first open
up below it. I hope this makes since.
"Sorry about the display name"
Steve House said:
But what about February? or leap years? Given any arbitrary date, exactly
1 calendar month later won't always be 22 working days later (or 20 or 21 or
any other number you might come up with). Why do you want to say that a
task lasts 4 calendar months anyway? In terms of predicting when it will
finish given the date it starts, the only thing that counts is the amount of
time a worker spends actively engaged in the task and calendar elapsed time
spans don't convey any information about productive time.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



AB said:
Steve, thank you for your answer.
I fully agree with what you say. My problem was that 20 working days
per months didn't match the rest of my project... I re-defined it to 22
(actually 21.72, without taking vacations and days off). So now when I
"say"
4 months, it actually shows 4 calendar months (or 88 working days).


Thanks again for your comments...

AB

:

The number of working days Project considers a "month" is set in the
Tools,
Options menu, Calendar page. The default is 20 days. So if you enter a
task's duration as "4 months" Project says that it is 80 working days.
At 8
hours per day that means the duration is 640 working hours. It then
begins
at the task's start date and time and counts off 640 working hours as
defined in the working time calendar to come up with the finish date.

Project's task durations should almost always measured and recorded in
working time hours instead of elapsed clock time hours. Think about it a
sec and you'll see why. The task only proceeds when someone is there
doing
it. If it will require 16 hours to complete it, will take more elapsed
time
to get it done when you only work on it in drips and drabs than if you
work
on it in one continuous block. The only thing that counts towards
completing it is the time you spend actively do it.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I have a task that I want to start on March 1st, 2007. I know it should
take
4 month... so I enter that too. Now, MS Project 2003 shows the end of
it
June 6th, 2007, while I was expecting it to be July the 1st. Why is it
doing
it? How many (working) days does Project assign to 'month'?

I had to put 17.4 weeks -- 52.14/12*4 = 17.4 (weeks-per-year /
months-per-year * 4 months) 365 days)/ (7 days/week)-- to get it
right,
but
I don't think this should be the right way to do it....

Thanks
 
T

Tina

I need some QUICK HELP!
Before I start the Project (in Project), how do I set up the calendar to be
a 7 day work week, so I don't run into the Duration/Finish date issues? If I
start a Task on 2/1/08 (and it is a 21 day duration), I need it to say
"2/21/08" (mine keeps saying 2/29/08). PLEASE HELP?

Steve House said:
The number of working days Project considers a "month" is set in the Tools,
Options menu, Calendar page. The default is 20 days. So if you enter a
task's duration as "4 months" Project says that it is 80 working days. At 8
hours per day that means the duration is 640 working hours. It then begins
at the task's start date and time and counts off 640 working hours as
defined in the working time calendar to come up with the finish date.

Project's task durations should almost always measured and recorded in
working time hours instead of elapsed clock time hours. Think about it a
sec and you'll see why. The task only proceeds when someone is there doing
it. If it will require 16 hours to complete it, will take more elapsed time
to get it done when you only work on it in drips and drabs than if you work
on it in one continuous block. The only thing that counts towards
completing it is the time you spend actively do it.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


AB said:
I have a task that I want to start on March 1st, 2007. I know it should
take
4 month... so I enter that too. Now, MS Project 2003 shows the end of it
June 6th, 2007, while I was expecting it to be July the 1st. Why is it
doing
it? How many (working) days does Project assign to 'month'?

I had to put 17.4 weeks -- 52.14/12*4 = 17.4 (weeks-per-year /
months-per-year * 4 months) 365 days)/ (7 days/week)-- to get it right,
but
I don't think this should be the right way to do it....

Thanks
 
S

Steve House

It's a little unclear just what you're trying to do or why you think you
need to do it. There are no Start/Finish issues with the "problem" you
describe because there isn't a problem there. Duration is defined as the
amount of working time between when a task begins and when it's done,
specifically excluding any non-working time. It isn't a peculiarity of MS
Project - it's the ANSI-accepted textbook definition of what a task's and/or
a project's duration really and truly is. I can appreciate that you might
have some reason to do it differently but you must understand if you do
you're not talking about duration any more and are deviating from the
generally accepted standards of project management.

Tasks are activities done by people and people don't work 24/7. Does an
individual worker in your organization work 7 days a week? If I have x days
worth of work for you to do, don't the dates between when you start it and
when you finish it include some of your days off where no work gets done?
If you (and you alone) must write a big report that requires 20 days worth
of work and you can start it Monday, won't it go for 5 days, stop for 2, go
another 5, etc, until you have done a total of 20 days over the course of a
total of 4 weeks. And because of those days off won't there be about 30
days of total elapsed time inclduing time off between the date you start and
the date you finish it?

Project's durations should be an accurate model of what you'd see if you
were standing there watching the person doing to work as they do it.

The dates you say you want to see, 01 Feb to 21 Feb, do not describe a 21
days task. The true duration only counts the time during which physical
progress towards the finish is taking place and would be 21 days MINUS how
ever many days the resource assigned doesn't come to work.

Now in the off chance that what you ask really does describe physical
reality in your organization, go to the Tools menu, Change Working Time, and
create a calendar where all 7 days of the week are working days. If this is
global for all tasks, then go to the Calendar Options and set hours per week
to 56 (7*8, assuming people work 8 hours per day). But be very very careful
before deciding to handle it that way because it can have profound
implications as to your schedule and your budget


--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs



Tina said:
I need some QUICK HELP!
Before I start the Project (in Project), how do I set up the calendar to
be
a 7 day work week, so I don't run into the Duration/Finish date issues?
If I
start a Task on 2/1/08 (and it is a 21 day duration), I need it to say
"2/21/08" (mine keeps saying 2/29/08). PLEASE HELP?

Steve House said:
The number of working days Project considers a "month" is set in the
Tools,
Options menu, Calendar page. The default is 20 days. So if you enter a
task's duration as "4 months" Project says that it is 80 working days.
At 8
hours per day that means the duration is 640 working hours. It then
begins
at the task's start date and time and counts off 640 working hours as
defined in the working time calendar to come up with the finish date.

Project's task durations should almost always measured and recorded in
working time hours instead of elapsed clock time hours. Think about it a
sec and you'll see why. The task only proceeds when someone is there
doing
it. If it will require 16 hours to complete it, will take more elapsed
time
to get it done when you only work on it in drips and drabs than if you
work
on it in one continuous block. The only thing that counts towards
completing it is the time you spend actively do it.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


AB said:
I have a task that I want to start on March 1st, 2007. I know it should
take
4 month... so I enter that too. Now, MS Project 2003 shows the end of
it
June 6th, 2007, while I was expecting it to be July the 1st. Why is it
doing
it? How many (working) days does Project assign to 'month'?

I had to put 17.4 weeks -- 52.14/12*4 = 17.4 (weeks-per-year /
months-per-year * 4 months) 365 days)/ (7 days/week)-- to get it
right,
but
I don't think this should be the right way to do it....

Thanks
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top