Milestones estimate the time it will take to complete your project by marking important dates and events. They are essential in project planning and scheduling. Milestones often coincide with the delivery of project documents and appear on documents such as the project schedule, project charter and project plan.
If using the guidance of the project management institute (PMI), there are typically five phases in project management: initiation, planning, execution, monitoring & controlling and closure. Maybe it makes sense to set milestones that coincide to these main project phases – but often they are more related to tasks vs phases. For even more resolution, a milestone can align to a task, sub-subtask, important event or deliverable.
Late in the project’s expected lifecycle, an unforeseen event may delay a critical milestone. This negative impact on schedule requires decisive action by the project manager and the team. Consistent communication with stakeholders must take place so their schedules will not be impacted as well – and all parties must participate in a “return to green” plan.
The first step is to coordinate with stakeholders. Often, they depend on your team meeting deadlines in order to meet their own. While parties may agree to accept the delay if slack is built into the schedule, the project’s stakeholder may have to communicate with their stakeholders if the delay will cause a ripple effect. In this case, it is important to communicate the cause of the delay as well as why the delay is necessary.
Recovery often involves increased tracking. Part of scheduling a project is monitoring and tracking the progress of the delivery schedule in real-time. Milestone charts track progress of a project and measure the remaining effort to complete a project. For this reason, stakeholders are more interested in milestone charts as they provide necessary information without excessive detailed granularity into the project’s process. Milestone charts show project progress throughout the major phases. Typically, this shows the stakeholders what is recently accomplished and what will be accomplished next.
The stakeholders may decide schedule should not slip and thus the team shall reallocate resources. This can have additional challenges in that it may cause other milestones to then slip. Another option could involve delivering a reduced set of capabilities in order to meet the deadline. Certain capabilities that are drivers of cost and schedule could potentially defer to a later milestone.
If the team decides to pursue recovery, a person shall be elected as the recovery manager to minimize recovery time, cost, and residual damage. This person shall also provide additional guidance as to whether or not recovery should take place at all by collecting additional information if possible. Typically, milestones that are not business critical, exceptionally difficult, or both, are slated for removal in favor of minimizing impact to the remaining milestones.
After evaluation of the troubled project, the team, including stakeholders, may determine that there is no good business case for project recovery so the milestone may be dropped altogether rather than waste time and money on project recovery planning. In this case, the team must plan to retire the milestone – potentially involving reverting code, stopping the Configuration Management (CM) review cycle or repurposing hardware.