Notes on IT programmatic risk in 5 not so easy pieces

37
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 10 th Annual Rocky Mountain Project Management Symposium Denver Colorado, April 2008 1

description

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

Transcript of Notes on IT programmatic risk in 5 not so easy pieces

Page 1: Notes on IT programmatic risk in 5 not so easy pieces

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

10th Annual Rocky Mountain Project Management Symposium Denver Colorado, April 2008

1

Page 2: Notes on IT programmatic risk in 5 not so easy pieces

The Five Easy Pieces of Risk Management

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

2

Page 3: Notes on IT programmatic risk in 5 not so easy pieces

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.

3

Page 4: Notes on IT programmatic risk in 5 not so easy pieces

Hope is Not a Strategy

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.

4

Page 5: Notes on IT programmatic risk in 5 not so easy pieces

Hope is Not a Strategy

!  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

5

Page 6: Notes on IT programmatic risk in 5 not so easy pieces

Hope is Not a Strategy

!  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)

6

Page 7: Notes on IT programmatic risk in 5 not so easy pieces

Replace Hope with a Plan to Reduce Technical and Programmatic Risk

!  Implement  Best  Prac/ces:  Program  Schedule/Cost  Analysis  Reflects  On-­‐going  Program  Risk/Uncertainty  Reali/es  

+  

–  Allowed

   Risk    Variance  

Time  Milestone  A   Milestone  B   Milestone  C  Ini8al  Concept  

Risk  Must  Decrease  with  Program  Maturity  along  with  the  tolerance  for  risk  

0  

7

Page 8: Notes on IT programmatic risk in 5 not so easy pieces

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.

8

Page 9: Notes on IT programmatic risk in 5 not so easy pieces

No Point Estimate of duration or cost can be correct

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

9

Page 10: Notes on IT programmatic risk in 5 not so easy pieces

No Point Estimate of duration or cost can be correct !  Schedule duration and cost values are random variables

!  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

!  Point Estimates cannot be correct because: !  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

10

Page 11: Notes on IT programmatic risk in 5 not so easy pieces

The Term “Best Estimate” has no standard meaning

!  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

11

Page 12: Notes on IT programmatic risk in 5 not so easy pieces

Each duration and cost has a probability distribution

!  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

12

Page 13: Notes on IT programmatic risk in 5 not so easy pieces

Statistics of a Triangle Distribution

Mode = 2000 hrs

Median = 3415 hrs Mean = 3879 hrs

Minimum 1000 hrs

Maximum 7830 hrs

50% of all possible values are under this area of the curve. This is the definition of the median

13

Page 14: Notes on IT programmatic risk in 5 not so easy pieces

A Check List for Accurate Estimates

!  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

14

Page 15: Notes on IT programmatic risk in 5 not so easy pieces

Probabilistic versus Deterministic Estimating

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”

15

Page 16: Notes on IT programmatic risk in 5 not so easy pieces

Points to Remember about Estimating cost and schedule

!  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

16

Page 17: Notes on IT programmatic risk in 5 not so easy pieces

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

17

Page 18: Notes on IT programmatic risk in 5 not so easy pieces

Connecting the independent variables of project risk

!  The first impulse is to use the traditional Cost, Schedule, and Quality

!  But a better approach is to connect ! Cost ! Schedule ! Technical Performance

18

Page 19: Notes on IT programmatic risk in 5 not so easy pieces

Without Integrating $, t, and TPM you’re driving in the rearview mirror

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.

Technical  Performance  (TPM)  

19

Page 20: Notes on IT programmatic risk in 5 not so easy pieces

Measures of Technical Performance

!  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

20

Page 21: Notes on IT programmatic risk in 5 not so easy pieces

There are other project variables

!  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

21

Page 22: Notes on IT programmatic risk in 5 not so easy pieces

Putting it all together means dealing with three levels of risk reduction

Technical  Performance  

Quality  

22

Page 23: Notes on IT programmatic risk in 5 not so easy pieces

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

23

Page 24: Notes on IT programmatic risk in 5 not so easy pieces

Without  a  model  for  risk  management,  you’re  driving  in  the  dark  with  the  headlights  turn  off  

Risk  Management  means  using  a  proven  risk  management  process,  adap/ng  this  to  the  project  environment,  and  using  this  process  for  everyday  decision  making.  

24

Page 25: Notes on IT programmatic risk in 5 not so easy pieces

RISK COMMUNICATION It does no good to manage risks if the results are not communicated to the participants

25

Page 26: Notes on IT programmatic risk in 5 not so easy pieces

Risk Communication is not …

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.

26

Page 27: Notes on IT programmatic risk in 5 not so easy pieces

Risk Communication is …

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.

27

Page 28: Notes on IT programmatic risk in 5 not so easy pieces

Components of Risk Communication

! 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

! 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

28

Page 29: Notes on IT programmatic risk in 5 not so easy pieces

Communicate Risk Graphically 29

Page 30: Notes on IT programmatic risk in 5 not so easy pieces

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

30

Page 31: Notes on IT programmatic risk in 5 not so easy pieces

Summary

!  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.

31

Page 32: Notes on IT programmatic risk in 5 not so easy pieces

The train wreck starts when we don’t pay attention to the details

!  Inattention to budgetary responsibilities

!  Work authorization not always followed

!  Budget and data reconciliation issues exist

!  Lack of an integrated management system

!  Baseline fluctuations and frequent replanning

!  Current period and retroactive changes

!  Improper use of management reserve

!  EV techniques do not reflect actual performance

!  Lack of predictive variance analysis

!  Untimely and unrealistic Latest Revised Estimates (LRE)

!  Progress not monitored in a regular and consistent manner

!  Lack of vertical and horizontal traceability cost and schedule data for corrective action

!  Lack of internal surveillance and controls

!  Managerial actions not demonstrated using Earned Value

32

Page 33: Notes on IT programmatic risk in 5 not so easy pieces

Putting Risk Management to Work 33

Page 34: Notes on IT programmatic risk in 5 not so easy pieces

Start With a Risk Assessment Technique

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.

34

Page 35: Notes on IT programmatic risk in 5 not so easy pieces

Manage Risk

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.

35

Page 36: Notes on IT programmatic risk in 5 not so easy pieces

Top 9 Reasons Projects Fail

Reason

Poor Communication

Insufficient resource planning

Unrealistic schedules

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

28%

18%

13.2%

9.8%

6.7%

5.2%

4.8%

4.4%

4.3%

36

Page 37: Notes on IT programmatic risk in 5 not so easy pieces

37