Handoffs: The Reasons Behind Interim Milestones in Schedules


In the last couple of years, I’ve worked with some project managers who thought the reason they made schedules was to know when the milestones would be met. They thought if they knew when “design complete” or “feature freeze” or “code complete” occurred, they could track the schedule.

I’ve never been comfortable with that, and now I think I know why. The PM can track the milestones from release to release and understand — in general — how the project’s process is working. And if you want to know if your general project management process is helpful, track interim milestone estimates and actuals. But to track a specific project, I prefer to track handoffs between groups.

When I manage projects, and especially when I manage programs, I develop a schedule of handoffs. Knowing when this particular design is ready for those particular development groups to implement or use, especially if there’s an API that other development groups need helps me track the dependencies more effectively.

In reality, most interim milestones are irrelevant. (If you have an external event or deliverable, that interim milestone is certainly relevant.) The release date is relevant, but if you meet or beat or slip an interim milestone by a few days, does it matter? Most of the time, no.

What is relevant is if the handoffs arrive to each person or team working on the project. And if you track handoffs, you’re more likely to know earlier if the interim milestone will be met.

Tracking milestones is late information for the project manager. Tracking handoffs provides earlier information.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.