The Soft and Squishy Side of Risk How To Get Started Identifying Your Risks

April 23, 2012

Presented by: Joann Heck, PMI-RMP, PMP Project Support Process Manager SRA International, Inc. Joann_Heck@sra.com 703-227-8351

A risk cannot be managed unless it is first identified.

PMI Risk Management Handbook

2

What is a RISK?

Definable future event that will affect one or more of your project objectives.

=====================================================A future event:• that is uncertain – that has a probability of occurrence is above 0% but less than 100%• with at least one cause – that is uniquely associated with it• that has consequences should it occur - positive or negative consequences (impact)• that has a time envelope associated with it. A short “fuse” or time frame prior to the

event occurring is considered urgent for purposes of action

3

Risk Characteristics

Every risk has 3 characteristics … • PROBABILITY – likelihood of the risk happening; the occurrence• IMPACT – amount of consequence (impact) caused by the risk.

– should the risk occur it could be positive or negative, depends upon the kind of risk.

• URGENCY – the need to respond in the near-term or in the far-term

4

Types of Risks

Negative Risk = ThreatPositive Risk = Opportunity

5

Negative RiskImmediate and future threats

… THREAT …6

Positive RiskImmediate and Future Opportunities

7

…Opportunities…

WE Don’t Know . . .

What we don’t know!– This makes us dangerous to the success of our project– This causes us to “assume” things are true when they may not

be true– This causes us to believe in the reality we have made up and

are convinced is the ‘reality’

DANGER WILL ROBINSON ! ! ! ! !8

Why Identify Risks?

We identify risks so we can manage risks by taking the time to plan, identify, analyze, determine responses, monitor, and control actions to:

• INCREASE the probability and resultant impact to our project for Positive Events (opportunities)

• DECREASE the probability and resultant impact to our project of Negative Events (threats)

• To consider the impacts of ACCEPTING risks we choose not to do anything about

So we can be more prepared as we move from planning into project execution/implementation.

9

Cone of UncertaintyProject Risk

Project Schedule

Project Initiation

Qrtr OneStatus

Qrtr TwoStatus

Qrtr ThreeStatus

Qrtr FourStatus & Closeout

At the beginning of every project, there is lots of risk – because we don’t know much about the requirements and the future activities / events

As you near project end, there is less risk since the requirements are well known and the activities and events are almost all done!

10

Management vs Fire Fighting

11

Options Cost

Risk Management Fire Fighting

Risk Identification

12

Link Risks to Project Objectives

Cost

Schedule Technical

Quality

13

Tools for Risk Management Planning• Planning Meetings

– Include risk as an agenda item in every meeting– Seek description, impact, and resolution

• Interviews– Include team members, managers, subcontractors– Include customers, other vendors– Include internet searches

• Discussions– Seek description, impact, and resolution

14

Tools for Identifying Risks

15

A.1 On task order award, Customer will provide tools to support project planning, configuration management, defect tracking, document management, diagramming, and team collaboration in accordance with the agreed upon Project tool specifications.

A.2 Within 30 days of task order award, Customer will provide hardware platforms for development and testing in accordance with the agreed upon Project environment specifications.

A.3 Within 30 days of task order award, team members will have access to standard project development tools in accordance with the agreed upon specifications for Management/Analyst and Developer laptop software and server-based tools configurations.

A.4 On task order award, Contractor staff will have access to training or practice accounts on appropriate application systems, including legacy systems.

A.5 On task order award, Contractor staff will have electronic access to baselined Project requirements in the Customer’s RequisitePro repository.

A.6 All issues documented in the related System Requirements Specification volume(s) and project Framework System Design Specification have already been resolved or can be quickly resolved by the Project governance bodies without impact to the task order schedule.

Tools for Identifying Risks• Information gathering techniques

– Asking– Brainstorming– Company historical information– Discussions

• Seek and you will find…

16

Tools for Identifying Risks• Performing preliminary analyses using checklists• Project specific lists of points that you want to

review for risks• Start with the SEI for examples of risk checklists

http://www.sei.cmu.edu/library/abstracts/reports/93tr006.cfm

17

Tools for Identifying Risks

18

Process/MethodsMaterials

MachinePeople

Why?

Why?

Why?

Why?

Why?

Why?

Why?

Why?

Why?

Why?

Why?

Why?

Why?

Why?

Why?

Why?

During Release 2, test problems accounted for 50% of delays which was 3X higher than desired and caused customer dissatisfaction.

