One key element of a project schedule is the creation of milestones. A literal milestone is a stone marker, set (at regular intervals) along the side of a road, to assure travelers that they are still on the right path and to show them how far they have progressed along that path (e.g. the distance to Rome). Project milestones are very similar: accomplishments that measure our progress towards completion.
A project plan will define a set of milestones, and specify a date, by which each milestone is expected to be achieved. We will take status reports from all of the people on the project, and compare them with the established project milestones ... to ensure that everyone is working on the right tasks and making progress at the expected rate. These comparisons enable us to detect and respond to problems as quickly as possible. Well chosen milestones are key to effective project management.
The most obvious way to define project milestones is to break the project down into sub-components and tasks, and to define a milestone for the completion of each sub-component. These might or might not prove to be a good set of milestones. There are a set of characteristics that good milestones should have. They should be:
A good milestone is specific. There should be no ambiguity about what it means. A vague goal might be something like "sufficient functionality for alpha testing". A more specific goal might be "able to perform searches by artist, album, and title".
A good milestone is measurable. This means that (a)the goal should be quantitative (or at least quantifiable) and (b) that there must be an objective process for measuring its achievement.
We could define a milestone for the completion of a module ... but how does one measure completion? People often attempt to define completion by a sign-off (e.g. from some manager). The obtaining of a sign-off is indeed specific and measurable ... but what acceptance criteria should the signer use? These criteria should be clearly specified and independently ascertainable. A more quantitative and meaningful milestone might be the successful execution of all 35 of the specified unit test cases.
A good milestone is entirely achievable. Stretch goals are a good thing, but unachievable requirements are counter-productive. Sometimes, in an effort to encourage people to do their best, project managers set impractical goals (e.g. "100,000 hours of beta testing" or "zero open bugs"). Setting impractical requirements (a) ensures failure and (b) actually demotivates the team.
There is, of course, also a danger of setting the bar too low, and shipping a product that is only marginally acceptable. One way of addresing this problem is to establish a points system for capabilities, and minimum required scores for every attribute ... but to require a total score greater than the sum of the minimums.
A good milestone is directly related to the achieving of project goals. We could define a milestone for having written 2000 lines of code ... but if that code does not yet work, or if it does not deliver a complete unit of functionality, it is difficult to correlate this milestone to progress. A much better milestone might be successful completion of a code review. As a general rule, it is better to measure progress with results achieved than with effort expended ... which leads to earned value analysis.
Direct relevance is, in fact, a common problem with all kinds of goal setting (not merely the definition of project milestones). Some customer support organizations, for instance, measure their productivity with metrics like "number of cases closed" and "mean time to closure" ... which motivates support staff to close problem reports as quickly as possible, whether the underlying problems are solved or not. Unfortunately, such behavior may not directly correlate to the real goals of solving problems and satisfying customers.
A primary purpose of milestones is to measure progress. To fulfill this purpose, they must be spaced at reasonable intervals. How many milestones are need, and how closely spaced they are depends on the situation: