STRIDE Standard Process for RISK

STRIDE
Standard Process
for Risk
Management
By: Romains Bos

STReamlined
Innovation &
Development
Excellence
S T R I D E

What is Risk?
A risk is not a:
• Problem: something already wrong or undesirable that it is too late to
avoid and which needs to be fixed now
• Concern: something that is causing worry, in which case it’s best to
discuss it as an issue and see if there is a problem or a risk driving the
concern
• Issue: something that requires discussion to either reach understanding or
clarify a direction, problem, or potential risk
RISK: An uncertain event or condition that, if it occurs, has a positive or a negative
effect on at least one project objective, such as time, cost, scope, or quality
PMBOK® Guide, 4th Edition

Flow of STRIDE Tools in Initiating & Planning
Processes
Clarifying remark
to initial
verbatim
response.
Clarifying remark
to initial
verbatim
response.
VerbatimVerbatim
response to nonresponse to non
leading question.leading question.
from team.from team.
VerbatimVerbatim
Customer's
response to
probing by team.
VerbatimVerbatim
VerbatimVerbatim
VerbatimVerbatim
VerbatimVerbatim
Clarifying remark
to initial
verbatim
response.
Customer's
response to
probing by team.
Clarifying remark
to initial
verbatim
response.
Clarifying remark
to initial
verbatim
response.
Clarifying remark
to initial
verbatim
response.
Clarifying remark
to initial
verbatim
response.
VerbatimVerbatim
VerbatimVerbatim
VerbatimVerbatim
VerbatimVerbatim
Customer's
response to
probing by team.
Customer's
response to
probing by team.
VerbatimVerbatim
VerbatimVerbatim
VerbatimVerbatim
VerbatimVerbatim
VerbatimVerbatim
VerbatimVerbatim
VerbatimVerbatim
VerbatimVerbatim
Clarifying remark
to initial
verbatim
response.
Clarifying remark
to initial
verbatim
response.
Customer's
response to
probing by team.
Customer's
response to
probing by team.
X Y
Stage 1 FAI
required on all
hardware
Rapid turnaround of
prototype hardware
on fuel injector
The development
programme will run
better with co-
ordinated use of all
availabletest faciities
Current funding
may only provision
for 4 - 5 builds
The last build will
be an indurance run
High cost / weigt
must be justified on
builds 1 & 2 with
audit team
understanding and
control of tolerance
stack up through fuel
system will produce a
better system
Design and
manufacture drop
offs would threaten
the programme
RR need to do a risk
assessment before
they can define safety
critical and despatch
critical areas
High risk
technology can be
included if it does
not hazard the
whole programme
Defined levels of
risk at each build
are needed to
define inovation
level
Risk levels will
reduce over the life
of the programme
Risk may be reduced
via rig tests as well
as engine tests
A simple overall
final system that
meets
performance
objectives
+ + + + +
Deliver a TRL6
system + + + + +
Programme and
schedule + +
ACTIONS
Define what stage
1 FAI
requirements are
Design for quick
prototype
Continue to work
with funding
agencies
Goodrich to be
partner in audit
team
Late change of
requirements need to
be managed
RR to schedule and
early whole engine risk
assessment to define
safety and despatch
critical features
Ensure innovative
solutions are
explored for builds
1 & 2
Joint risk
management plan
Joint risk
management plan
Document Review
Voice Of the Customer
Impact Matrix
Output:
Actions to resolve higher fidelity
requirements and increased
confidence of compliance
Deliverables Map
LWW Project Plan
Output:
Risk Mitigation and
Contingency Plans
Output:
LWWPP with active
risk mgmt. built in
Risk Management
This is an Iterative process that
continues into the Executing and
Monitoring and Control Processes
You are
Here

What is Risk Management?
• Risk management is proactive. The key point is acting early
enough to be effective. If not, we go into a reactive mode and
address a problem
Risk Management includes the processes concerned with conducting risk
management planning, identification, analysis, responses, and monitoring
and control on a project … to increase the probability and impact of positive
events, and decrease the probability and impact of events adverse to the
project
PMBOK® Guide, 4th Edition

Risk Management Process
—PMBOK® 4th Edition, Chapter 11
Regular Reviews
and Updates
0) Risk Planning
- Select Risk Mgmt Team
- Conduct Initial Risk Assmt
- Create Risk Mgmt Plan
- Obtain Plan Approval
1) Risk Identification
- Explore RBS
- Identify Risks
- Draft Risk ID section of
Risk Register
2) Risk Analysis
- Agree to Ranking Criteria
- Determine Risk Impact &
Probability
- Estimate Risk $ (optional)
3) Risk Response
- Assign Owner
- Classify Response Type
- Develop Response(s)
- Risk Impact & Prob. After
- Est. Response $ (optional)
4) Risk Control
- Execute Response
- Monitor Risks
- Report Risk Status
This Process is
Iterative!

Risk Management Planning
Conduct Initial Risk
Assessment
Select Team Members
and Functional
Experts
Complete Risk
Management Plan
Secure Plan
Approval
RiskPlanning
- Rating for each of 9
questions
- Determine level of
Risk Mgmt required
to manage risk
- Determine Required
Organizational
Functions
- Define Core Risk
Management Team
Members
- Supporting Members
- Stakeholders
- Experts
- Functional Leads
- Project Name
- Customer
- Contract $ Value
- Project Duration
- Define Methodology
- Establish Review
Frequency
- Define Metrics &
Reporting Frequency
- Sign-off Plan
with Project Principles
- File with Project Mgmt
Documents
Continue
To Risk
Identification
• Risk Management Planning is the process of deciding how to approach
and conduct the risk management activities for a project
• Ensures that the level and visibility of risk management match
importance of the project to the organization
• Provides for sufficient resources and time for risk management
activities
• Establishes an agreed-upon basis for evaluating, monitoring and
controlling risks

