A milestone anticipates what the project is supposed to achieve at a pre-set date. It should describe a desired state of affairs, the desired future situation. There are two important aspects to this. First, the concept refers to a point in time, not a period of time. Second, it looks forward to what we want to create, not how we create it.
Many define a milestone as an event in a project. It is not a very sensible definition really, because it mixes two different things together. A milestone should describe what we want to achieve; when we get there, that's the event. Most people avoid this level of precision, but by referring to milestones as events, for instance, attention may be diverted from what the project is supposed to achieve or deliver.
Milestones should preferably be felt like a natural part of the project. Of course, what people mean by “natural” depends on their experience and qualifications in subjects of relevance to the project. Natural milestones are, for example, normal decisions and consignments within the type of project we are planning.
The way a milestone is formulated should allow us to determine whether the desired state has been achieved or not. This is a major point. It is relatively simple to say whether a milestone has been reached if it is an actual object, something we can inspect and verify. If it is an abstract quality, on the other hand, we are in a different ball game altogether. When is a document good enough?