|
The risk issues addressed by a [[work breakdown structure]] (WBS) are then discussed. Often considered only a project planning task Kendrick points out the uncertainty and risk introduced into a project when the WBS is not fully defined and understood. A WBS at too high a level can leave scope ill defined not allowing for proper estimates or definition of work to be performed. Often WBS elements that are defined at too high a level indicate work that is not understood and indicates significant risk due to uncertainty on the project.
D*I*C*K In your mouth gets bigger during risk period.
===Schedule risk===
{|class="wikitable" align="right" width="250px"
|+Key ideas: Schedule risk
|-
|Estimates with wide variations should be investigated for thorough understanding
|-
|Identify source of estimates, especially if not empirical
|-
|Identify high risk dependencies
|-
|Compare estimates to historical values looking for large variations
|-
|Pull risk forward to allow time to react
|-
|Identify all potential critical paths
|-
|Note project duration risk
|}
Schedule is the second level of risks effecting project duration in the PERIL database. The top five (the book lists ten) categories are:
#Project Dependencies
#Parts Delays
#Estimation errors
#Decision Delay
#Hardware Delay
Dependency on external parties is the largest sub-categorization of schedule risk in the database (editors note: as might be expected since it is always safe to blame the other party) followed by poor estimations.
To assist in reducing these risks, Kendrick explains that the process should start with the WBS and apply estimates for effort and resources. This is an iterative process. A number of things should be kept in mind:
*Historical data should be used where applicable.
*Resources planning (done next) will affect these estimates so these processes will need to be iterative.
*Be cognizant of people hesitating to give estimates, it may imply additional uncertainty.
*If the durations are greater than two weeks they should be broken down further.
*Make sure to incorporate holidays, vacations and other non-project time.
He summarizes a number of estimating techniques:
*Project-level Think-Do-Check based on project size.
*Historical data
*Prior experience
*[[Delphi method|Delphi Group]] Estimating (a form of Consensus estimates)
*[[Program Evaluation and Review Technique]] (PERT)
He spends significant time throughout the book discussing the PERT method and clearing up misconceptions on the PERT process. He explains that the PERT method of estimation generates the expected duration of a task by adding the pessimistic, optimistic and four times the most likely durations and dividing them by six. The standard deviation is determined by taking the difference of the pessimistic and optimistic durations and dividing them by six. The standard deviation is a reflection of the uncertainty in the estimates.
After determining the durations and sequencing the [[critical path method|critical path]] can be determined. The Critical Path is the longest contiguous path of tasks with no lag. The easiest way to do this is by using one of the many computerized tools on the market. He cautions that an increase in critical and near-critical paths will bias or significantly increase the probability that the project will not complete by the projected time. This is due to the statistical probabilities of multiple paths causing failure.
As with many sections of the book, he provides lists of general items to use when planning.
===Resource Risk===
| 