Risk Management Plan (RMP)
Brief
description of
the project from
a risk viewpoint
Responsibilities
of the PM, RMB,
Project Team,
QA, Sr. Mgmt,
other
stakeholders
Level of
communication
with senior mgmt.
& stakeholders
Strategy,
process, ground
rules and
assumptions,
schedule, and
budget/cost
guidelines
Defines the risk management approach to be used on the project.
Subcontractor,
customer, and
relevant
stakeholder
involvement
Full Blown Risk Management Plan
Needed or
available
resources
including tools,
people,
facilities
Definitions
of risk
groupings,
categorizations,
scoring,
ID technique(s),
Escalation &
Retirement
Criteria

Risk Management
Plan
Cover Sheet
(Used as a screening
tool for all projects/
programs to get
agreement on scope
of Risk Management
need)
Project Name: Customer:
Risk Leader: Project Duration:
Contract Value: Project Type:
Link to Project Plan:
Outcome of Initial Risk
Assessment
0.0
Purpose of Project:
Output:
Support
Red
Formal risk management
process. Support by all key
stakeholders to identify risks.
Yellow
Use key stakeholders to
identify risks.
Green
Further support only as
needed.
Risk Team Members /
Stakeholders
% of
time
Function
Frequency of updates:
Risk Leader: signature/date
Leadership: signature/date
Program Manager: signature/date
Functional Dept. Head: signature/date
Additional: signature/date
Recommendations for
Risk Mgmt based on
Outcome of Initial Risk
Assessment
Daily to weekly reviews of response
plan status. Monthly updates of
Risk Register.
Dedicated Risk
Management Team if
needed.
Complete Risk Mgmt Plan
and Initial Risk Assessment
at minimum.
Regular reviews of response status
(may be part of project plan).
Monthly updates of Risk Register.
Review of risk management is
required if circumstances change.
Initial Risk Assessment Worksheet
Roles & Responsibilities
Dedicated Risk
Management Team.
Planning/Mgmt Update Frequency
Risk Management Plan
Scope Statement for Project Risk Management
Risk Management Plan Approval

Initial
9 Question
Risk
Assessment
(Used as a guide
to quickly
determine overall
project/ program
risk)
Initial Risk Assessment Worksheet (New Product Introduction)
Project Name: Risk Leader:
0 0
1) Complete probability rating for all 9 risk factors (causes). Record assessment participants.
2) Provide Project/Program comments as necessary to explain the ratings that you gave.
3) Summary score is automatically transferred back to Risk Management Plan.
Risk Factor (Cause) Impact of Risk (Effect)
Probability of
Risk Factor
Occurring Project/Program Comments
1
Proposal price is less than the current
estimated cost.
Design will not be sustainable in production due to high
NRC. May need product redesign or structured cost
reduction via STRIDE tools.
2
Performance parameter
extrapolations are outside the
experience base of previous products.
Design will operate beyond our experience base or known
response surface. May need additional design, prototypes,
testing to mitigate risk
3
The product contains the first use of
materials beyond the SBU's
experience.
Design will be outside our experience base. May need
additional materials expertise, properties data and testing to
mitigate risk.
4
The product contains the first use of
technology beyond the SBU's
experience.
Design will operate beyond our experience base. May need
additional design expertise, Tech Center Support, 3rd party
support, prototypes, testing or significant development time
to mitigate risk
5
Inventions are required or expected
during design/development.
Design is not based upon demonstrated designs and requires
innovation to succeed. May need additional design,
prototypes, testing or significant development time to
mitigate risk
6
New suppliers to the SBU will be
involved or required.
Program success is dependent upon a supplier in which we
have no experience or performance history. May need
additional supply chain, engineering or operations support to
qualify the supplier or find alternative qualifiable sources.
7
New design processes or tools will be
used that are beyond the SBU's
current experience.
Program success is dependent upon tools or processes in
which we have little or no experience. May need additional
engineering expertise, tool vendor support, training or
development time to apply new tools.
8
New manufacturing processes to the
SBU are required.
Program success is dependent upon manufacturing
processes in which we have little or no experience. May
need to build a productivity learning curve, prototype
operating cells or additional training into the program plan.
9
Conditions are expected to change
(e.g. schedules, customer
requirements, regulations) that may
invoke any of the above conditions.
Design will not be sustainable in production due to high
NRC. May need product redesign or structured cost
reduction via STRIDE tools.
Summary Score (1-5): 0.0
Return to Risk Mgmt Plan

