Successfully reported this slideshow.

Notes on IT programmatic risk in 5 not so easy pieces


Published on

Risk management in the IT business is similar to risk management most domains. Here's a starting point for understanding the steps needed to manage risk

Published in: Business, Technology
  • Be the first to comment

Notes on IT programmatic risk in 5 not so easy pieces

  1. 1. 1 10th Annual Rocky Mountain Project Management Symposium Denver Colorado, April 2008 FIVE EASY PIECES†: THE ESSENTIALS OF MANAGING PROGRAMMATIC RISK Managing the risk to cost, schedule, and technical performance is the basis of a successful project management method. † With apologies to Carole Eastman and Bob Rafelson for their 1970 film staring Jack Nicholson
  2. 2. The Five Easy Pieces of Risk Management 2 1.  Hope is not a strategy; Only preparedness is 2.  No point estimate of cost or schedule can be correct 3.  Cost, schedule and technical performance must be integrated for risk assessment to have credibility 4.  Risk management requires adherence to a well defined process 5.  Communication is the number one success factor
  3. 3. 3 HOPE IS NOT A STRATEGY; ONLY PREPAREDNESS IS Have specific outcomes defined before hand, with risks identified and mitigations in place should the risks become active.
  4. 4. Hope is Not a Strategy 4 A Strategy is the plan to successfully complete the project If the project’s success factors, the processes that deliver them, the alternatives when they fail, and the measurement of this success are not defined in meaningful ways for both the customer and managers of the project – Hope is the only strategy left.
  5. 5. Hope is Not a Strategy 5 The Plan for the project is the Strategy for its successful completion !  This Plan needs to define: !  !  How the products and services will be “matured” as the project progresses !  What are the “units of measure” for this increasing maturity !  At what points in the project will this maturity be assessed be assessed to confirm progress is being made
  6. 6. Hope is Not a Strategy 6 !  Hope means: ! “I hope we can get done by the weekend with the integration test” ! “I hope the control bus will be fast enough for the command loop” ! “I hope we’ll have enough management reserve to complete the project on budget” !  A Plan means: ! If we don’t get the integration test done by Friday, we’ll release without features A, B and F ! If the control bus is not fats enough, we’ll run two in parallel until the new version is complete ! At each 20% budget level, we’ll confirm our deliverables value (BCWP) match is investment value (BCWS)
  7. 7. Replace Hope with a Plan to Reduce Technical and Programmatic Risk 7 Implement  Best  Prac/ces:  Program  Schedule/Cost   Analysis  Reflects  On-­‐going  Program  Risk/ Uncertainty  Reali/es   0   +   Risk  Must  Decrease  with   Program  Maturity  along   with  the  tolerance  for  risk   –   Allowed    Risk    Variance   !  Ini8al  Concept   Milestone  A   Milestone  B   Milestone  C   Time  
  8. 8. 8 NO POINT ESTIMATE CAN BE CORRECT Point estimates of cost and schedule are not only incorrect, they are misleading – stating confidence where there is none.
  9. 9. No Point Estimate of duration or cost can be correct 9 When estimating cost and duration for planning purposes using Point Estimates results in the least likely result. A result with a 50/50 chance of being true Single Point Estimates use sample data to calculate a single value (a statistic) that serves as a "best guess" for an unknown (fixed or random) population parameter !  Bayesian Inference is a statistical inference where evidence or observations are used to infer the probability that a hypothesis may be true !  Identifying underlying statistical behavior of the cost and schedule parameters of the project is the first step in forecasting future behavior !  Without this information and the model in which it is used any statements about cost, schedule and completion dates are a 50/50 guesses ! 
  10. 10. No Point Estimate of duration or cost can be correct 10 !  Schedule duration and cost values are random variables !  !  !  !  Point Estimates cannot be correct because: !  !  !  !  Existing technical capabilities fall short of expectations Requirements cannot be stated in a well defined list “Normal” variance exists in all phases, especially the integration phase Estimates of activity durations are not correct The project duration is the sum of incorrect activity durations Costs associated with duration may not be linear The Actual project duration and cost will fall within some range surrounding the “Point Estimate” !  !  The best that can be expected is to understand the range of this uncertainty With this understanding, the project can not provision for the changes that will occur
  11. 11. The Term “Best Estimate” has no standard meaning 11 !  The “Best Estimate” means: !  The “Most Likely” (Mode)? !  The 50th percentile (Median)? !  The expected value (Mean)? !  The roll up the “Best Estimates” is almost never one of these three values
  12. 12. Each duration and cost has a probability distribution 12 !  How can it be known that: !  The “Best Estimate” is not the only possible estimate. Other estimates may be worse, than the best !  The “Most Likely” assumes that other possible duration are possible !  The Mean, Mode, Median are statistical terms that characterize probability distributions – not point values !  The Actual duration or cost is a Random Variable, drawn from a probability distribution
  13. 13. Statistics of a Triangle Distribution 13 50% of all possible values are under this area of the curve. This is the definition of the median Minimum 1000 hrs Mode = 2000 hrs Maximum 7830 hrs Mean = 3879 hrs Median = 3415 hrs
  14. 14. A Check List for Accurate Estimates 14 !  !  !  !  Business results are known an quantified Project priorities are clearly stated A standard estimating method is used for all project elements A proper Work Breakdown Structure has been developed !  !  !  !  Estimates of durations and costs have been developed from statistical distributions Planned and actual costs are being collected Lessons learned are used to correct past estimates Management accepts the detailed estimates or redefines the project
  15. 15. Probabilistic versus Deterministic Estimating 15 Deterministic Probabilistic Simple calculation of critical path Requires assessment of variances Single valued durations estimates Defined probability distribution function (Triangle) with parametric ranges Cannot quantify risk Risk defined in terms of confidence of completing on or before a date Criticality of an activity is either true or not true Criticality of an activity is probabilistic and correlated to the network paths Suited of “simple” project management approaches Suited for realistic project management by “managing under uncertainty” and “variability”
  16. 16. Points to Remember about Estimating cost and schedule 16 !  !  Good planning and control depends on good estimates Good estimates are approximations that depend on: !  Experienced cost and schedule estimators !  Realistic assumptions !  Recognizing unknowns with adequate reserves !  Recognizing the past is prologue !  It is betetr to be aopprxitamey rhgit, than to be precisely wrong – Warren Buffet
  17. 17. 17 INTEGRATE COST, SCHEDULE AND TECHNICAL PERFORMANCE Connecting Schedule, Cost, and Technical Performance is the basis of establishing a Performance Measurement Baseline (PMB) needed to successfully manage the project
  18. 18. Connecting the independent variables of project risk 18 The first impulse is to use the traditional Cost, Schedule, and Quality !  But a better approach is to connect !  !  Cost !  Schedule !  Technical Performance
  19. 19. Without Integrating $, t, and TPM you’re driving in the rearview mirror 19 Technical   Performance  (TPM)   Addressing customer satisfaction means incorporating products requirements and planned quality into the Performance Measurement Baseline to assure the true performance of the project is made visible.
  20. 20. Measures of Technical Performance 20 Measure of Effectiveness !  Measure of Performance !  Key Performance Measures !  Technical Performance Measures !  Type Item Threshold Indicator MOE Service life At least 18 years Service life expected MOP System capacity At least 18 major connections Connections support TPM Volume allocated to storage At least 17.5L Tank capacity
  21. 21. There are other project variables 21 !  Not just the traditional “iron triangle,” but other aspects of the project comes in three’s Risk CMMI Cost burden assigned to activities Process framework guides improvement Customer Satisfaction Six Sigma Income enhancement improved Problem solving methods Quality Lean Customer retention maintained Execution principles reduce waste
  22. 22. Putting it all together means dealing with three levels of risk reduction 22 Technical   Performance   Quality  
  23. 23. 23 PROGRAMMATIC RISK PROCESSES MUST BE WELL DEFINED AND PROVEN TO WORK AND FOLLOWED WITH RIGOR Use a defined risk management processes that is proven to provide value to the project and provide a consistent method of managing risk
  24. 24. Without  a  model  for  risk  management,  you’re  driving  in  the   dark  with  the  headlights  turn  off   24 Risk  Management  means  using  a  proven  risk  management   process,  adap/ng  this  to  the  project  environment,  and  using  this   process  for  everyday  decision  making.  
  25. 25. 25 RISK COMMUNICATION It does no good to manage risks if the results are not communicated to the participants
  26. 26. Risk Communication is not … 26 Telling people what we want them to know, in order to get them to behave “rationally”, that is, the way we think they should behave.
  27. 27. Risk Communication is … 27 An interactive process of the exchange of information and opinion among individuals, groups, and institutions; often involving multiple messages about the nature of risk or expressing concerns, opinions, or reactions to risk messages or to legal or institutional arrangements for risk management.
  28. 28. Components of Risk Communication 28 !  Understand the Perceptions of Risk –  –  –  Key barrier is the term “risk”: how it is measured, described, and ultimately received People do not believe that risks are of the same type, size or importance Perception of risk for the technical and lay audiences are often dissimilar !  Acknowledge Uncertainty –  –  –  –  If information is not known or not available, admit it “I don’t know” can actually build credibility Provide as much information as possible Demands for 100% certainty are more likely based on underlying values and process, not the science. Try to identify the real concerns behind the demand
  29. 29. Communicate Risk Graphically 29
  30. 30. 30 WRAP UP RISK MANAGEMENT IS HOW ADULTS MANAGE PROJECTS “In theory there is no difference between theory and practice. In practice there is.” – Yogi Berra
  31. 31. Summary 31 Risk management is project management !  Risk mitigation must be made visible in the schedule with resources, budget and risk buy down plan !  Measure project progress with increasing maturity of the deliverables. Measure risk progress with reducing risk. ! 
  32. 32. The train wreck starts when we don’t pay attention to the details 32 !  Inattention to budgetary responsibilities !  Lack of predictive variance analysis !  Untimely and unrealistic Latest !  Work authorization not always followed !  Progress not monitored in a regular !  Budget and data reconciliation issues exist !  Lack of an integrated management system !  Baseline fluctuations and frequent replanning Revised Estimates (LRE) and consistent manner !  Lack of vertical and horizontal traceability cost and schedule data for corrective action !  Lack of internal surveillance and controls !  Current period and retroactive!  Managerial actions not changes !  Improper use of management reserve !  EV techniques do not reflect actual performance demonstrated using Earned Value
  33. 33. Putting Risk Management to Work 33
  34. 34. Start With a Risk Assessment Technique 34 Risk Assessment Techniques Process risk assessment Used to assess (identify and analyze) program technical risks resulting from the contractor's processes Program Documentation Evaluation Risk Identification Provides a methodology for the comparison of key program documents and plans to ensure that they are consistent and traceable to one another. Threat and Requirements Risk Assessment Describes an approach to assess risk associated with requirements and threats and to identify those requirements and threat elements that are risk drivers. Product (WBS) Risk Assessment Identifies those risks associated with a given system concept and design. Cost Risk Assessment Provides a program-level cost estimate at completion (EAC) that is a function of performance and schedule risks. Quantified Schedule Risk Assessment Provides a means to determine program-level schedule risk as a function of the technical performance and cost risk associated with the various activities that comprise the program. Expert Interviews Provides a means for collecting relevant risk-related data from subject-matter experts and personnel who are intimately involved with the various aspects of the program Analog Comparison/Lessons Learned Studies Uses lessons learned and historical information about the risk associated with programs that are similar to the new system to identify the risk associated with a new program. Risk Prioritization and Risk Aggregation Provides a means to prioritize the risks present in a program and to roll-up lower level risks into a meaningful value at the critical risk area and process level.
  35. 35. Manage Risk 35 Risk Process Activities performed during the process Controlling Lowering the chance that an event will occur by using multiple contractors, conducting multiple tests, reusing proven software versus developing new software, parallel design and development of key sub-systems and components, and incremental upgrades Avoiding Changing the source (element or constraint) that is subjecting the program to risk by reducing the scope of performance objectives, using more expensive materials or processes with proven track records, extending the schedule to increase the probability of success. Assuming Planning for the potential consequences by accepting the risk, putting a monitoring process in place, and taking action now that will support contingency actions if the risk materializes into an actual problem. Transferring Transfer cost or schedule risk to another organization, and assigning responsibility to the organization that is best suited to minimize the probability of a negative consequence.
  36. 36. Top 9 Reasons Projects Fail 36 Reason 28% Poor Communication 18% Insufficient resource planning 13.2% Unrealistic schedules 9.8% Poor project Requirements Lack of stakeholder buy in Undefined project success factors or closure criteria Unrealistic budgets Insufficient or no risk planning Lack of control or change process 6.7% 5.2% 4.8% 4.4% 4.3%
  37. 37. 37