Transcript PRESENTATION NAME

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.
[email protected]
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 = Threat
Positive Risk = Opportunity
5
Negative Risk
Immediate and future threats
6
Positive Risk
Immediate and Future Opportunities
7
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 Uncertainty
Project
Risk
Project
Schedule
As you near
project end,
there is less
risk since the
requirements
are well
known and
the activities
and events
are almost all
done!
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
Project
Initiation
Qrtr One
Status
Qrtr Two
Status
Qrtr Three
Status
Qrtr Four
Status &
Closeout
10
Management vs Fire Fighting
Options
Risk Management
Cost
Fire Fighting
11
Risk Identification
12
Link Risks to Project Objectives
Cost
Quality
Schedule
Technical
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
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.
15
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
Materials
Process/Methods
Why?
Why?
Why?
Why?
Why?
Why?
Problem Statement
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
People
During Release 2, test
problems accounted
f or 50% of delays
which was 3X higher
than desired and
caused customer
dissatisf action.
Why?
Why?
Machine
Free copies of many quality tools can be obtained at: http://asq.org/learn-about-quality/tools-templates.html
18
Tools for Identifying Risks
STRENGTHS
OPPORTUNITIES
WEAKNESSES
THREATS
19
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 Taxonomy
RBS Level 0
RBS Level 1
1.0 Technical Risk
2.0 Management Risk
0. All sources of Risk
3.0 Contract Risk
4.0 External Risk
5.0 Schedule Risk
6.0 Quality Risk
RBS Level 2
1.1 Scope Definition
1.2 Requirements Definition
1.3 Estimates, Assumptions, Constraints
1.4 Technical Processes
1.5 Technology
1.6 Technical Interfaces
ETC.
2.1 Project Management
2.2 Program / Portfolio Management
2.3 Operations Management
2.4 Organization
2.5 Resourcing
2.6 Communication
ETC.
3.1 Contractual Terms & Conditions
3.2 Government Furnished Equipment / Property
3.3 Internal procurement
3.4 Suppliers and vendors
3.5 Subcontracts
3.6 Customer Stability
3.7 Partnerships and Joint Ventures
ETC.
4.1 Legislation
4.2 Exchange Rates
4.3 Site / facilities
4.4 Environmental / Weather
4.5 Competition
4.6 Regulation
5.1 Government Mandated Drop Dead Date
5.2 Critical Path Risk
5.3 Schedule Compression
6.1 Customer Satisfaction
6.2 Defect Rate
Technical
Management
Contractual
External
Schedule
Quality
25
Risks by WBS Element
Web Design
Project
Project
Management
Training
Web Product
Data
Support
Equipment
Requirements
Design
Build
Bill of
Materials
Unit Test
Business
Requirements
Test &
Evaluation
Risks by
WBS
Element
Risks by Sub- Element
System
Requirements
26
Risks by the “-ilities”
1. Usability
2. Maintainability ( or Flexibility / Testability)
3. Scalability
4. Availability (or Reliability)
5. Extensibility
6. Security
7. Portability
8. Compatibility
9. Interoperability
10. Reusability
11. Serviceability
12.Dependability
27
Summary
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.
28
Questions?????
29
PARKING LOT
1.
2.
3.
4.
5.
30