Milestones

[WeRhino]

Can a Milestone %Complete update from a Predecessor?
Using Project 2003 and I want a milestone to auto update from a Start-Finish
predecessor. If the task is 20% complete the Milestone should indicate 20%
complete also. Any suggestions…?

 

[Steve House [Project MVP]]

Strictly speaking a milestone occupies a single instant in time and has zero
duration. It marks the passage of a boundary line in the Project just like
a milepost marker does out on the highway. Since % Complete is the
percentage of a task's total duration that has been worked and milestones
don't have a duration, they don't have a % Complete either. (Division by
zero is mathematically undefined.) The milestone has either occured or it
hasn't, there are no other intermediate values possible for it to take. If
a performance task links to a milestone at its end, the milestone is zero
while the task is in progress and becomes complete (or is passed) when the
predecessor ends but not before.

 

[Jan De Messemaeker]

Hi,

Steve explains why the answer is no, strictly speaking.
Through a VBA procedure you could copy the predecessor's %complete to a
custom field.
Can't do any better, sorry :-(

 

[connies]

However, you can mark a summary task as a milestone. Then you can see
the % complete aggregated over all the tasks under the summary. If
your summaries correspond to deliverables, this can be useful.

I have the same issue in my projects -- customers want to know how far
you are toward completing deliverables, task groups, or phases.

--Connie

 

[connies]

Should have clarified that you can see the % complete IN THE MILESTONES
REPORT. Which is a quick and easy way of summarizing how far you are
toward milestones that correspond to completion of deliverables, phases
or task groups.

--Connie

 

[WeRhino]

Just wanted to say thanks that really helped!

 

[Steve House [Project MVP]]

You can mark a summary as a milestone, true enough, just like you can choose
to call an apple a chicken. But neither is correct usage. A summary task
might mark the progress towards a milestone but the milestone proper is the
instantaneous change of state that occurs when the summary is completed. If
we're writing a program, it doesn't exist (yet) while we're writing. We
can't use it. After we've finished, the program exists and we can use it.
The milestone is not the process of the writing; the milestone is the
instantaneous change of state from "not done" to "done" that occurs at the
end of the process, conceptually the same thing as the phase boundary
between solid and liquid that you find in a melting ice cube.

 

[connies]

Sure, no argument. There remains however the practical and legitimate
question of *how much progress have we made toward achieving* our
milestones and reporting on the answer to that question. Such as, how
far are we toward delivering that program? How many joules have we
put into the ice block toward making it cross the phase boundary? How
far have I come on my climb to the mountaintop?

Preserving semantic purity isn't a terribly good reason for diving into
VBA when using trivially simple existing UI functionality will work.
Maybe that's why that evil checkbox was put there in the first place.
And especially since summaries ideally already correspond to
deliverables, you have a really easy means of reporting on progress
toward deliverables milestones. Maybe they should relabel the checkbox
"mark as a deliverable."

Anyway, I do appreciate the discussion, and I'm eager to hear
suggestions about simple ways to report on progress toward milestones.


Thanks,

Connie

 

[Steve House [Project MVP]]

Seems like we're pretty close to each others thinking. And your points
about the importance of project reporting are spot on. I just find a lot of
people get into problems when they confuse milestones with tasks - it tends
to lead to a WBS that is more a list of objectives than a roadmap of what is
required to achieve those objectives and that sort of plan is un-schedulable
and un-measurable. Hence my propensity for semantic rigor.

I don't know for sure but I think that "mark as deliverable" checkbox is
there either as a hold-over legacy from the days when MSP was a far less
sophisticated product or as a sop to "seat of the pants" PMs who demanded
it.

 

[Matt Piazza]

Steve, thanks for standing up for the value of true project management. Our
work is much harder than necessary due to poor command of our industry's
terminology by many people who think they know project management. I agree
with Connie's points about the 'real' world. We all benefit when we stay
true to our terminology guns and help others understand what they are really
wanting when they ask for a percent complete of a milestone. They are really
asking for a percent complete of a deliverable (best represented by a summary
task).

I enjoyed yours and Connie's dialog. Glad to see champions having open and
productive discussions.

BTW, regarding the reason the "milestone" checkbox exists, see another
discussion thread on "alternatives to MS Project". I like the person's
recall on how MS Project was developed and how scheduling experts were
ignored. Did you know that Microsoft took ten years to correct the name of
the "precedence diagram" from a "PERT" diagram? The checkbox probably exists
because people with little scheduling experience built the early versions of
MS Project. I still use MS Project as the best tool on the market, but they
really missed some basic features of our business. These missing features
add hours of work to my routine world to compensate for the missing
information that is readily available in the database.

Matt Piazza, MBA, PMP
Flower Mound, Texas