blank date

[Andy Bolger]

Really naive question i know - new user. Is it possible to enter a "blank
date" for when you want to note a project/task but don't know exactly when
it will start?

Or alternatively any suggestions on how to handle the types of issues.
many thanks
andy

 

[Rob Schneider]

Well, it is really *bad* form to enter any dates into Project (except
for the Project Start date.

Project will *compute* the dates for you based on your input of the
task's three dimensions: Duration, Work, Units. You "fix" one, input
the second, and Project computes the third. This is called the "project
triangle". You also define the logical sequence of the tasks
(predecessor/successor) and put resources on the tasks to spend the work
hours.

You'll find that start/finish dates are *never* blank or empty, and you
can't make them so, becuase Project will compute them for you. If you
enter data into these fields, Project will put in a constraint date of
some sort, e.g. "Must Start On". Constraints like this are usually not
what you want. You want, normally, "As Soon As Possible".

Probably best if you buy one of the many books available on Project and
have a good read. There are also internet-based resources you can find
via http://project.mvps.org/.

--rms

www.rmschneider.com

 

[HansH]

This is not possible in Project 2003 or 2007.
Depending on your needs, there are different possible approaches.

- You can create a summary task to group all tasks that are not yet
fully defined. Once the task details are known, you can move the task
into it's correct location in the schedule and enter the details.
- You can use task notes to reflect the fact that the dates entered are
'best guesses'. (or you can do this in the task name)
- You could use a custom field (like a flag that defaults to Yes) to
identify the tasks for which the dates are 'best guesses'

Of course, there are also other possible approaches, but it's a matter
of finding the solution that best fits your needs.

I hope this helps,
Hans

Projectopolis <http://msepm.hsquared.be>

 

[Mike Glen]

Hi Andy,

Welcome to this Microsoft Project newsgroup

You can use week numbers instead of dates: Tools/Options.../View tab and
select from the Date Format pick list. You cannot have a blank. I would
enter a reasonable start date for your project in Project/Project
Information. When it firms up, use the Adjust Dates macro from the Analysis
toolbar.

I thoroughly recommend you take at least a 2-day introductory course on
Project to get yourself up and running quickly. Meanwhile, you might like
to have a look at my free series for beginners 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 articles before leaving the site,
Thanks.)

FAQs, companion products and other useful Project information can be seen at
this web address: http://project.mvps.org/faqs.htm

Hope this helps - please let us know how you get on

Mike Glen
MS Project MVP

 

[HansH]

Entering finish dates is in most cases a very bad practice. There is
nothing wrong with entering start dates for some tasks. How else are you
going to define the start date for a task that has no dependency what so
ever with another task? How are you going to add external milestones
into your schedule?
Entering start dates creates a Start-No-Earlier-Than constraint, which
is a fairly flexible constraint and often is needed to build your schedule.
So 'entering dates is a bad practice' is very bad advice and needs some
nuances.

I'm going to ignore your remark about best guesses, as that would be a
discussion about choice of word, and is not relevant in this thread.

Regards,
Hans

Projectopolis <http://msepm.hsquared.be>

 

[Rob Schneider]

Hans,

While I agree in spirit to what you are saying, almost always the MPP
models I've built there is a logical pre-requisite for each and every
task. Most of the the time it's a real tasks in the plan, but absent
that I would make the pre-req the project start "milestone". So I
wouldn't call it "very bad advice" that "entering dates is a bad practice".

Like all rules, rules are there to be broken! One of those other
related rules that is there to be broken is the one about "the task MUST
start on or MUST finish on" rule.

--rms

www.rmschneider.com

 

[Steve House]

The start date of a task with no dependencies would be the start date of the
project unless the required resource is unavailable for the task on that
date. If you had the resources to do the task and there were no other
requirements such as a later delivery date of required parts or materials
(hence a Start No Earlier Than constraint really is required), would would
you delay the task past the earliest date it could be done, ie, the start of
the project as a whole? Why put off until tomorrow what you could get done
today? Rather than manually entering a start date, let the task sit on the
project start date, assign the required resources, and let resource leveling
delay it if it's necessary to prevent resource overallocations.
--
Steve House
MS Project Trainer & Consultant


Entering finish dates is in most cases a very bad practice. There is nothing
wrong with entering start dates for some tasks. How else are you going to
define the start date for a task that has no dependency what so ever with
another task? How are you going to add external milestones into your
schedule?
Entering start dates creates a Start-No-Earlier-Than constraint, which is a
fairly flexible constraint and often is needed to build your schedule.
So 'entering dates is a bad practice' is very bad advice and needs some
nuances.