Risk Register Used Throughout To
Manage Risk Management Process
1) Risk Identification: 3) Risk Response Planning: Date:
Total Cost
of Effects:
TOTAL RISK: 104 $21,500 RISK AFTER: 31 $12,500 83
RiskItem#
Entry
Date
Risk
Category
Cause
(If this
happens…)
Effect
(Then this
may
happen…)
Probability
(1-5)
Impact
(1-5)
RiskScore
(1-25)
RiskEffect
Estimated
Cost$
Risk Owner
Response
Type Risk Response(s)
ProjectCross
Ref.#
Due
Date
Response
Status
Estimated
Probability
After(1-5)
Estimated
ImpactAfter
(1-5)
Estimated
RiskScore
After(1-25)
Response
Cost$
Current
Risk
Score
Response
Plan
StartDate
1.0 11-Jan-08
Technical/
Design
Risk cause 1 Risk cause 1 1 3 3 Jack White Accept 0 1 3 3 3
2.0 11-Jan-08 Project Mgmt Risk cause 2 Risk cause 2 5 3 15 $1,500 Mary Jane Contingency Risk Response 2.0 21 1-Jun-08 1 2 1 2 $500 11.75 1-Mar-08
3.0 11-Jan-08 Development Risk cause 3 Risk cause 3 3 4 12 $20,000 Joe Dude Mitigate Risk Response 3.0 34 20-Apr-08 3 3 1 3 $12,000 5.25
4.0 11-Jan-08 Development Risk cause 4 Risk cause 4 5 5 25 Sally Bobaly Avoid Risk Response 4.0 35 25-Jul-08 0 2 3 6 25 1-Apr-08
5.1 12-Mar-08 Supply Chain Risk cause 5 Risk cause 5 4 5 20 John Johnson Mitigate Risk Response 5.1 37 1-Aug-08 2 2 2 4 12
5.2 0 John Johnson Contingency Risk Response 5.2 37 2-Aug-08 0 0 0
6.0 12-Mar-08
Mfg/
Operations
Risk cause 6 Risk cause 6 2 4 8 Julie Bobuly Transfer Risk Response 6.0 42 1-Jun-08 3 2 2 4 5
7.0 19-Mar-08 Supply Chain Risk cause 7 Risk cause 7 2 3 6 John Johnson Accept 0 2 3 6 6
8.1 19-Mar-08
Technical/
Design
Risk cause 8 Risk cause 8 3 5 15 Jack White Mitigate Risk Response 8.1 23 15-Sep-08 0 3 1 3 15 1-Apr-08
8.2 0 Jack White Mitigate Risk Response 8.2 24 15-Sep-08 0 0 0 15-May-08
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
Risk
Foreca
sting:
2) Risk Analysis: Total
Current
Risk
Score:
Total Cost
of
Responses:
1-Apr-08
Sort by
Risk Item #
Sort by
Risk
Score
Sort by
Current Risk Score
Sort by
Risk
Owner

Risk Identification
• Risks of all types may be identified throughout the New Product
Introduction process – including in opportunity targeting, proposal
development, project planning, product and process design, verification
and validation, and production ramp-up
• Risk identification is an iterative process because new risks will become
known as the project progresses through its life cycle
Review and Modify
Risk Breakdown
Structure (RBS)
Use Recognized Tools
to Identify Risks
RiskIdentification
Draft Risk
Identification Section
of Risk Register
- Expand RBS as
Required for Project
- Brain Storming
- Interviews
- Ishikawa (fishbone)
Diagrams
- Other Tools
- Identify Actionable
Risks
- Identify Risk Event
Category from the
RBS
Continue
To Risk
Analysis

Risk Identification Approach
• Gather as much relevant data as possible
• Schedule a risk management meeting with the key team members
• Use a structured approach to identifying risks, and be thorough
• FOCUS ONLY ON IDENTIFYING RISKS

Risk Identification Approaches
Who?
• Project team members
• Vendors/subs/suppliers
• Customers
• Senior Management
• Subject Matter Experts (SME)
Tools
• Risk Breakdown Structure (RBS)
• Checklists (Risk Taxonomy, Lessons Learned)
• Questionnaires (Risk Taxonomy)
• Strengths, Weaknesses, Opportunities & Threats (SWOT) Analysis
• Scenario analysis (Walk through Program scenarios)
• Evaluating Proposal and Project plans for key assumptions, uncertainties, drivers
• Design and project reviews, test results, problem reports
Techniques
• Interviews
• Brainstorm sessions – multi-disciplinary team
• Written questionnaires
• Delphi technique (anonymous questionnaire) – multi-disciplinary experts
• At every formal and informal meeting
• Project Manager
• Lead Project Engineer
• End Users
• Other PM
• Other Stakeholders
Everybody!!!

Risk Breakdown Structure (RBS)
Each business or value stream should have an RBS / Risk Taxonomy
that reflects common risks encountered.
The RBS is part of the Risk Management procedure
Default Risk Breakdown Structure
Category Sub-Category Category Sub-Category
Project
Management
Personnel Capacity Development Development Process Maturity
Personnel Skills and Experience Technical Decision-making Process
Resource Monitoring & Management System Integration and Testing
Facility Capability/Constraints Configuration Control/Traceability
Program Financials Analysis Capability and Tools
Project Integration & Communication Supply Chain Dependency on Sole Sources
Requirements Flowdown & Execution Exotic Materials & Processes
Risk Management Maturity Hardware Delivery Performances
Schedule Flexibility Forecast Lead times
Work Environment Pricing
Multi-SBU/Site Complexity Manufacturing Manufacturing Capacity
Leadership Decision-making Process / Operations Process Capability
Roles & Responsibilities Clarity Equipment Suitability and Reliability
Technical / Design Interfaces Special Processes Capability
Design Technology Maturity Contract Dependencies on Outside Contractors
Design Testability Contractual Restrictions
Requirements Feasibility Export Licensing Requirements
Performance Margins Long Term Agreements
Software Constraints Customer Requirements Completeness
Software Performance/Capability Requirements Clarity
Design Capability/Capacity Requirements Stability
Design Complexity Customer Skill and Experience
Reliability and Maintainability Safety Requirements
Relationships and Politics

Leading Investigators Through
Risk Areas Using RBS
Project
Technical External Organizational Project
Management
Requirements Subcontractors Project
Dependencies
Estimating
Technology
Complexity &
Interfaces
Performances
& Reliability
Quality
Regulatory
Market
Customer
Weather
Resources
Funding
Prioritization
Planning
Controlling
Communication
- PMBOK® Guide, 4th Edition

Risks are categorized by:
• Class
• Element
• Attribute
B. Development Environment
1. Development Process
a. Formality
b. Suitability
c. Process Control
d. Familiarity
e. Product Control
2. Development System
a. Capacity
b. Suitability
c. Usability
d. Familiarity
e. Reliability
f. SystemSupport
g. Deliverability
3. Management Process
a. Planning
b. Project Organization
c. Management Experience
d. ProgramInterfaces
4. Management Methods
a. Monitoring
b. Personnel Management
c. Quality Assurance
d. Configuration Management
5. Work Environment
a. Quality Attitude
b. Cooperation
c. Communication
d. Morale
A. Product Engineering
1. Requirements
a. Stability
b. Completeness
c. Clarity
d. Validity
e. Feasibility
f. Precedent
g. Scale
2. Design
a. Functionality
b. Difficulty
c. Interfaces
d. Performance
e. Testability
f. Hardware
g. Non-Developmental Software
3. Code and Unit Test
a. Feasibility
b. Testing
c. Coding/Implementation
4. Integration and Test
a. Environment
b. Product
c. System
5. Engineering Specialties
a. Maintainability
b. Reliability
c. Safety
d. Security
e. Human Factors
f. Specifications
C. Program Constraints
1. Resources
a. Schedule
b. Staff
c. Budget
d. Facilities
2. Contract
a. Type of Contract
b. Restrictions
c. Dependencies
3. ProgramInterfaces
a. Customer
b. Associate Contractors
c. Subcontractors
d. Prime Contractor
e. Corporate Management
f. Vendors
g. Politics
Leading Investigators Through Risk Areas

Risk Identification - Keys to Success
Identifying “all” risks candidates, avoid limiting the list
• Large number of risks does not necessarily indicate a high risk program
Establishing an open atmosphere for communication
• “Open” means not dismissed w/o an explanation, no retribution for surfacing
concerns
Ensuring a wide perspective
• All aspects of the program and all stakeholders involved
Sufficient risk identification documentation to support the analysis step
• Clear statement of risk, context, and source
• “If … Then …” structure helps clarify the two components of risk
Not a one time process
• Update during proposal, on award, major reviews (SRR, PDR, CDR)
• Update periodically (quarterly recommended)
• Updates as new risks surface during daily standup meetings

Risk Register:
Identification
Phase
1) Risk Identification: 3) Risk Response Planning: Current Date:
Total Cost of
Effects:
TOTAL RISK: 0 $0 RISK AFTER: 0 $0 0
RiskItem#
Entry Date
Risk
Category
Cause
(If this happens…)
Effect
(Then this may happen…)
Probability
(1-5)
Impact
(1-5)
RiskScore
(1-25)
RiskEffect
Estimated
Cost$
Risk Owner Response Type Risk Response(s)
ProjectCross
Ref.#
Due
Date
Response
Status
Estimated
Probability
After(1-5)
Estimated
ImpactAfter
(1-5)
Estimated
RiskScore
After(1-25)
Response
Cost$
Current
Risk Score
Response
Plan
StartDate
1.0 11-Jan-08
Technical/
Design
Risk cause number 1 Risk effect number 1
2.0 11-Jan-08 Project Mgmt Risk cause number 2 Risk effect number 2
3.0 11-Jan-08 Development Risk cause number 3 Risk effect number 3
5.1 12-Mar-08 Supply Chain Risk cause number 5 Risk effect number 5
5.2
6.0 12-Mar-08
Mfg/
Operations
8.1 19-Mar-08
Technical/
Design
8.2
8.3
Risk
Forecasti
ng:
Current
Risk
Score:
Total Cost of
Responses:
1-Apr-08
Sort by
Risk Item #
Sort by
Risk Score
Sort by
Current Risk Score
Sort by
Risk Owner
1) Risk Identification:
RiskItem#
Entry
Date
Risk
Category
Cause
Effect
(Then this may
happen…)
1.0 11-Jan-08
Technical/
Design
Risk cause 1 Risk cause 1
2.0 11-Jan-08 Project Mgmt Risk cause 2 Risk cause 2
3.0 11-Jan-08 Development Risk cause 3 Risk cause 3
4.0 11-Jan-08 Development Risk cause 4 Risk cause 4
5.0 12-Mar-08 Supply Chain Risk cause 5 Risk cause 5
6.0 12-Mar-08
Mfg/
Operations
7.0 19-Mar-08 Supply Chain Risk cause 7 Risk cause 7
8.0 19-Mar-08
Technical/
Design
Sort by
Risk Item #

Recommended Method for Risk Identification
Brainstorm project risks individually
• Write one risk per stickie
• Use the RBS, Impact Matrix, documentation
as a prompt for developing risks
• Set a time limit (usually 15 min.)
As a group
• Facilitator reads each risk for everyone’s
understanding, then posts to the wall
• Any similar risks are identified and posted
together
• Team groups common risks and names
groups
• If needed, use the RBS categories for
groupings

