A project milestone is defined as the end of a project stage and marks the completion of that phase. Milestones can be used not just to highlight that key deliverables have been delivered, but also to indicate a key decision (or key investment) point within the project. Milestones can be used in any project, be they a construction project, an agile software project (milestone does not mean waterfall), or a project to build the next generation of space shuttle.
When defining a work package it is often the case that people tend to focus on what needs to be done, the requirements of the work package. It is then common for everyone involved to deep dive into the requirements and begin to specify a solution. I often find that at the beginning of a project a better approach is to use milestones to help us stay focussed. By this I mean that we should be thinking about how do we know that we are done. In my experience by first focussing on when we are done, we give ourselves and the team focus and context and save ourselves considerable time. I frequently use a simple Work Breakdown Structure to aid me in defining when we’re done.
Unless you are closing your project, when seeking approval for a milestone it is always good practice to include the definition of the next milestone, so that the key decision makers know exactly what they are signing up to, and the criteria upon which the next milestone will be judged.
When it comes to using milestones to monitor how the project is progressing, there is one big trap to watch out for, namely, that a milestone may not accurately reflect the state of the project. This is because often it is only critical items such as key deliverables that are monitored by the milestone. Thus it is possible in the extreme that none of the other tasks have been completed, or more likely that resources have been diverted from non-critical tasks to tasks monitored by the milestone so that to the steering group everything appears fine within the project, when in fact there is a lot which hasn’t been done. Whilst by definition a non-critical task is non-critical, the culmination of having many non-critical items incomplete may indeed be critical to the project’s success.
For this reason it is a good reason, particularly on larger projects or programs, to use project maturity gates (I’ll write about these soon) alongside project milestones.
