Ideas for Managing at the Milestone
•Als PPT, PDF herunterladen•
1 gefällt mir•643 views
A few ideas about how to be successful managing the schedule for making a milestone
![Milestones are hazards for on-time schedules! ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von John Goodpasture
Mehr von John Goodpasture (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Ideas for Managing at the Milestone
- 1. Quantitative Methods Part II Ideas for Managing at the Milestone John C Goodpasture Square Peg Consulting www.sqpegconsulting.com www.johngoodpasture.com
Hinweis der Redaktion
- 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.