Risk Analysis
• Analyzing risks for both probability and impact
• Developing a risk profile for your project
• Prioritizing which risks get your attention first
Agree to Ranking
Criteria for Impact &
Probability
Determine Risk Impact
& Probability for each
Risk
RiskAnalysis
Rank the Risks
Continue
To Risk
Response
- Use examples to
determine project-specific
ranking criteria
- Input Probability and
Impact Values in Risk
Assessment Tool
- Prioritize Risks
using sorting macros
in preparation for Risk
Response to the high
priority items
- Define Quantitative
Method and Scale
Factors for Probability
/ Impact Values
- Define Estimated Cost
of the Risk Impact

When Is Analysis and Prioritization Performed?
At the beginning of the project
When:
– A new risk is identified
– An existing risk changes
– Influential factors change
– New information surfaces
– The customer proposes a change
– Market conditions change
– Significant personnel leave the
project

Qualitative Approach
• Uses subjective values like high, medium, and low or other
combinations
• Requires common understanding of preferred ranking system
Impact (Select the column that the risk impacts the most):
Probability
5
High
> 50%
5
High
3
Med.
10% to 50%
3
Med.
1
Low
< 10%
1
Low
Risk may have a
negligible impact on
schedule.
Risk may have
negligible impact on
project budget.
Risk will not impact on any Customer
Specification compliance.
Scope
Risk may result in a shortfall in
operational performance that will NOT
be accepted by Customer.
Risk may impact
project NRC budget
in the order of 10%.
Risk may impact
project NRC
budget in the order
of 2%.
Risk may result in a Customer
Specification non compliance, but
overall operational performance will be
accepted by Customer.
Schedule
Risk may prevent “On
Time Delivery” of Key
Customer Milestones.
Risk may incur
schedule slippage, but
within Customer
Milestones.
Cost
Qualitative Risk Analysis – prioritizing risks for subsequent further
analysis or action by assessing and combining their probability of
occurrence and impact.
PMBOK® Guide, 4th Edition, Chapter 11

The Infamous 5x5 Criteria
Standard criteria should be part of the business risk management procedure
Probability
5 Very Likely >75% Chance
4 51-75% Chance
3 26-50% Chance
2 10-25% Chance
1 Unlikely <10% Chance
Impact
5 Severe Impact - Redesign Major Components, > 2 Mon. Slip
4 Some Impact - Redesign Minor Components, 1-2 Mon. Slip
3 Some Impact - Min. redesign, 2-4 Wk. Slip
2 Some Impact - Min. redesign, 0-2 Wk. Slip
1 Minimal - No redesign or Schedule Impact
Risk Score:
4 5
Probability
Impact
1
1 2 3
5
4
3
2
2 3
6
5 10
4 51
8 12 16
6 9
4
3
2
20
15
10
12
4
15 20
8
25

Combined Visual Examples
5 3
4
6
1,2
Probability
Impact
1 2 3 4 5
1
2
3
4
5
5x5 Example3x3 Example
Low (1) Impact Medium (3) Impact High (5) Impact
High (5)
Probability
Cluttered approver mailboxes for specs
not requiring their review and approval.
Stakeholder cannot complete task Project team over-extended
Specs continue to be created without
obsoleting old spec.
Specs not built to Business Rules (e.g.
BOS, etc.)
Non-Spec documents (records such as
validation/ stability docs) not migrated
from NADCS to GSS.
Incomplete, inaccurate or lack of
communication of spec changes with
outside suppliers/vendors.
Medium (3)
Probability
Training methodology is ineffective. Maintaining updated Approval Matrix. Bad data integrity
Users not available to attend training
classes.
Keeping status of BOS intact to BOM in
SAP.
Resistance to new "Roles" e.g. TA
approves component specs.
GSS out of sync with organizational
model.
Approval matrix behavior is not as
expected.
Plant operators cannot use system
Trainers availability Users cannot access system
Extremely slow response time - network
bandwidth
Not delivering on ROI.
Specs not built to Business Rules (e.g.
BOS, etc.)
Low (1)
Probability
Mark up not working. Insufficient manpower to support user
community
Users cannot create new spec revisions
Records/documentation for test scripts,
execution, validation are in place.
BOS not functioning properly. Defective Workflow
Compare not working No executive support for additional
resources.
On-going cost exceeds expectations
System hangs Funding not available or exhausted
Network failure
Cannot use reference docs Software failure - system inaccessible
Unable to restore from backup
File collaboration server - inaccurate
replication and functionality
Forgot critical major user requirements
Use combined matrices as a visual communication and record of project risks

Risk Level Definition and Required Action
High Risk Medium Risk Low Risk
A risk that may have a
significant impact (or even the
possibility of failure) on the
project's performance, cost, or
schedule objectives or
customer satisfaction. The
probability of occurrence and
the consequence of
occurrence is so high that
rigorous control of all risk
sources is needed.
A risk that could affect project
objectives, cost, schedules, or
customer satisfaction. The
combination of likelihood and
consequence of occurrence
requires close control of all
contributing risk sources,
development of a handling
plan, establishment of risk
milestones, and possibly
secondary plans.
A risk that may have a minor
effect or consequence on
project objectives. The
probability and consequence of
occurrence are sufficiently low
so as to cause little concern.
Requires: control and
monitoring of each risk source,
a detailed handling/mitigation
plan, secondary plans, and
aggressive risk monitoring.
Requires: similar attention as
high risks at RMB discretion.
Requires: no special project
emphasis other than normal
design group monitoring and
control. These risks are
monitored to detect a potential
increase in risk level (i.e.,
added to a risk watch list).