Problem Statement

Free copies of many quality tools can be obtained at: http://asq.org/learn-about-quality/tools-templates.html

Tools for Identifying Risks

19

 STRENGTHS OPPORTUNITIES

  

        

                    

WEAKNESSES THREATS    

    

   

Where To Look for Risks• Organizational Process Assets (History)• Lessons Learned from Other Projects• Risk Sources• Risk Taxonomy• Project Assumptions• Work Breakdown Structure (WBS)

20

Where To Look for Risks• Customer – we have no control over these

– Multiple decision makers– Geographically disperse– Micromanager

• Company Management – we have no control over these as well– Multiple decision makers– Geographically disperse– Micromanager

21

Sources of Technical Risk• Scope not clearly defined (including boundaries, assumptions, and constraints)• Requirements not fully defined• No basis of estimate• Technical methodology not defined• Processes and procedures are not mature• New (leading edge) technology to be used• More than five interfaces to other external systems• Performance requirements not well understood• Safety issues are not identified• Security issues are not detailed and understood• Test and user acceptance plans are not agreed upon by customer

22

Sources of Management Risk• Shared Project Manager and/or Technical Lead• Multiple Projects/Programs/Portfolios to manage• Matrix Organization – may be conflicting management• Staffing/Resource Challenges• Weak Communication/No Communication Plan• Inconsistent Information• Environmental issues• Safety Issues• Quality Issues• Company’s Reputation

23

Sources of External Risk**• Legislation• Exchange rates• Site/facilities• Environmental/weather• Competition• Regulatory• Political• Country• Social/demographic• Pressure groups• Force majeure** Hillson, David. Managing Risk in Projects, Burlington, Vermont: Gower Publishing Company, 2009 Link = http://www.risk-doctor.com/

24

Risk TaxonomyRBS Level 0 RBS Level 1 RBS Level 2

0. All sources of Risk

1.0 Technical Risk

1.1 Scope Definition1.2 Requirements Definition1.3 Estimates, Assumptions, Constraints1.4 Technical Processes1.5 Technology1.6 Technical InterfacesETC.

2.0 Management Risk

2.1 Project Management2.2 Program / Portfolio Management2.3 Operations Management2.4 Organization2.5 Resourcing2.6 CommunicationETC.

3.0 Contract Risk

3.1 Contractual Terms & Conditions

3.2 Government Furnished Equipment / Property3.3 Internal procurement3.4 Suppliers and vendors3.5 Subcontracts3.6 Customer Stability3.7 Partnerships and Joint VenturesETC.

4.0 External Risk

4.1 Legislation4.2 Exchange Rates4.3 Site / facilities4.4 Environmental / Weather4.5 Competition4.6 Regulation

5.0 Schedule Risk5.1 Government Mandated Drop Dead Date5.2 Critical Path Risk5.3 Schedule Compression

6.0 Quality Risk 6.1 Customer Satisfaction6.2 Defect Rate

Technical

Management

Contractual

External

Schedule

Quality25

Web Design Project

Project Management Training Web Product

Requirements

Business Requirements

System Requirements

Design Build Bill of Materials Unit Test

Data Support Equipment

Test & Evaluation

Risks by WBS Element

Risks by WBS

Element

Risks by Sub- Element

26

Risks by the “-ilities”

27

1. Usability2. Maintainability ( or Flexibility / Testability)3. Scalability4. Availability (or Reliability)5. Extensibility6. Security7. Portability8. Compatibility9. Interoperability10. Reusability11. Serviceability12.Dependability

Summary

28

Many of the early activities aimed at identifying risk (positive or negative) have to do with people skills, brainstorming, and creative activities. This is what I generically call “that soft squishy stuff” since it cannot be prescribed by a rigid process or specific steps.

Communicating and presenting the team with opportunities to discuss and identify risks is paramount to the success of the project. This also teaches the newer project team members that the PM is serious about delivering “on time” and “within budget” to “satisfy the customer’s requirements.” This is also a soft and squishy skill that the PM can use to strengthen bonds, reinforce credibility, and become a trusted partner in the events of the project.

Lastly, by providing regular opportunities to discuss risks, the PM is encouraging team members to participate and contribute their ideas & experiences. By soliciting their contributions to a risk program the PM motivates and makes the team stronger as they perform the activities necessary for project success.

Questions?????

29

PARKING LOT

1. 2. 3. 4. 5.

30