A milestone is a significant event in the life of the project. But there ' s more to a milestone than simply stating, "This is a significant event." The real purpose of a milestone is to recognize the passing of a measurable event by which you can judge that the project is proceeding on time and within the prescribed budget. So you must decide on milestones that are able to give you both a quantitative read (time and budget) and a qualitative read (how well the project is going). Milestones are typically represented as activities with zero duration.
Presumably, you ' re tracking expenses and time within your project budget as you go along. When Joe finishes a task, he keys in his time spent on the task. Additionally, the invoiced cost for any software or hardware that you utilized in a given task is compared with what was budgeted. You' re summing the budget items as well as the person-hours, and you now have a total that gives you an idea of how well you' re doing.
Now, should the milestone involve any more than just the summation of a project' s total person-hours and money spent to date in comparison to projections? An emphatic yes! The milestone also represents a significant turn in the project. All databases have been built and are operational, for example. All of the screens have been developed. All servers throughout the corporate enterprise are replicating perfectly with one another. A milestone is a representation of a significant event or turning point in the project (the qualitative measure) as well as a set of gauges that gives you an instant read on how well you ' re doing from a time and budget perspective.
Generally, milestones are set at the completion of a phase, not of a task or activity, though there are exceptions to this. There are two kinds of milestones: major and minor. You' l l set major milestones to denote a significant advance in the project ' s activities. Minor milestones mark something relevant to a specific part of the project. Dor example, you might be developing a large client/server front-end application that has several modules to it: printing, calculating, presentation, reporting, and so forth. You might set a minor milestone at the point when the printing module has just been finished and is ready to snap into the main body of code. A minor milestone might trigger off of a task or activity, but generally all milestones fire when a phase has elapsed. Note that there are no hard and fast rules when it comes to setting milestones. The idea is that you're supposed to analyze the project's tasks, activities, and phases, then make decisions about when you think you've reached a new apex in the project.
Tip Larger projects require more milestones than smaller ones.
Notice anything missing in this formula? Well, we're not tracking how well our team players are getting along with one another, are we? While you would not set a milestone that stops to evaluate the psychological well-being of your team, you should certainly be keeping an eye on this element of the project as well. Indeed, the attitude of the team tells a lot about the nature of the project itself.
Was this article helpful?