Risk Analysis Caution Areas
• Risks can interact in unanticipated ways
• A single risk can cause multiple effects
• Opportunities for one may be a threat to another
• Mathematical tools can create a false impression of precision and
reliability

Results of Risk Analysis and Prioritization
Determination of Probability and Impact leading to prioritization by
Risk Number (P x I)
Root Cause of risk
• Potentially leading to restatement of risk
• Why … Why … Why … Why … Why …
• Fishbone and/or pareto analysis
• Other problem solving techniques (Six Sigma, 8D, etc.)
Cost to the program should the high risk become a problem
Recommended triggers to initiate corrective action
• When measure exceeds a specified value
• When specific test fails or is marginal
• Customer/Supplier feedback
• ? …

Risk Register: Analysis Phase
1) Risk Identification:
Total Cost
of Effects:
TOTAL RISK: 104 $21,500
RiskItem#
Entry
Date
Risk
Category
Cause
Effect
(Then this may
happen…)
Probability
(1-5)
Impact
(1-5)
RiskScore
(1-25)
RiskEffect
Estimated
Cost$
1.0 11-Jan-08
Technical/
Design
Risk cause 1 Risk cause 1 1 3 3
2.0 11-Jan-08 Project Mgmt Risk cause 2 Risk cause 2 5 3 15 $1,500
3.0 11-Jan-08 Development Risk cause 3 Risk cause 3 3 4 12 $20,000
4.0 11-Jan-08 Development Risk cause 4 Risk cause 4 5 5 25
5.0 12-Mar-08 Supply Chain Risk cause 5 Risk cause 5 4 5 20
6.0 12-Mar-08
Mfg/
Operations
7.0 19-Mar-08 Supply Chain Risk cause 7 Risk cause 7 2 3 6
8.0 19-Mar-08
Technical/
Design
0
0
2) Risk Analysis:
Sort by
Risk Item #
Sort by
Risk Score
Total Cost of
Effects:
TOTAL RISK: 0 $0 RISK AFTER: 0 $0 0
RiskItem#
Entry Date
Risk
Category
Cause
Effect
Probability
(1-5)
Impact
(1-5)
RiskScore
(1-25)
RiskEffect
Estimated
Cost$
Risk Owner Response Type Risk Response(s)
ProjectCross
Ref.#
Due
Date
Response
Status
Estimated
Probability
After(1-5)
Estimated
ImpactAfter
(1-5)
Estimated
RiskScore
After(1-25)
Response
Cost$
Current
Risk Score
Response
Plan
StartDate
1.0 11-Jan-08
Technical/
Design
2.0 11-Jan-08 Project Mgmt Risk cause number 2 Risk effect number 2
5.2
6.0 12-Mar-08
Mfg/
Operations
8.1 19-Mar-08
Technical/
Design
8.2
8.3
Risk
Forecasti
ng:
Current
Risk
Score:
Total Cost of
Responses:
1-Apr-08
Sort by
Risk Item #
Sort by
Risk Score
Sort by
Current Risk Score
Sort by
Risk Owner

Risk Response Planning
• The process of developing options and determining actions to
enhance opportunities and reduce threats to the project’s objectives
• The effectiveness of response planning will directly determine whether
risk increases or decreases for the project
Define Risk
Response Strategy
Establish Action & Due
Date for Each Risk
RiskResponse
Assign Owner to
Each Risk
Evaluate Response
Effectiveness
(Projected Risk Score)
Continue
To Risk
Monitor
- Define Appropriate
Response Approach
to manage the Risk
- Accept
- Avoid / Exploit
- Mitigate / Enhance
- Transfer / Share
- Contingency
- Define Measurable
Response Action
- Define Contingency
Action & Trigger
(as required)
- Establish Method to
to Integrate Response
Actions into the Project
- Project Plan
- Action Item List
- Response List
- Input Projected
Probability and
Impact Values
- Define Estimated
Cost of the Risk
Response
- Define Risk Response
Start Date (forecasting)

Strategies for Negative Risks or Threats
• Avoid: Eliminating the risk, usually by eliminating the cause
– Using a more stable technology
– Using a less complicated or less sophisticated programming language
– Using a list of exclusions
• Mitigate: Managing the risk by trying to reduce the probability and / or
impact of an event to an acceptable threshold
• Transfer: Shifting the negative impact of the event to a third party
– Purchasing insurance, performance bonds, warranties
– Contracts
– Hiring subcontractors

Example Mitigation Approaches
• Personnel Short falls
– Career Development
– Team building
– Cross-training
– Hiring, consultants, subs
– Overtime
• Unrealistic Schedules and Budgets
– Multi-source cost & schedule
estimation
– Design to cost
– Incremental development
– Requirements scrubbing
– Outside reviews
– Remove from critical path
• Shortfall in purchased components
– New vendor, 2nd source
– Inspections
– Reference checking
– Compatibility analysis
• Developing the Wrong user Interface
– Parallel development
– Scenarios
– User Characterization (e.g. functionality,
style, workload, level)
• Real-Time Performance Short falls
– Parallel development
– Simulation Prototyping
– Benchmarks, Modeling, Simulations
• Continuing Requirements Changes
– High change threshold
– Set change milestone
– Enhance visibility to impact of changes
– Staged/incremental development (defer
changes)
– Additional Voice of the Customer session
• Straining laws of physics
– Technical analysis
– Cost-benefit analysis
– Prototyping

