I'm preparing a paper for the 2009 NASA PM Challenge
conference. Walter Majerowicz is a constant contributor to the professional of
project and program management. I finally met Walt at the PMI College of
Scheduling conference this year.
In a previous PMChallenge presentation, Walter mentions several sources to
project and program risk that are worth restating.
- Poor or unrealistic activity duration estimates - the "art" of estimating is largely overrated. Using probabilistic estimating techniques where the upper and lower bounds of the cost or duration is the starting point. With these estimates, classified is a geometric expansion series, the sensitivity of the cost and schedule model can be exposed. The traditional estimating process of asking for "high" and "low" estimates has been to shown to be seriously flawed.
- Deterministic / single point activity durations in logic network not based on expected value of 3-point estimates - "no single point estimate can be correct," is the starting point for programmatic risk reduction. All cost and schedule values are random variables. Without understanding the statistics of these random variables, the schedule and cost models will be wrong.
- Not capturing 100% of total work scope in schedule - no side bar work, not under the covers work, no work can be performed on the project that is not scheduled to be performed.
- Inadequate or incorrect resource planning - the notion that people will sort out the sequencing of the work for themselves is nonsense. A resource assignment plan at some level of granularity is needed.
- Inadequate or poor project logic - in what order the work is to be performed is the basis of utilizing resources and producing increasing value. This sequence is held in the Schedule.
- Insufficient schedule reserve - with cost and duration values being random variables, schedule and cost "margin" is needed. How much margin needs to be determined by some analytical means. Guessing and using some standard (20 days per year) usually is wrong. Knowing where to put the margin is the next step. Solving this problem is the role of Monte Carlo Simulation.
- Multiple convergence paths / merge bias - this is a subtle but critical issue. Parallel work tends to drive the delivery date later. This is counter intuitive but it is a fact. Look for the term "merge bias" to read about the theory.
- Overuse of directed constraints that override true schedule logic - a good schedule has all the tasks marked "AS SOON AS POSSIBLE." All other constraints need to be "real." The START NO EARLIER THAN and FINISH NO LATER THAN approaches are the kiss of death for analyzing the impacts of schedule slippage on the outcome
- Unrealistic schedule baseline – if the schedule is not credible to begin with, it never gets better
- Poor performance – late starts mean late finishes. No completing on time – as planned – simply pushes all the work to the right. The developers (or any project content provider) MUST start on time in order to finish on time. Late finishes usually mean late starts for the next collection of tasks. You can't make this up by working harder. That just spends more money.
- Uncertainty in work scope (e.g. new design, advanced technology, new processes) – adding more variance to the schedule cannot improve its credibility.
- Inexperienced project management – nothing succeeds like success. You’ve got to start somewhere, so start as a deputy to a good project or program manager and learn the ropes from her success.
- Improper or poor change control – the baseline is just that. Making changes in the absence of an impact analysis is nonsense. “Emergent” anything needs to go through a change control process. Simple, informal, formal – it doesn’t matter in the end if the right questions are asked and answered.
- Complex
organizational interfaces – the more touch points the more places things
go wrong. Managing the interfaces is a Systems Engineering discipline. Learn
from the profession of Systems Engineering how to do this right.
