Milestones are important in any paradigm of project management regardless of what tools are used to assist in project management. Carefully planned milestones go a long way towards success of a project and satisfaction of its stakeholders.
While a project may be reviewed in great detail by looking at the level of tasks, it is the milestones and their dates that aggregate the impact for easy comprehension of the bigger picture.
Now, is there a basis for setting up these milestones in a project?
While it is not exactly a science, some useful guidelines can certainly be framed to help in defining the milestones. A word of caution, of course, is in specific situation, these guidelines may be required to be adapted to fit the occasion.
Here we go:
Every important event in the life of a project is enshrined as a milestone. Usually these events mark the completion of a phase of the SDLC cycle for a module or piece of the system under development.
Associated with a milestone is a deliverable (code, document, bug-list…) of value to the stakeholders.
It is often overlooked the acceptance of the deliverable by the customer is also a milestone. It implies the deliverable is adequately tested by the vendor before delivery and is also sufficiently tested by the customer for its acceptance. The principle applies to all committments required from the various stakeholders for the successful execution of the project. And these milestones represent the committment of their owners (stakeholders) to the project. This must be impressed up on all at the very outset. It is not a solo show by the vendor driving all the milestones.
As far as possible, a milestone has a single stakeholder responsible for the deliverable. For instance, QC testing is normally done by an independent Quality group and hence gives rise to a separate milestone to mark that activity.
Obviously the definition of the milestones and their sequencing are settled jointly by the stakeholders, usually guided by the customer’s priorities and any inherent dependencies and risks.
Often a simple step is missed out of making sure all stakeholders are in the know and in agreement with the schedule of milestones. It has the potential for causing serious consequences. How often do we find the customer has planned his vaccation when the deliverable is required to be tested by him for acceptance!
A corollary of associating a deliverable with a milestone is to also link a quantum of payment by the customer to the vendor commensurate with the efforts towards the milestone.
The milestone’s deliverable must be ‘executable’ (verifiable), must represent a significant addition to the functionality delivered in the earlier milestones. And, even usable especially in the later stages of the project.
For this reason, it is a good practice to ensure the deliverable of the current milestone is completely integrated with the earlier deliverables.
In all but the simpler projects, at any instant of time, activities may be current on more than one milestone.
A key question still remains is: How many milestones should be defined in a project?
More milestones a project has, it is less risky for the customer. He has greater visibility into the project and sees it being ‘conquered by divide and rule.’ It is also less risky for the vendor as any lack of alignment of the deliverable with the customer’s needs is detected at the earliest point of time for correction. The down-side of having too many milestones is the overhead associated with readying the deliverable by the vendor and its testing by the customer for each of those milestones.
Obviously, it is the other side of the coin if there are too few milestones in the project. Besides, the vendor also gets paid later in the day for his efforts.
What is the golden mean?
Of course it depends on the size of the project. Well, a thumb-rule could be a vendor’s milestone for every 15% of the project efforts completed or for every 3 to 4 weeks of elapsed time whichever is earlier.
It is also not unusual to define a hierarchy of milestones in larger projects.
It is a normal practice to estimate and track other performance parameters besides the timeline for each milestone individually.
Hence, a high-level milestone or a set of milestones at lower level may be planned so as to include the all the phases of the SDLC cycle as completely as possible. Only then many performance parameters are meaningful. For instance Defects Density is meaningful for a milestone only if all the development efforts are included in that milestone.
And, finally, it is possible for the vendor to set up internal milestones not visible to the customer as part of the strategy to split it up into manageable pieces.
Do share your experiences in this regard.
Source: Image form Wiki