The purpose of the Integrated Master Schedule (IMS) is to model and communicate the plan to accomplish a project’s objectives. A key part of that model is the identification of key events that are represented as milestones. The selection of these milestones should be done with consideration for its purpose – what does the milestone represent and communicate? You should be aware of the intent of each milestone that is entered into the IMS. The IMS is a critical communication tool to ensure everyone on the project has a common understanding of the project’s work flow. Too many times I have witnessed a scheduler slam a milestone into the IMS without regard to how it impacts the schedule logic. This could be due to haste but, in my experience, it is often due to a lack of understanding of the purpose of the milestone.
Figure 1 illustrates a common diagram for a milestone.
As illustrated in Figure 1, the milestone is a gate and will hold up work in task C until the milestone is claimed as finished.
If the intent is to have the milestone act as an indicator instead of a gate, then the diagram in Figure 2 could satisfy that intent. If a successor is needed for the indicator milestone, something like the “End of Project” milestone could be added.
An accomplished scheduler knows the dangers of a Merge in the IMS. The Merge introduces schedule risk. Imagine the damage to the schedule risk assessment (SRA) if a Merge were entered as illustrated in Figure 3.
In addition to adding risk, as the question indicates in Figure 3, the situation portrayed may not be true.
Is the purpose of a milestone clear to everyone?
What is the real purpose of the milestone? That must be defined first so the diagram can be entered properly into the schedule, and the IMS can model the correct steps for the project. Along with the definition of the purpose, the completion criteria should be defined and documented.
Unfortunately, this problem often extends to others on the project and even to those most responsible for the project – the Program/Project Managers (PMs). A case in point. Some years ago, a high-level customer PM challenged me, in my role as the contractor IMS architect, after the PM’s schedule subject matter expert (SME) expressed their concern that milestones in the IMS were being input incorrectly.
The milestone in dispute was the Preliminary Design Review (PDR). The PM and the PM’s schedule SME said the review was a gate and therefore should be modeled as illustrated in Figure 4. Note: In the real schedule, there were many more predecessors and successors to the milestone. Figure 4 simplifies the schedule content for clarity.
They both agreed that Tasks A and B were tasks to be done during the review itself and that the Milestone was to represent the satisfactory completion of the review. According to the definition of the PDR in the Integrated Master Plan (IMP) entrance/exit criteria, the review would lead to a letter of acceptance. The letter of acceptance was the definition of done in this case. When asked how long it would take from the time the review in A and B (and all predecessors) would be held until the letter was received, the answer was something in the order of weeks.
A literal reading of the IMS would go like this: “Hold the review in tasks A and B (and all predecessors) then wait for the approval letter before starting any other work.”
When asked if it was the PM’s intent for the several hundred engineers and others working on the project to put down their pencils after the review and wait for the letter while doing nothing as shown in PM’s desired version of the milestone in the IMS, the immediate reaction of the PM was shocked silence. Of course not. The project could not go on hold for even one week waiting for a letter. The teams would disband, and the workforce would be gone. Work would stop.
I then told the PM it was not the contractor’s intention to go parade rest and wait for the letter even if he had thought that was what was supposed to happen. If the review in A and B was deemed successful with some reasonable set of action items, then the teams would proceed. It might be that they would proceed on risk, but they would proceed anyway. I then showed the PM and the PM’s schedule SME how we would model the review in the IMS to show proceeding on risk. It would look like the example in Figure 5 if we implemented the milestone as an indicator milestone.
The PM thought that could work but was concerned there was no gate review aspect to this diagram and PM control of the project would be weakened or lost. I then showed him how we could put the review into the IMS as an indicator with a delayed gate effect. In other words, work would proceed while the letter was being prepared but would stop at some point if the letter was not received. That diagram looked like the example in Figure 6.
The letter could be prepared while the teams worked on tasks C and D. If issues arose then the teams would be compelled to stop after tasks C and D individually. In this case an issue with task C might not hold up task D and conversely, an issue with task D might not hold up task C. This was a measure of control the PM thought would be adequate when the need for the approval letter in the milestone was also added.
Talking Through the IMS to Verify the Intent of Milestones
The point is that the IMS is a model of the project that should define exactly what is supposed to happen. What exactly is the IMS telling us to do? Is the review a gate? Is it just an indicator? What do the documents and agreements say about the milestone? This is definitely not the time to quickly slam a milestone into the schedule logic without taking the time to think about its purpose or what you want to communicate to someone else on the project.
This story also highlights the importance of ‘reading’ or ‘talking through’ the IMS. When it was explicitly stated that the project would be put on hold if the schedule depicted in Figure 4 were followed, the team quickly realized the need for a better approach, leading to the development of a more effective plan.
Interested in Learning More?
There is an art and skill that is honed over time for creating integrated master schedules that accurately reflect the work to be performed and clearly communicates that plan to everyone on the project. There is always more to learn. H&A offers basic and advanced scheduling workshops taught by senior master schedulers with decades of experiences in all types of scheduling environments that can be tailored for the scheduling tools you are using. Give us a call today to get started.