Start Date or Finish Date?

[Top Spin]

I am just learning Project. The Tutorial makes a big point of whether
I set up a new project with a Start Date or a Finish Date. I got the
impression that start date is the way to go for most projects, but I
couldn't find where it explained why. It did talk about losing various
settings if you change from one to the other such as "leveling delays"
and "leveling splits". I don't know what those are and if I even need
them.

I have a software project that I am doing more or less in my spare
time, but I have a couple of contract programmers and some other
external dependencies. I'd like a way to keep track of all of the
little tasks and interdependencies.

I don't really have a "deadline", per se. I would like to enter the
various tasks and time estimates for each and then let the
interdependencies tell me when it will be done. Is that a reasonable
way to go?

That seems to me to suggest that I not use a Finish Date. Is that
right? I just don't want to enter a lot of data and run into
conversion problems later.

Thanks

 

[Robert]

Creating project using a:
1. Start date is when you say "Right... I start project
today.... When will I be fisnished????"
2. Finish date is when you say "I have to be finished that
date... When do I start??? Or how many do I have to have
to be finished on time???"

As far as do you "need" leveling delays/splits... Trust me
when I say that you'll bump into them!!!!

 

[Steve House]

You're exactly on the right track. Scheduling from the start date gives you
the most flexibility. Project considers the *best* schedule to be the
shortest schedule and directs its calculations to that end. If you schedule
backwards from the finish date required, Project places all tasks so as to
start on the latest possible date to finish the project on the desired date.
But that implies that if any task starts late - resource is ill the day it's
supposed to start, for example - or takes longer than you had originally
expected, everything after taht is delayed and the project itself finishes
later than you need it to. Scheduling forward from start will give you a
project that finishes as soon as possible. Hopefully you can arrange the
tasks so that you can finish up some time before you absolutely positively
are required to, giving yourself a cushion to absorb any contingencies and
reduce the risk of running late. Or conversely, if you have some tasks with
multiple resources on them that are effort driven, you could release some
resources from the project, the tasks they were on now taking longer to
complete, eating up some of that cushion at the end but in the process
reducing the project's costs by saving on labour cost.

 

[Top Spin]

You're exactly on the right track. Scheduling from the start date gives you
the most flexibility. Project considers the *best* schedule to be the
shortest schedule and directs its calculations to that end. If you schedule
backwards from the finish date required, Project places all tasks so as to
start on the latest possible date to finish the project on the desired date.
But that implies that if any task starts late - resource is ill the day it's
supposed to start, for example - or takes longer than you had originally
expected, everything after taht is delayed and the project itself finishes
later than you need it to. Scheduling forward from start will give you a
project that finishes as soon as possible. Hopefully you can arrange the
tasks so that you can finish up some time before you absolutely positively
are required to, giving yourself a cushion to absorb any contingencies and
reduce the risk of running late. Or conversely, if you have some tasks with
multiple resources on them that are effort driven, you could release some
resources from the project, the tasks they were on now taking longer to
complete, eating up some of that cushion at the end but in the process
reducing the project's costs by saving on labour cost.

OK, that makes sense.

Do you think that Project is overkill for a small project? I can
pretty much keep most of the tasks in my head with a little help from
a manual list in Word. I do spend a bit of time rearranging my manual
Word list. I was hoping Project would do the rearranging for me (and
the overall time calculations) once I got the interdependencies set
up. I just hope the learning curve isn't more than it's worth.

Thanks

 

[Trevor Rabey]

How small is small? Using MSP properly and comprehensively will teach you
about the critical path method and other basic project management
discipline.
This will make you start to think like a real project manager. It will come
in handy all the time in the future in ways that you cannot begin to imagine
from where you are now.
Yes, you have to take some pain, but then the light goes on and it is worth
it, or at least that has been my experience.
Imagine what you would have missed out on if you had deciding that learning
to read was too difficult to be bothered with, or had to be obviously
immediately relevant at the time.
BTW, invest in something more recent than MSP 98.

 

[Sarah]

You should only set a Finish Date if you have an absolute deadline
that CANNOT move. Otherwise, you should use a Start Date. When you set
a Finish Date for a project, the software will schedule from that date
back. It can be a real headache, which is why most people avoid it.
Since you don't have a deadline, you should use a Start Date, which
you can set by clicking Project>Project Information.

As for Leveling Delays and Splits, these refer to leveling a resource.
If you want a realistic plan, you would enter the tasks, link them
appropriately, assign resources and work efforts, then you would level
the resources. This tells the software to adjust the timing of tasks
so that resources do not exceed their maximum availability. For
instance, if Resource A is scheduled initially for two tasks of 8
hours each that start on 10/3, when you level, Project will adjust the
Start Date of one of these tasks to 10/4. There are different options
for the order that leveling occurs.

Sarah

 

[Top Spin]

How small is small? Using MSP properly and comprehensively will teach you
about the critical path method and other basic project management
discipline.
This will make you start to think like a real project manager. It will come
in handy all the time in the future in ways that you cannot begin to imagine
from where you are now.
OK

Yes, you have to take some pain, but then the light goes on and it is worth
it, or at least that has been my experience.
Imagine what you would have missed out on if you had deciding that learning
to read was too difficult to be bothered with, or had to be obviously
immediately relevant at the time.

Hmmm... I doubt that Project really compares with reading... ;-)

BTW, invest in something more recent than MSP 98.

I was going to give it a go with 98 since I happened to have a copy.
If I found it useful, I'd upgrade to the latest version.

Is there that much difference? What are the major improvements over
98?

Thanks

 

[Top Spin]

You should only set a Finish Date if you have an absolute deadline
that CANNOT move. Otherwise, you should use a Start Date. When you set
a Finish Date for a project, the software will schedule from that date
back. It can be a real headache, which is why most people avoid it.
Since you don't have a deadline, you should use a Start Date, which
you can set by clicking Project>Project Information.

As for Leveling Delays and Splits, these refer to leveling a resource.
If you want a realistic plan, you would enter the tasks, link them
appropriately, assign resources and work efforts, then you would level
the resources. This tells the software to adjust the timing of tasks
so that resources do not exceed their maximum availability. For
instance, if Resource A is scheduled initially for two tasks of 8
hours each that start on 10/3, when you level, Project will adjust the
Start Date of one of these tasks to 10/4. There are different options
for the order that leveling occurs.

Sarah

OK, thanks

 

[Steve House]

It's a matter of approach, but I don't like to use a schedule backward from
finish strategy even when there is a fixed in stone deadline. I see one of
the principle uses of MSP as a tool to answer the question "We know we have
to finish by XXX, now what do we have to DO to make it so?" A few years ago
I was helping an organization with their Y2K mitigation plan project. They
decided to be safe and said everything had to be done by Nov 99 so they
plugged that end as the finish and scheduled backwards. MSP informed them
that the project should start no later then July 97. Unfortunately it was
already November of 98 when they started to create the plan and none of the
work that should have come before had been done. A better approach is to
figure out when they can start. Now MSP calculates a ridiculous end date
that is a year too late. BUT we have something to work with - we can adjust
the scope of this set of tests, do these tasks in parallel, hire so temps to
come in and work on these tasks along with the regular staff, etc etc. Each
thing we try changes the calculated finish. We keep us this "what if"
modeling until we come up with a plan that gets the important stuff done by
an acceptable date. By not trying to lock things down with constraints made
up of thin air and using a scheduling method that gives us the most
flexibility, we have a fighting chance of coming up with a workable schedule
that will actually accomplish out objectives.