How to enter dates in MS Project

[redleafsoft]

Is there a way to enter dates in MS Project in a relative mode ? Let me be
more specific. I want to create a template project that starts at day 0
instead of on a specific date and then count the # days from that 0 date.
Advise will be appreciated

Marco Vucenovich

 

[MAT]

Hi.
You dont need to do that in this way. You can create your tempelate project
and the user can just change the start date (project -> projectinfo) if he
uses this tempelate.
MAT

 

[Y Lee]

Adding to MAT's comment, you can then add Lag (as in the # of days) from your
"0" date in the predecessor/successor functionality.

 

[Catfish Hunter]

If you want start on "0" and have day 1, 2, 3.............. go to format
timescale, chose middle tier only under time scale options and 1,2,3, from
start under label.
This should fix you up.

 

[davegb]

Adding to MAT's comment, you can then add Lag (as in the # of days) from your
"0" date in the predecessor/successor functionality.

In fact, if you are using Project properly, you shouldn't be entering
many dates at all. You should enter your list of tasks, their durations
and their dependencies. If you link properly (all tasks linked) you
only need to set the date for the start of the project. Of course, in
the Real World, occasionally, you need to set a date for a task. This
is called a "Constraint". They should be used sparingly. If you Google
this group for this term, you'll find my comments, and others, about
properly using them.
The above-mentioned "Lag" is a variation on a standard link.
Hope this helps in your world.

 

[Catfish Hunter]

Often when you build proposal schedules you don't want to show dates. You
only need the number of days to complete the project. Once you are awarded
the project and have a firm start date you convert to a date format. I think
this is what redleafsoft is looking for. (?)

 

[Trevor Rabey]

Regardless of how the timescale shows on the Gantt Chart (dates or days),
MSP is still calendar based and the project must always have a Start Date.

Even if you set the top, middle and bottom tiers to years 123..month
123..day 123 (or in reverse for countdown), there is still a calendar and a
start date behind it. You can hide the date columns, and everything else
about dates when you print, of course. But what's the point? You may just as
well present the project with any reasonable, assumed start date and reveal
all the Task starts/finishes and also show dates on the Gantt Chart
timescale.

Re real Date Constraints, hopefully there will be few of them, the absolute
minimum, used sparingly and reluctantly, as Dave says.
One thing I find helpful with this, is to keep all of the Date Constrained
Tasks at the top of the WBS in a section called "Reference Dates and
Events", so they are not scattered around in the body of the project, and
use them as Predecessors to the Tasks in the body of the project.

eg
10 Client promises site access, 0 days, MFO 8/03/2006 (could also be MSO, or
even FNET but be careful)
11
12:
:
:
100 Start Construction FS10

As long as the Date Constraints are there it's not perfect, but this just
helps to manage them a bit easier.

 

[Steve House [Project MVP]]

Just commenting sidebar .. I try to always keep clear on the difference
between having a date constraint on the project and having a task constraint
date within the project plan as handled by MS Project. A date constraint
would be "You must have the prototype of the new WonderWidget ready to demo
at the stockholder's meeting the 1st of August." It's a parameter the
project needs to be scheduled around, one of the goals of and in the
project, that needs to be met for the project to be successful. But it's
not a limitation on where the task might actually end up in the plan, only
an indication of where it has to end up if we are to consider the plan and
project a success. But we are building the plan in MS Project in order to
figure out just how we have to go about things in order to meet those
constraints and objectives and at the time we're inputting what we need to
do it still remains to be seen whether we'll make it or not. I think the
deadline field, NOT the constraint date field, is the best way to express
those parameters within the project plan.

A task constraint, OTOH, is a date entered into MSP by placing a constraint
of some sort on the task is a way of informing the scheduling engine about
physical factors that force the task to actually, physically occur on,
before, or after some date that is beyond our control and independent of any
factor within the plan itself. It is a limitation on the scheduling engine
to allow for parameters in addition to predecessor links and resource
availablility that the engine must take into account when placing the task.
The Christmas parade happens on a certain date regardless of what we our
plan may say about it. Parts won't arrive from a vendor prior to a certain
date and so there is nothing else we can do in our plan that can make the
task happen earlier than when the required parts get here, that sort of
thing. But our boss, or a contract with our client, saying something "must"
happen on such-and-such a date doesn't in itself MAKE it happen on that
date, it only says we really need to get it to happen on that date and gives
us very strong incentives for making sure it does <grin>. In fact, if the
parts don't get here before the 1st of May yet the boss or the contract says
the task must be done no later than the 15th of April, how're you going to
express both of those requiremnts solely through task constraints? You
can't.


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

 

[Trevor Rabey]

I make a distinction between:

1) what other people outside the project tell me about the things that they
will deliver, do or provide and the corresponding dates that they tell me
these things will happen on, before or after. These are usually all
predecessors to Tasks in my project, and have no predecessors in my project
(or perhaps do but it gets messy), and I keep them in the special place at
the top of the WBS. I trust none of them. Other people's promises would have
to constitute the lowest grade data available, deserving the least amount of
confidence and constituting one of the clearest sources of project risk.

and..

2) things that my project must achieve on, before or after some date due to
some requirement that comes from outside my project, usually the arbitrary
contract project finish date. These definitely have predecessors in my
project and I use the MSP deadline to capture the date for these and
constantly watch the difference between the planned finish (entirely
dependent on the predecessors and other conditions from within the project)
and the deadline.

Steve, I fear that, for all your experience, you have not seen common
practice in the construction industry, with MSP but especially with P3,
where people routinely nail down the finish milestone to a FNLT contract
date and then pile on predecessors to it which cannot finish on time. In
this example, the Task and the Milestone both end up with -5 Days Total
Slack. To do it with MSP you have to get past a few warnings, at least. I
hate negative Total Slack (and I hate negative lag, too) because it is so
difficult to interpret, if not impossible. When I see it I know someone is
"trying it on". It is only done to show the project finishing on time
because it is politically completely taboo to show the finish date after the
contract date. Of course, it finishes when it will anyway.

1 lay some bricks 10d Mon 13/03/06 Fri 24/03/06
2 finish the bricklaying 0d Fri 17/03/06 Fri 17/03/06 (FNLT) 1

Trevor

 

[Catfish Hunter]

To add to what I stated earlier. Clients very often request to see week 1,
week 2 week 3.... across the top of a proposal schedules. Perhaps someday
Trevor will be requested to show this on a schedule and will know how after
reading all these fine suggestions.

 

[Steve House [Project MVP]]

It's not that I'm not familar with those practices. But just because
something might be a common practice doesn't mean we should encourage it to
continue, especially if somehow asks a question about a problem that they're
facing that would become moot if they approached it another way. It is
related to the old issue of whether Project is best used to create a plan or
just to document a plan that has already been created.

I try to make a distinction between what a FNLT constraint is in the real
world of the project work and the entry MS Project CALLS a "FNLT Constraint"
in the software-created gestalt model of that world that is the project plan
we see glowing on out monitor screen. The constraint in the external world
is very definitely real - there's a contract that requires you to deliver X
by the 1st of June and if you don't, the company goes under from the
penaltys incurred. Can't get more real than that! But that's not what a
constraint AS ENTERED INTO THE PLAN IN SOFTWARE is. It is not a requirement
that we must figure out how to meet - it is a limit on what the software
predicts will happen to the plan from the information we've given it, a way
of forcing exceptions to the software's normal behavior. In a manner of
speaking, a constraint MODIFYS or DISABLES a feature of the calculation
engine, forcing it to behave in some non-standad way. The trick is to
insure that the modified behavior results in a model of the project that
behaves more like the real world project than it would without the
constraint.

Consider an Excel spreadsheet that is being used to figure out if you can
afford a new house. We have entered the amount to be borrowed, the interest
rate, and the term and our worksheet is calculating the payment. Interst is
5%, term is 25 years. We decide to do a "what-if" to see what the payment
will be at various amounts borrowed. We want to know the payment at $5000
increments upwards starting at 150 kilobucks and so we use the scenario
tools to build a table. But we have a constraint that the most we've
decided we can afford is $1000 per month and so we put a "must not exceed"
constraint of $1000 on the payment cell. We enter 150k, 155k, 170k in the
amount borrowed and everything works fine. But when we enter 180k for the
principal, Excel insists the payment is $1000 and refuses to calculate any
higher number. No matter what we put into the amount borrowed - 180k, 190k,
210k, 1 million, the payment shown is $1000. The calculated payment is only
an accurate prediction when borrowing amounts are less than about $178k. We
have disabled the calculation for amounts borrowed exceeding a certain
amount by setting a constraint that the payment must not exceed our budget.
As a result, the tool we designed to help us make the buy/no-buy decision is
lieing to us about the consequences of some of the options we're
considering.

