About Milestones
Until recently, I thought that the concept of a milestone is basically self-explaining, but it seems that I was wrong. On two different occasions, I was told that even trained project managers sometimes cannot tell the difference between an activity and a milestone.
In my opinion, milestones represent one of the most important concepts of project planning, monitoring, controlling and reporting. A milestone provides you (as the project leader) with the ability to define a specific point in time where your project reaches a defined status. Without milestones it is very hard to tell how "far" you actually are with executing a given project plan.
In many project planning tools, the difference between a milestone and an activity is simply that the milestone has zero length, i.e., it starts and finishes at the same point in time. However, semantically, there is a lot more to it why an activity and a milestone are two completely different things:
- An activity defines a unit of work, i.e., what has to be done, by whom, with a defined start and finish date. For instance, "create a project plan" could be an activity. An activity can be between 0% and 100% complete, since progress can be measured within the activity
- A milestone defines a specific status which should have been reached within the scope of the project, typically indicating that some work or phase has been completed, e.g., "project plan created" could be a milestone. A milestone cannot be 50% complete; it is either open (0%) or it is closed, i.e., completed (100%) - there is nothing in between
Milestones are typically shown in schedules in the form of a diamond where an empty diamond indicates an open milestone, while a filled diamond denotes a closed/completed milestone.
This semantic difference should also be reflected in the naming of activities and milestones: I personally use the present tense to name activities while I use the past tense to name milestones. Typical examples for milestone names could be "design finished", "implementation completed", or "handbook reviewed".
The most common practical application of a milestone is as a delimiter of a phase within a project plan. A project phase is a top level activity or collection activity (often also referred to as a "work package"). Such milestones can then be used for monitoring and controlling the overall project progress using milestone tables, or more advanced tools such as a milestone trend analysis (we will cover this topic in a future post in more detail).
Finally, the most important milestone of a project is probably the completion of the given project. Therefore, it is good practice to include an explicit "project completed" milestone. This milestone can be used to formally conclude the project and might remind you to think again if your project is really complete, or whether you have forgotten about something... have you? ;-)
Comments on this article
Melanie Mersmann wrote on March 10, 2007 at 14:02 GMT
Good arguments, but you can also validly argue, that if a milestone is "design finished" that would be equivalent, to the activity "design application" is 100% completed. And even, if you have multiple activities like "design businesslogic" and "design userinterface" you can still model it apropriately via making both dependent for a task "merge design". There should be more about milestones and from my opinion, there is. Normally you make projects for a client (either an explicit one but also inside a company). And it is obvious, that the client has to execute some tasks here as well. But normally they would not let them be included in the project-plan. Thus as a rule of thumb it is quite smart to have a milestone for every obligation to cooperate of the client beeing due. Also because normally that would also block proceeding with the dependent tasks.
Gerald Mesaric wrote on March 10, 2007 at 14:26 GMT
Very good comment, thanks. I especially agree about let's call them "external" milestones, or "obligations" as you named them.
Christian Philipps wrote on March 11, 2007 at 16:30 CET
I could not agree more with Melanie on the use of milestones for prerequisites. Normally you would also use some additional document such as a prerequisites-log linked to these milestones. Business partners sometimes like to ignore the impact of them failing to fulfill their own obligations in time ... using milestones for visualising this impact in the project plan makes it easier to bring the message across. Another aspect of milestones worth writing about could be best practices for using milestones for project plan segmentation and visualisation. Milestones can help for example to summarize key dates in a section of their own right at the top of the project plan (if one likes this style).
wrote on April 3, 2007 at 17:12 GMT
Gerald Mesaric wrote on April 6, 2007 at 18:44 GMT
I am about to write a follow-up article about milestones; I will try to cover some of these aspects (we are still in "newbie" mode here, so I do not want to go into too advanced topics in detail yet).