Nothing really good happens at a milestone because too many things have to come together to have success. At a milestone, seemingly independent activities have their fate joined. At the milestone, everyone is in, or else everyone is stymied when the gate is not opened to pass through.
Here's one idea: The fact is, joining together at a common event, like a milestone, is hazardous because of the concept of ‘merge bias’. Merge bias simply means there is a strong tendency to slip to the right at a milestone, thereby stretching the schedule. In other words, when you look at a schedule and you see a milestone, think immediately that there is a risk to shift right—that is, milestones are hazards to on-time performance and represent the first weakness to look at when assessing the schedule for risk.
Here's another: It’s common sense that the more independent an activity is, the more freedom of action there is. After all, there is minimum need to coordinate outcomes and processes if no one else is depending on your production. So, by corollary, dependencies limit choices, limit agile methods, and place constraints where there would not otherwise be inhibitions. Dependencies increase the effort that must go into coordination—team of teams, staff meetings, and the like—and this effort must come from some budget, and potentially the distraction of more coordination could impact other value-add work.
It’s no accident that milestones tend to shift to the right on the schedule. There is actually a mathematical explanation for this phenomenon that arises from the statistical behavior of somewhat risky activities. In a project, no activity can be known for certain—there is always some risk that things will take longer than planned, or in some cases take less time than planned
In statistics, the explanation comes from behavior of intersections and unions of events. A union is an ‘or’ case; an intersection is an ‘and’ case. A milestone is an intersection of two or more joining tasks.
Statistics defines the intersection of independent events by the product of their probabilities. There is no general formulation for the statistics of an intersection unless the events are independent. If they are not, then the only practical way to determine the performance of the intersection—in our case, the milestone—is to simulate the project by running many trials. Simulation for this purpose is the subject of another presentation.
In similar fashion, we can multiply out all the other cases of one late/early and the other either late/early or on time. For two joining paths, there is one success case—both on time—and three failure cases—one or the other or both are late. The sum of the success case and all of the failure cases must account for all the possibilities—100%. If the sum of all cases is not 100%—either more or less than—then the analyst has made some error in accounting for the possibilities.
For the project manager, the quick take away is that by glancing at the schedule and picking out milestones defined by joining paths, the weak points of the schedule are immediately seen. At every such milestone, there is a bias towards shifting to the right—an obvious hazard to on time performance
Take a look at this slideshare presentation for more information
Take a look at this slideshare presentation for more information
Ideas for Managing at the Milestone
View more presentations from John Goodpasture.
