Introducción

Searching the language for risk management fundamentals

Tom Stokes    
Solvera - USA

Presentation abstract

Risk Avoidance and Consequence Mitigation
Looking to Language for Fundamentals
The “risk” in this example was a failure in the baggage system software. A
consequence of this risk was the inability to move baggage with the automated cars.
There are many ways the risk could have been avoided, but if the construction crew had
mitigated the consequence with tunnels large enough to use manned trains the airport
might have opened on time.
Viewed from the perspective of requirements management, the mitigation would have
been a traceable source for the tunnel size requirement. Building the tunnels large
enough for manned cars would cost more, but this expense and forethought would have
provided a contingency to handle this particular consequence.
To “take the risk” is to choose not to avoid the event. To “suffer the consequences” is to
choose not spend resources on mitigation actions.
After the risk occurs, mitigation is impossible, of course. And if the risk never occurs,
the money spent mitigating the consequences is wasted.
In the presentation, an example layout is shown for relating risks, avoidance actions,
consequences and mitigation actions. The risk management section of a typical project
plan is already burden enough for many Project Managers. And the thought of adding a
“consequence layer” does not immediately seem to help the problem. But by
considering the impact of each risk as a set of individual consequences, many of which
will be mitigated by specific product requirements, the Project Manager can begin to see
the usefulness of risk and consequence management as it relates to requirements
management and contingency planning.
A cost model is also presented to help the mitigation decision for each consequence. In
this model, the cost of mitigated recovery is compared to the cost of un-mitigated
recovery multiplied by the probability of the risk event.
Many words in our industry have specific meanings, but tend to be used
interchangeably, for example:
- Version and Revision
- Testing and Quality Assurance (QA)
- Verification and Validation
- Requirement and Constraint
The intent of this presentation is to make a distinction between risks, consequences,
avoidance and mitigation to help clarify a much-discussed, but little-understood part of every project.

Speakers information

Tom Stokes has over 25 years of experience in all phases of electronic system design across
several industries. With a BS in Electrical Engineering, he started with defense industry
board design and assembly language embedded software. He worked more than ten years
for Philips Electronics as Test Technology Manager, Quality Manager and Project Manager
on systems ranging from video broadcast systems to semiconductors. More recently, Tom has
served as Project Manager for USAirways and is currently involved with integration and platform
testing for General Dynamics C4 Systems in Scottsdale, Arizona, USA. Tom's leading philosophy is to focus on people and ideas, not computer tools.

volver