Milestone Dependencies without dates

[etc]

Using MS Project 2007 Standard, I would like to setup a chain of dependencies
with milestones that aren't date oriented. For example Milestone X is
dependent upon Milestone X-1. Milestone X would come a certain amount of time
(i.e. 16 weeks) after Milestone X-1. Is there a way to do this?

 

[John]

Using MS Project 2007 Standard, I would like to setup a chain of dependencies
with milestones that aren't date oriented. For example Milestone X is
dependent upon Milestone X-1. Milestone X would come a certain amount of time
(i.e. 16 weeks) after Milestone X-1. Is there a way to do this?

etc.
Milestones in Project should be used for two things. They can be used to
mark the start of a group of tasks and they can be used to mark the
completion of a group of tasks. Milestones should NOT be linked to other
milestones - it serves no purpose. The most prevalent use of a milestone
is to mark the completion of a significant group of tasks within an
overall project plan (i.e. preliminary design review, completion of the
slab for a house, etc.). The milestone "floats" based on how the driving
tasks are performing. Although a milestone may be roughly related to a
previous milestone, it is dependent on the tasks that lead up to it and
not the previous milestone itself.

Perhaps what you really want is a series of deadlines. For that you
should use the Deadline field. Basically you set the date and Project
puts a deadline marker on the Gantt Chart display. You can read more
about the Deadline field in the Project help file.

By the way, the answer to your question is yes, but it is a misuse of
the milestone concept. If you really really want to chain milestones,
just put a lag in the link between them.

John
Project MVP

 

[salgud]

etc.
Milestones in Project should be used for two things. They can be used to
mark the start of a group of tasks and they can be used to mark the
completion of a group of tasks. Milestones should NOT be linked to other
milestones - it serves no purpose. The most prevalent use of a milestone
is to mark the completion of a significant group of tasks within an
overall project plan (i.e. preliminary design review, completion of the
slab for a house, etc.). The milestone "floats" based on how the driving
tasks are performing. Although a milestone may be roughly related to a
previous milestone, it is dependent on the tasks that lead up to it and
not the previous milestone itself.

Perhaps what you really want is a series of deadlines. For that you
should use the Deadline field. Basically you set the date and Project
puts a deadline marker on the Gantt Chart display. You can read more
about the Deadline field in the Project help file.

By the way, the answer to your question is yes, but it is a misuse of
the milestone concept. If you really really want to chain milestones,
just put a lag in the link between them.

John
Project MVP

I'm going to have to respectfully disagree with John. The two uses he
suggests for milestones are some of the major uses, but there are others.
Examples would be any Go-No Go decision on the project, the release of a
major report or other document (like scoping document), major project
reviews or control points. An example of the last is one I learned in a PM
class and used for many years on medium to large mining and oil
construction projects. I was taught that civil work should begin by the
time design work was 10% complete, which was not an easy thing to make
happen. But it helped to insure a good start on these kinds of projects. So
I always inserted a milestone, for me and my team, showing the point at
which the Design Phase was 10% complete. Then I'd try to make sure that all
of the tasks that needed to happen in order for the civil work to start
finished by that same time. Of course, I couldn't just link from the 10% Ms
because that would have been artificially forcing the start of Civil work,
possibly before the necessary predecessors were complete.
I believe in using milestones wherever you feel you need a marker in your
schedule. Of course, I don't advocate peppering your project with them and
diluting their value.
Hope this helps in your world.

 

[salgud]

I'm going to have to respectfully disagree with John. The two uses he
suggests for milestones are some of the major uses, but there are others.
Examples would be any Go-No Go decision on the project, the release of a
major report or other document (like scoping document), major project
reviews or control points. An example of the last is one I learned in a PM
class and used for many years on medium to large mining and oil
construction projects. I was taught that civil work should begin by the
time design work was 10% complete, which was not an easy thing to make
happen. But it helped to insure a good start on these kinds of projects. So
I always inserted a milestone, for me and my team, showing the point at
which the Design Phase was 10% complete. Then I'd try to make sure that all
of the tasks that needed to happen in order for the civil work to start
finished by that same time. Of course, I couldn't just link from the 10% Ms
because that would have been artificially forcing the start of Civil work,
possibly before the necessary predecessors were complete.
I believe in using milestones wherever you feel you need a marker in your
schedule. Of course, I don't advocate peppering your project with them and
diluting their value.
Hope this helps in your world.

