Nothing really good happens at a milestone (read: also, gate). It's that simple (is there any need to read on?)
Why so? Because too many things have to come together to have success. At a milestone (gate), seemingly independent activities have their fate joined. At the milestone, everyone is in, or else everyone is stymied.
In fact, I challenge my risk mangagement students (PMI's eSeminarWorld
Advanced Risk Management) with this question:
"Has anyone ever successfully achieved a milestone with either everyone ready to participate, or no deficiencies deferred forward?". After hundreds of responses, I've had one student answer affirmatively.
Here's one rule of thumb:
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.
- They are the first weakness to look at when assessing the schedule for risk
As long as were're doing rules of thumb, 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 (like those imposed at milestones) limit choices, 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, so that means other budgets are reduced as dependencies go up.
And, don't forget distractions: potentially the distraction of more coordination could impact other value-add work.
Lies, damn lies, and statistics:
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 risky 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.
Statistics defines the intersection of independent events by the product of their probabilities.
Independence is a big deal to statisticians; less so to project managers: T
For the statistician, there is no general formulation for the statistics of an intersection if the events are not 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.
For the project manager, Simulation is no big deal. There are add-ins for simulation in all the popular scheduling and budgeting tools.
And, if there is not independence, at least for PMs, the "product of probabilities" thing is often "good enough". What it really means is that we should not be trapped by the cognitive bias of overestimating success at the milestone: it's always going to be worse than expected.
So, what's a PM to do? First to mission: Defeat all unfavorable forecasts! DDo not sit back and accept the inevitability of shifting right.
- You can reorganize the schedule logic
- You can put in buffers
- You can retool, retrain, re-resource to change the odds
- You can have a process for carrying deficiencies forward without impairing tthe critical path
In short, you can act!
Take a look at this slideshare presentation for more information
Ideas for Managing at the Milestone
View more presentations from John Goodpasture.