Strategies for Positive Risks or Opportunities
• Exploit: Eliminates the uncertainty associated with an
upside risk by ensuring the opportunity will happen
• Enhance: Increases probability of positive impacts; identifies and
maximizes key drivers of the positive impacts
• Share: Allocates ownership to a third party who can better capture
the opportunity for the benefit of the project

Strategies for Both Threats and Opportunities
• Acceptance: Used when the team decides not to change
the project management plan to deal with risk or when the
team cannot identify a suitable strategy
• Contingent: A response plan that will be used only if certain events
occur
– Events that trigger the contingency response should be defined and tracked
PassiveActive

Contingency Plans vs. Project Reserves
Contingency plans involve the
development of alternative
courses of actions, which may
include:
• Schedule changes
• Resource changes
• Contract clauses
Project reserves take the form of
money or time targeted at specific
areas of the project and are
sometimes called:
• Management
• Budget
• Schedule

Risk Register – Response Phase
1) Risk Identification: 3) Risk Response Planning: Date:
Total Cost
of Effects:
RiskItem#
Entry
Date
Risk
Category
Cause
(If this
happens…)
Effect
(Then this
may
happen…)
Probability
(1-5)
Impact
(1-5)
RiskScore
(1-25)
RiskEffect
Estimated
Cost$
Risk Owner
Response
ProjectCross
Ref.#
Due
Date
Response
Status
Estimated
Probability
After(1-5)
Estimated
ImpactAfter
(1-5)
Estimated
RiskScore
After(1-25)
Response
Cost$
Current
Risk
Score
Response
Plan
StartDate
1.0 11-Jan-08
Technical/
Design
Risk cause 1 Risk cause 1 1 3 3 Jack White Accept 0 1 3 3 3
2.0 11-Jan-08 Project Mgmt Risk cause 2 Risk cause 2 5 3 15 $1,500 Mary Jane Contingency Risk Response 2.0 21 1-Jun-08 1 2 1 2 $500 11.75 1-Mar-08
3.0 11-Jan-08 Development Risk cause 3 Risk cause 3 3 4 12 $20,000 Joe Dude Mitigate Risk Response 3.0 34 20-Apr-08 3 3 1 3 $12,000 5.25
4.0 11-Jan-08 Development Risk cause 4 Risk cause 4 5 5 25 Sally Bobaly Avoid Risk Response 4.0 35 25-Jul-08 0 2 3 6 25 1-Apr-08
5.1 12-Mar-08 Supply Chain Risk cause 5 Risk cause 5 4 5 20 John Johnson Mitigate Risk Response 5.1 37 1-Aug-08 2 2 2 4 12
6.0 12-Mar-08
Mfg/
Operations
Risk cause 6 Risk cause 6 2 4 8 Julie Bobuly Transfer Risk Response 6.0 42 1-Jun-08 3 2 2 4 5
7.0 19-Mar-08 Supply Chain Risk cause 7 Risk cause 7 2 3 6 John Johnson Accept 0 2 3 6 6
8.1 19-Mar-08
Technical/
Design
Risk cause 8 Risk cause 8 3 5 15 Jack White Mitigate Risk Response 8.1 23 15-Sep-08 0 3 1 3 15 1-Apr-08
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
Risk
Foreca
sting:
Current
Risk
Score:
Total Cost
of
Responses:
1-Apr-08
Sort by
Risk Item #
Sort by
Risk
Score
Sort by
Current Risk Score
Sort by
Risk
Owner

Update the Appropriate Documents
• Project management plan (updates)
• Risk-related contracts
• WBS: Add appropriate work packages that reflect the risk response
strategies
• Budget: Add risk funding to the appropriate work packages
• Deliverables map/LWWPP: Add time to the appropriate work
packages
• Resources: Add resources as needed to the appropriate work
packages

Flow of STRIDE Tools in Executing
and Monitoring and Control Processes
Inputs:
• Actions to resolve higher
fidelity requirements and
increased confidence of
compliance
• LWWPP with active risk
mgmt. built in
• Risk Mitigation and
Contingency Plans
Project Team
Daily Stand-up Meetings
Regular Risk Reviews
-100
0
100
200
300
400
500
Jan Feb Mar Apr May Jun Jul Aug Sep
RN
TOTAL EXPOSURE
CURRENT EXPOSURE
MONTHLYCHANGE
0
2
4
6
8
10
12
Jan Feb Mar Apr May Jun Jul Aug Sep
LOW
MEDIUM
HIGH
Outputs:
• Execution to Plan
• Real-time Problem
Identification &
Countermeasure
Assignment
Outputs:
• Risk Mitigation to Plan
• New Risk Identification &
Response Planning
Improved
Scope, Cost &
Schedule Control
You are
Here

Risk Monitor and Control
The process of:
• Identifying, analyzing, and planning for newly arising risks
• Tracking the identified risks and those on the watch list
• Reanalyzing existing risk
• Monitoring triggers to activate contingency plans
• Monitoring residual risks
• Reviewing the execution of risk responses while evaluating their effectiveness
Execute Response
Plans
Monitor Risk
Responses
(periodically)
RiskMonitor/Control
Report Risk Status
(periodically)
Return
To Risk
Identification
- Manage Completion
of Response Actions
- Record Completed
Response Actions
(risk score achieved)
- Review Visual Controls
- Current Risk Score
- Number of Risks
- Evaluate and Report
Risk Management
Results
- Record % Complete
(risk score achieved)
- Projected Time Based
Risk Score
(forecasting)

