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. 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.
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. So it is with a milestone, the achievement of which, and the satisfaction of its gating parameters, depend on the work of all joining tasks. The fact is, one late activity and the whole milestone event is at risk of being late. Furthermore, if the milestone is on the critical path, then the on-time outcome of the project is at risk. Thus, there is need for careful coordination of all activities leading to milestone achievement
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. Thus most planning is centered on most likely outcomes with an idea about confidence. In the slide shown, two activities, A1 and A2, join at a milestone. Each activity is independent of the other, but the milestone is dependent on both. In this example, there is 90% probability of each activity completing on time. A common technique is to consider 100 trials of the project and examine results. In the grid we see that A1 or A2 performance limits the opportunities for milestone performance: It is likely that in 100 trials, there will be only 81 times when both A1 and A2 jointly occur on time, reducing the milestone performance 9 percentage points compared to the individual activities. 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. The concept is that one participant in the intersection weights or discounts the participation of the others, thereby degrading the overall performance at the intersection. Degraded performance simply means that it will take more time to get everything done.
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. For this presentation, we assume the joining activities are individually independent. Thus we can employ the simple rule that the product of the joining activities determines the performance of the milestone. 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. The upshot of moving from an ‘or’ union to an ‘and’ intersection is that performance degrades and there is need to stretch things out to allow all activities to complete. Another view from the project management planning perspective is that the lower expectation may be acceptable—a risk worth taking—or a mitigation is needed to drive the expectation back up to higher figure associated with the union.
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 There are mitigations: First, the project manager may accept the risk of shift-right and be on guard to counter its effects if it happens—after all, it is not a certainty, just a probability Second, every activity should be estimated with three-point estimates, explained in prior presentations, so that risk adjustments are built into the schedule plan Third, buffers can be arrayed at weak junctures to provide elasticity and flexibility to the schedule plan. Hitting in the buffer and then buffering out to the milestone should raise the predictability of the milestone performance. However, the only way to really see the results is to simulate the project by running several trials.
Ideas for Managing at the Milestone
Quantitative Methods Part II Ideas for Managing at the Milestone John C Goodpasture Square Peg Consulting www.sqpegconsulting.com www.johngoodpasture.com
Milestones are hazards for on-time schedules! <ul><li>Milestones are dependent on everyone joining at the event—success for all depends on the successes of each </li></ul><ul><li>Dependencies stretch things out—it’s a mathematical certainty </li></ul><ul><li>Stretching at the milestone is called ‘merge bias’ </li></ul><ul><li>Merge bias explains the tendency for the schedule to ‘shift right’ at the milestone </li></ul>
Milestones are dependent on everyone joining at the event <ul><li>Dependencies limit maneuver, limit agile responses, and take actionable options off the table </li></ul><ul><li>Dependencies require effort to go into coordination—effort that costs money and takes away from other value-add work </li></ul><ul><li>Milestone performance is dependent on the independent performance of each joining activity </li></ul><ul><ul><li>If any activity is late, the milestone is late </li></ul></ul><ul><ul><li>All the conditions for milestone success must be jointly achieved </li></ul></ul><ul><li>If the milestone is on the critical path, then all the joining activities are near-critical </li></ul>Photo: Dwight Tracy Activity A1 Activity A2
Dependencies stretch things out—it’s a mathematical certainty <ul><li>A milestone is the intersection of joining schedules </li></ul><ul><li>Probability of making the milestone schedule is the probability that all joining schedules intersect on time </li></ul><ul><li>The intersection is ‘stretched’ by the need to accommodate all the joining activities </li></ul><ul><li>Consider 100 trials with 90% on time: </li></ul><ul><ul><li>For 90 A1 opportunities on time, likely only 0.9 x 90 opportunities for A1 and A2 to be on time </li></ul></ul><ul><ul><li>There are 9 + 9 + 1 opportunities to be late </li></ul></ul>Photo: Neal McQ
Example of schedule stretch <ul><li>When the intersecting activities are independent, then the probability of the intersection is the product of the intersecting probabilities </li></ul><ul><li>Example: </li></ul><ul><ul><li>A1 intersects milestone with 90% probability on-time, 10% probability of being early or late, but adding similar A2 reduces performance </li></ul></ul><ul><ul><ul><li>Probability of A1 and A2 intersecting—making the milestone on-time—is 90% x 90% = 81% </li></ul></ul></ul><ul><ul><ul><li>Probability of late = 90x10 + 10x90 + 10x10 = 19% </li></ul></ul></ul><ul><ul><li>Lower probability—81% vs 90%—translates to a likely longer schedule </li></ul></ul><ul><ul><li>Longer schedule is required to recover milestone probability to 90% </li></ul></ul>81% 100% 90% Intersecting activities stretch the opportunity to make the milestone A1 or A2 A1 & A2 Time Milestone Probability
Stretching at the milestone is called ‘merge bias’ <ul><li>Merging activities create a bias toward ‘Shift right’ </li></ul><ul><ul><li>To raise the probability from 81% back to 90%, the milestone must ‘shift right’ </li></ul></ul><ul><li>To counter the effects of merge bias: </li></ul><ul><ul><li>Risk adjust all estimates with 3-point estimates </li></ul></ul><ul><ul><ul><li>Take risk adjustments into account when building the schedule </li></ul></ul></ul><ul><ul><li>Establish time buffers </li></ul></ul><ul><ul><ul><li>Buffers are ‘reserves’ </li></ul></ul></ul><ul><ul><ul><li>Size the buffer to cover the likely ‘stretch’ </li></ul></ul></ul>Photo ShiYali
Read more about it! <ul><li>Quantitative Methods is a book about numbers and methods for applying them to practical situations in projects </li></ul><ul><li>There is a good tutorial on statistics, accounting, balanced scorecard, and value </li></ul><ul><li>The chapter on estimating is right out of my own experience </li></ul><ul><li>The presentation on earned value makes EV really workable in day-to-day situations. </li></ul><ul><li>If you do contracting, read the chapter on about doing risk management with contracts </li></ul><ul><li>And, best of all, you can buy it at any on-line retailer, and read excerpts on google/books </li></ul>
I hope you liked what you saw here <ul><li>I hope you enjoyed this presentation. </li></ul><ul><li>You can share it with your network </li></ul><ul><li>There is a lot more information in the book, at my company website, and at my BLOG. See the cover page for links </li></ul><ul><li>By the way, there is information on my other books and magazine articles at sqpegconsulting.com </li></ul><ul><li>You can contact me from my company website; the information is all there </li></ul>