RIGHT Blogs                                                              

Monitoring Your Program Health (Milestones)

Milestones are not project tasks, and that is probably the hardest thing to convince your project managers of, unless they've gone through some formal project management training.  Because the default behavior of PMs is to pull tasks from their project plan and stick it into your milestone tracking sheet, and that really isn't going to help you manage your program.

I've enclosed a sample milestone tracking sheet that I've used in the past and I've listed how to get the most out of it based on past experience.

* First, as I said above, remember milestones are not tasks.  Milestones mark concrete deliverables that can be touched or seen.  (eg. a requirements document, a prototype, a signature on a form indicating signoff)  I've seen PMs add milestones like "completed coding for portfolio service", and argue that since it is a piece of code, it can be seen.  But the problem with that is that it's pretty hard to see that code in isolation.  Usually it's a component of a much larger system, and until more components are completed, there is no real way to make sure the portfolio service is complete.  So milestones have to be capable of being independently verified.
* Milestones are either complete or they are not.  A lot of PMs like to put down that they are x% complete, and project management tools like Microsoft Project actively encourage this by making it so easy to see the % complete.  The problem with that number is it is based on your best guess at how much effort it takes to complete a milestone.  And typically that guess was formed before you even looked at it in detail.   So while you may have thought it would take 8 days to finish a design document, you may have gotten 6 days into it and realized there is a particularly thorny design problem that will take a few more days to resolve.   So your milestone plan should really show when the task was completed.  If you really want to put more information there before completion, then you can put the milestone is in progress so that management knows you are working on it at least, but never put % complete because you'll be setting expectations that you can't live up to most of the time.
* Set your milestones in a staggered fashion so that there is something being delivered every week.  This is important so that you can show progress on the projects.  You also want your milestones small enough so that no single one takes more than 2 weeks to complete.  Any longer, and you risk finding out about problems when it is almost too late to fix them.
* You'll note that the sample I provided has a Revised date and a revision count column.   You'll find those columns useful because with any program of sufficient complexity, you'll find dates slipping a number of times, often for reasons that are out of your control.  These columns allow you to see how much the date has slipped from the original date, and how often it has slipped.  As the revision count goes up, it is a good indicator that you need to have a chat with the PM to talk about how he/she is managing their risks and how they might be impacting the project/program.
* And finally, you've got a comments column so the PM can explain why the milestone is late and what the potential impact might be on the project.