Thanks goodness Excel doesn't really behave that way because such a
spreadsheet would be useless for figuring out if we could afford a new
house. But MSP can behave like that and it is the constraint entry that can
make it do it! I have Task A with a duration of 5 days linked to Task B
also 5 days linked to a milestone. We're starting 03 Apr and the contract
requires we finish by 15 Apr. If we have a FNLT constraint of 15 Apr the
milestone shows occuring on 14 Apr; a MFO constraint puts it on 15 Apr. So
far no problem. But now we realize that Task A isn't 5 days but will
require 10. Without the constraint our finish milestone shows on the 21st,
an accurate prediction of the date we'll be able to actually hit IF we have
to live with those durations and start date. But if we put on either of
those constraints, the milestone still shows to be happening on 15 Apr, an
out-and-out lie. Granted, MSP gives us a warning by default but those
warnings can be, and usually are, disabled by the user with just one mouse
click and most users turn off the warning when they're tired of getting
nagged. The result, a project plan that promises to finish on time when
there's no way on God's Green Earth that we're actually going to make it.

I submit to you, if the reason for using scheduling software in the first
place is to figure out what we must do in order to meet our project's
requirements we must leave it free to show us if we're going to hit them or
are going to miss them. Something like an MFO or FNLT co nstraint programs
Project to always place the task in obedience to the constraint - it says,
no matter what we do, no matter what decisions we make, this task will
always fall where we want it to. I suggest that such a lieing plan is as
useless for managing the project as is the above spreadsheet is for managing
our housing search. It merely looks good on paper. It documents what we
want to happen but gives us no help in figuring out how to make it happen.
But simply declaring something will happen in a certain way by using a
constraint to show it that way in the plan is not sufficient in and of
itself to make it so.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[SunBird II]

Question on calcuation of number of days between any start and finish dates
of a project. In trying to assure myself of accuracy of project duration
dates, I used some of the example templates within M.S. Projects and noted
the duration of 85.75 days for a project start 1/3/00 - project finish
5/1/00. If you calcuated the number of days between the start and finish days
it equals 117 days. I would have to think that the difference between the MS
Project calculated duration of 85.75 is the number of work days and my
calendar calculated 117 days between these start and finish dates, is actual
total including weekends. Is this a correct deduction?
Thanks...SunBird II

 

[Mike Glen]

Hi Sunbird II,

Welcome to this Microsoft Project newsgroup

Project Help defines Duration like this: The total span of active working
time that is required to complete a task. This is generally the amount of
working time from the start to finish of a task, as defined by the project
and resource calendar.

You might like to have a look at my series on Microsoft Project in the
TechTrax ezine, at this site: http://tinyurl.com/2xbhc or this:
http://pubs.logicalexpressions.com/Pub0009/LPMFrame.asp?CMD=ArticleSearch&AUTH=23
(Perhaps you'd care to rate the article before leaving the site,
Thanks.)

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

 

[Steve House [Project MVP]]

A sidenote to Mike's answer - in your example, Project calculated duration
while you calculated elapsed time. The two are very, very different
measurments and mean totally different things. Try this one on for size
<g> - a 5 day duration task starting the 1st of June that has been assigned
to a part-time worker who comes in 1 day a week will finish about the 1st of
July.

 

[SunBird II]

Hi Mike;
Guess my question was not clear. I am aware of the info on difine Duration.
What I am addressing is the following:
1-Given that there are no constraints in the project schedule, when all the
project schedule is developed and Projects calculates the total finish date
based on the start
and finish of tasks. If you look my example:
templates within M.S. Projects and noted
the duration of 85.75 days for a project start 1/3/00 - project finish
5/1/00. If you calcuated the number of days between the start and finish days
it equals 117 days.

I calculated the number of actual calendar days between the dates of 1/3/00
and 5/1/00 and you would get 117 days.
The calcualation that resulted using one of the templates that is in Project
2000 standard version, the time results in 85.75.

I am just trying to see where this difference results from, because when I
looked at the summary totals in the template they do not add up to either of
these to sums.

Also really apreciate your articles in "Mike Tutorials" good stuff.
Thanks
SunBird II

 

[Mike Glen]

Hi SunbirdII,

You might be aware of the definition of Duration, but you are not applying
it! The 85.75 days is the number of WORKING days as opposed to the 117 as
the elapsed days. Duration is always the working time between start and
finish.

Mike Glen
Project MVP

 

[Steve House [Project MVP]]

"Duration" only includes working time and any hours of non-working time are
excluded. That's why Mon 8am to Fri 5pm is 40 hours of duration, not 105
hours. Deduct 2 non-working days per week from your 117 elapsed days and
you'll be close to the numbers Project gives for the duration between those
dates. The discrepency can be accounted for by holidays that lie in that
date range or rounding due to time of day tasks start and end.

 

[SunBird II]

Mike...Thanks this is what I was driving for and both you and Steve have
answered my question ... Much appreciated.
SunBird II

 

[Mike Glen]

You're welcome,

Mike Glen
MS Project MVP

Mike...Thanks this is what I was driving for and both you and Steve
have answered my question ... Much appreciated.
SunBird II