|
07.11
Application of Risk Management During Project Definition
By Paul Kostek
Why care about risk management? We all do risk
management whether we realize it or not. We make
decisions on insurance for ourselves and our
possessions, determining the amount we buy based
on the amount of risk we face. As part of
projects, we’ll do trade studies and pick the
solution with the best payoff for the least
risk. Today, more and more companies are looking
at enterprise-level risk. For most engineers,
the application of risk management will be at
the project level. In two of the most regulated
markets — aerospace and medical — the operating
authorities (FAA and FDA) are levying
requirements for the performance and
documentation of risk management, including
allocating risk down to the
subcontractor/supplier level.
At the project level, we want to
address risk at the beginning of the project to
ensure that our user needs/system requirements
address known/identified risks, determine the
appropriate system response to failure, and
limit the amount of rework on
requirements/design.
How do most of us start off a
new project? We look at material
(requirements/design) from previous projects
that might be applicable/reusable. We may have a
specification from the customer outlining their
needs, or a marketing needs document. We then
begin work on developing a set of user needs.
These needs must consider potential risks and
identify trade-offs/mitigations.
Following are steps involved in
a creating a risk management plan:
-
Identifying Risk — part of
user needs/system specification development.
Use lessons learned, requirements analysis,
risk checklists and brainstorming to
identify known or new risks.
-
Analyzing Risk – determine
likelihood of risk occurring and impact;
categorization of risk — technical, cost,
schedule, risk level — high, moderate, low.
As shown in Figure 1, items in
green are low risk, requiring no additional
analysis. Items identified as moderate risk
(yellow) need to be assessed to determine if any
mitigations are required that could move them
into the green (low-risk area). High-risk items
require assessment to determine what mitigations
can be done to lessen the risk and whether these
steps make financial/schedule/technical sense.
ALARP — As Low As Reasonably Possible comes into
play here. We don’t want to create mitigations
that result in the product being too costly or
difficult to field; with ALARP, a decision is
made to proceed after reasonable steps are taken
and documented.
Figure 1 Risk Assessment Process
(Source: FAA Air Traffic Organization – Capt
Bill Yantiss TASS 11/9/2009)
Assessing Risk
-
Avoidance – redefine plans,
requirements, technical approach
-
Transfer – move to
group/organization/supplier to address
-
Assume – accept risk based
on cost/benefit analysis
-
Mitigation – plans/actions
to reduce likelihood or lower consequence of
risk
Risk Mitigation – add
requirements to specification, change design,
usage. These need to be assessed and verified as
the design progresses.
After completing these stages, a
risk management plan (aka a safety risk
management plan) can be produced. This document
is then used as part of planned phased reviews
of the project. It should include any risk
management activities performed by suppliers.
This plan will serve as the guideline for
engineers and project management as the project
moves through the design cycle.
For example, in FDA-regulated
industries, international standard
IEC 60601-1 3rd edition provides
guidance and the requirements for the risk
management plan, including risk management work
undertaken by suppliers. This can be a challenge
because many smaller suppliers have not had to
deal with this requirement in the past and may
need guidance from the end user. Designers may
be required to provide direction, review and
approve the work done by suppliers. This should
be a clearly stated task within the supplier’s
SOW. Another useful resource for designers
working on the medical technology industry is
IS0 14971 Risk Management of Medical Devices
Ensuring Safety and Efficacy.
Track and Modify Risk
As the project moves through the
design phases, track the identified risks to
ensure all are addressed, modify if necessary
and identify any new risks that may emerge
during the design process. The initial tracking
should be done when the product requirements are
first reviewed. Tracking can be done with a
checklist or as part of the risk management
plan. New risks must be assessed to ensure that
they are valid before any changes are made.
Implementing a risk management
plan at the beginning of a project can help to
remove some of the possible problems that can
appear during the project’s lifecycle. There is
no guarantee that all problems will be
identified early or avoided, but reviewing
lessons learned and previous problems can limit
the number of requirement and design changes.
All this is essential in a marketplace where
time to market is critical, and for regulated
industries where demonstrating that risk was
considered early on, documented and assessed
throughout the design process.
In addition to internal
standards for Risk Management activities, good
resources include the
INCOSE Systems Engineering Handbook (v 3.2)
and the
Project Management Institute’s PMBOK
(Project Management Book of Knowledge).
Successfully managing risk is a
joint effort of management and engineering, and
requires a commitment to identifying, managing
and mitigating risk. Remember that the objective
of risk management is to balance the allocation
of resources in such a way that the minimum
amount of resources achieves the greatest risk
mitigation benefits.
Paul Kostek is a Principal of
Air Direct Solutions a systems
engineering/project management firm in Seattle,
Washington. He works with companies in the
aerospace, avionics and medical device
industries. Paul was President of IEEE-USA in
1999, President of the Aerospace and Electronics
Systems Society 2000-01, Chaired the IEEE
Intelligent Transportation Systems Conference in
2004 and the AIAA/IEEE Digital Avionics Systems
Conference in 2006. He is the Chair of the 2011
IEEE Global Humanitarian Technology Conference.
Comments may be submitted to
todaysengineer@ieee.org.
|
Comments
on this story may be
sent directly to