I should also have mentioned that one could create a link between your two
milestones and use lag time to set the time between them. I agree with John
that this is bad practice. Instead, the tasks between the two should be
properly linked, leading up to the second milestone. If it is occurring by
the desired time, great! (How often does that happen?) If not, you need to
attack the path between them as though you were attacking the CP, using the
same methods, until you have brought the second milestone into the desired
date, or realize that is just isn't going to happen that way. If you're not
willing or able to recognize that it can't be done in the desired time, you
need for change jobs or possibly careers.
Hope this helps in your world.

 

[John]

I'm going to have to respectfully disagree with John. The two uses he
suggests for milestones are some of the major uses, but there are others.
Examples would be any Go-No Go decision on the project, the release of a
major report or other document (like scoping document), major project
reviews or control points. An example of the last is one I learned in a PM
class and used for many years on medium to large mining and oil
construction projects. I was taught that civil work should begin by the
time design work was 10% complete, which was not an easy thing to make
happen. But it helped to insure a good start on these kinds of projects. So
I always inserted a milestone, for me and my team, showing the point at
which the Design Phase was 10% complete. Then I'd try to make sure that all
of the tasks that needed to happen in order for the civil work to start
finished by that same time. Of course, I couldn't just link from the 10% Ms
because that would have been artificially forcing the start of Civil work,
possibly before the necessary predecessors were complete.
I believe in using milestones wherever you feel you need a marker in your
schedule. Of course, I don't advocate peppering your project with them and
diluting their value.
Hope this helps in your world.

salgud,
I don't quite see the disconnect. Your example of a Go-No Go decision
point is analogous to my example of a milestone for a preliminary design
review. If the review shows that the design meets the intent of all
requirements then the next design phase proceeds. If it doesn't, then
more preliminary work is needed.

I think we're on the same wavelength.

John
Project MVP

 

[Steve House]

Ithink you both are on the same idea but our original poster was making a
fundmental error when he says he wanted to set a certain milestone to be on
date a certain timeperiod after another milestone. That implies that the
milestone is a date which it most emphatically is not. Milestones are
events, not dates. To say that "15 September is an important milestone date
in our project" is complete nonsense and yet it is something you hear over
and over again. You might have an milestone event of "Go decision made" and
it will certainly occur on such and such a date but the milestone is the
decision, not the date on which it should be made. The date is the deadline
by which the milestone needs to occur but it actually occurs whenever it
occurs, determined by the processes leading up to the decision. IF it
occurs before the deadline, great! If it occurs after the deadline, update
your resume. But no matter how important the date is to the project, the
milestone occurs whenever it occurs.

 

[salgud]

I was speaking to your opening statement:Some of the uses I suggested are not particularly marking the start or
finish of a "group of tasks". The Go-No Go decision may not be associated
directly with a particular "groups of tasks", and the example I gave of a
Control Point milestone certainly isn't.
If I've misinterpreted your intent, my mistake. I was just trying to show
the OP that milestones can be used in a variety of ways, not all of which
are associated with particular tasks.

 

[salgud]

Ithink you both are on the same idea but our original poster was making a
fundmental error when he says he wanted to set a certain milestone to be on
date a certain timeperiod after another milestone. That implies that the
milestone is a date which it most emphatically is not. Milestones are
events, not dates. To say that "15 September is an important milestone date
in our project" is complete nonsense and yet it is something you hear over
and over again. You might have an milestone event of "Go decision made" and
it will certainly occur on such and such a date but the milestone is the
decision, not the date on which it should be made. The date is the deadline
by which the milestone needs to occur but it actually occurs whenever it
occurs, determined by the processes leading up to the decision. IF it
occurs before the deadline, great! If it occurs after the deadline, update
your resume. But no matter how important the date is to the project, the
milestone occurs whenever it occurs.

Now I'm going to have to respectfully disagree with you, Steve. Saying "15
September is an important milestone date in our project" might be nonsense
or might not, depending on the context. If I'm planning a convention, and
that convention convenes on Sept 15, it's a milestone. If I say Sept 15
because I fancy having certain things finished or started on that date,
it's nonsense.

 

[Steve House]

Nope, the date is not the milestone, "Convention Begins" is the milestone.
It happens on a date, it has a very important deadline and in this case the
entire exercise is pointless if the deadline is not met, but the thing
happening is the milestone, not the date on which it happens. A milestones
is what a chemist or physicist would call a "state transition," a molecule
of liquid water changing into a molecule of steam, for instance. In
business terms it might mark the change from the state of "contract not
signed" to the state of "contract signed."