I'm going to ignore your remark about best guesses, as that would be a
discussion about choice of word, and is not relevant in this thread.

Regards,
Hans


Projectopolis


salgud wrote:
On Fri, 04 Sep 2009 12:52:25 +0200, HansH wrote:


- You can use task notes to reflect the fact that the dates entered are
'best guesses'. (or you can do this in the task name)
- You could use a custom field (like a flag that defaults to Yes) to
identify the tasks for which the dates are 'best guesses'


As others have pointed out, entering dates is a major problem and is bad
practice. That being said, it should also be noted that any date or
duration you enter is a "best guess". What else could it be? If I say I'm
going to pour the concrete next Thurs, it's a best guess. If I say I'll be
alive next Thursday, it's a best guess. Any prediction you have ever or
will ever make is a best guess.

 

[HansH]

Rob and Steve,

I totally agree that typically each and every task has a logical
prerequisite or dependency (except the first task(s) in a project), but
this doesn't mean that those dependencies are managed in the project
plan. I was referring to these kind of pre-reqs or dependencies.
Some examples: delivery dates controlled by an external party,
availability of resources (like rooms, etc.) controlled by external
parties, deliverable dates of other projects potentially managed outside
your project server environment, etc.

Also resource availability could be a reason to use SNET constraints in
your project. Using resource leveling in a stand-alone project is very
useful. But in a project server environment, it typically is impossible
to use because different projects are managed by different managers and
leveling will never give a good result.

Besides this, I agree that entering dates should be done with caution. I
never enter finish dates, I avoid MSO and MFO constraints if possible,
and I manage external dates using milestones and dependencies rather
than entering the dates directly on the task.

But in many cases, a SNET cannot be avoided.

I hope this clarifies my point of view on this topic,
Hans


Steve House wrote

 

[José Miguel Piñeres]

Hello Andy,

Welcome to this Microsoft Project General Questions newsgroup, and thank you
for your honesty in pointing out that you are a new user of this fascinating
application.

With this said, I'll try to make my answer as simple as I can: Every project
must have start and finish dates, therefore, all its tasks must have them too.

When you create a new project in Microsoft Office Project, many things
happen in the background that are set as default, two of them are: the
scheduling method (default: Project start date), and the project's calendar
(default: Standard).

Since the Project start date is set as the default scheduling method, a
Project Start Date is also set, using the project's creation date.

Now, when you type a name in the first row of the column "Task Name", some
other things happen by default: A task duration is set as 1 day, that
duration is represented with a bar in the Gantt chart, and of course, start
and finish dates for the task are set based on its duration. But also a
constraint type (as soon as possible) is set by default. This means that,
without any task dependencies established, the task will start at project's
start date.

I surely hope this can be useful to you and I do recommend you to follow
Mike Glen's advise, but I would like to add a couple of links from Project
2007 On-line Help for you:

http://office.microsoft.com/en-us/project/HA102354821033.aspx

and

http://office.microsoft.com/en-us/project/HA102130271033.aspx

Please, let us know how you come along.

 

[salgud]

Entering finish dates is in most cases a very bad practice. There is
nothing wrong with entering start dates for some tasks. How else are you
going to define the start date for a task that has no dependency what so
ever with another task? How are you going to add external milestones
into your schedule?

Having a task with no dependency to any other task tends to make me
question the thoroughness of the schedule. In my experience in widely
varying kinds of projects, this is extremely rare. External milestones that
are part of another project and upon which tasks in the current project
depend would be one of those rare exceptions.

Entering start dates creates a Start-No-Earlier-Than constraint, which
is a fairly flexible constraint and often is needed to build your schedule.
So 'entering dates is a bad practice' is very bad advice and needs some
nuances.

My experience is that in most cases tasks with no predecessor are logical
errors more often than entirely external events. When I find a task "with
no dependencies on any other task", the first question I ask is, "Is this a
part of this project? Why is it here if it has no predecessors or
successors? More often than not, I realize it doesn't belong in this
schedule.

I'm going to ignore your remark about best guesses, as that would be a
discussion about choice of word, and is not relevant in this thread.

You didn't ignore it very well!
Nonetheless, I'd be curious as to which future dates you've planned that
were not "best guesses".