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