Identifying Triggers for Each Risk Event
What is a risk trigger? A risk trigger is an early
warning sign that the risk event may occur:
• Identify potential triggers that would indicate the occurrence of a
risk event
• Ensure that these triggers are visible to the project team
• Monitor triggers frequently

Incorporating Risk Reviews
• Build risk reviews into the LWWPP
• Establish a window of time to monitor the project
• Review schedule, budget, and change control log for potential risks
• Review risk plan after each risk occurrence
• Reassess probabilities and impact for each risk event
• Make risk management part of status meetings, ideally including daily
stand-up meetings

Outcome from Risk Monitoring and Control
• Corrective and preventive actions
• Updates to risk management plan
• Updates to budget, including reserve and contingency
• Updates to schedule
• Impact matrix closed out; going forward use the risk management tool
• Risk Event Lessons Learned

Best Practice: Risk Management Tool
• Monitors action closure status using Lean symbols
• Adjusts CURRENT risk score as a result of the action taken
• Forecasts reduction in risk score based on completion status, start and
finish dates for the risk response(s)
Total Cost
of Effects:
RiskItem#
Entry
Date
Risk
Category
Cause
Effect
Probability
(1-5)
Impact
(1-5)
RiskScore
(1-25)
RiskEffect
Estimated
Cost$
Risk Owner
Response
ProjectCross
Ref.#
Due
Date
Response
Status
Estimated
Probability
After(1-5)
Estimated
ImpactAfter
(1-5)
Estimated
RiskScore
After(1-25)
Response
Cost$
Current
Risk
Score
Response
Plan
StartDate
4.0 11-Jan-08 Development Risk cause number 4 Risk effect number 4 5 5 25 Sally Bobaly Avoid Risk Response 4.0 35 25-Jul-08 0 2 3 6 25 1-Apr-08
5.1 12-Mar-08 Supply Chain Risk cause number 5 Risk effect number 5 4 5 20 John Johnson Mitigate Risk Response 5.1 37 1-Aug-08 2 2 2 4 12
2.0 11-Jan-08 Project Mgmt Risk cause number 2 Risk effect number 2 5 3 15 $1,500 Mary Jane Contingency Risk Response 2.0 21 1-Jun-08 1 2 1 2 $500 11.75 1-Mar-08
8.1 19-Mar-08
Technical/
Design
Risk cause number 8 Risk effect number 8 3 5 15 Jack White Mitigate Risk Response 8.1 23 15-Sep-08 0 3 1 3 15 1-Apr-08
3.0 11-Jan-08 Development Risk cause number 3 Risk effect number 3 3 4 12 $20,000 Joe Dude Mitigate Risk Response 3.0 34 20-Apr-08 3 3 1 3 $12,000 5.25
6.0 12-Mar-08
Mfg/
Operations
Risk cause number 6 Risk effect number 6 2 4 8 Julie Bobuly Transfer Risk Response 6.0 42 1-Jun-08 3 2 2 4 5
7.0 19-Mar-08 Supply Chain Risk cause number 7 Risk effect number 7 2 3 6 John Johnson Accept 0 2 3 6 6
1.0 11-Jan-08
Technical/
Design
Risk cause number 1 Risk effect number 1 1 3 3 Jack White Accept 0 1 3 3 3
0 0 0 0
0 0 0 0
Risk
Forecastin
g:
Current
Risk
Score:
Total Cost of
Responses:
1-Apr-08
Sort by
Risk Item #
Sort by
Risk Score
Sort by
Current Risk Score
Sort by
Risk Owner

STRIDE Risk Management
Monitoring and Control
Risk Tool provides visual controls for historical risk and risk reduction
forecast:
Forecast in Total Risk Reduction
0
20
40
60
80
100
120
Total
Risk
Apr-08 May-08 Jun-08 Jul-08 Aug-08 Sep-08 Oct-08 Nov-08 Dec-08
RiskNumber
Low
Medium
High
Forecast in # Risk by Category
0
1
2
3
4
5
6
7
8
9
Total
Risk
Apr-
08
May-
08
Jun-
08
Jul-08 Aug-
08
Sep-
08
Oct-
08
Nov-
08
Dec-
08
Jan-
09
Feb-
09
NumberofRisks
Low
Medium
High
Historical Change in Total Risk
0
20
40
60
80
100
120
Jan-08 Feb-08 Mar-08 Apr-08
RiskNumber
Low
Medium
High
Historical Change in # Risks by Category
0
1
2
3
4
5
6
7
8
9
Jan-08 Feb-08 Mar-08 Apr-08
NumberofRisks
Low
Medium
High
• By Overall
Risk
Score:
• By Risk
Category:
Low,
Medium, &
High

Foundations of Project Success
Scope and Requirements
Schedule
Project Success
Quality
Cost
Integrity and Safety

STRIDE Standard Process for RISK

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie STRIDE Standard Process for RISK

Ähnlich wie STRIDE Standard Process for RISK (20)

Mehr von Romains Bos, PMP, MBA

Mehr von Romains Bos, PMP, MBA (13)

STRIDE Standard Process for RISK