|
Page 1 of 22
Risk Management for Organizations: Keeping the Ship Afloat
The concept of risk management is one that has to encompass the whole of your
program, from the first day of planning a new activity through the last piece
of gear that is put away when the trip is over.
An introduction and discussion on Risk Management together with recommendations
for its implementation. Prepared by Chester Simmons.
CONTENTS
* 1. Introduction
* 1.1 Risk Definition
* 1.2 Risk Management Definition
* 2. Background
* 2.1 Policy
* 2.2 Practices
* 3. Risk Concepts
* 3.1 First Principles
* 3.2 Ownership
* 3.3 Types of Risks
* 3.4 Development Risks
* 4. Risk Management Structure
* 4.1 Functions, Phases and Timing
* 5. Risk Management Tools
* 5.1 WBS
* 5.2 SOW
* 5.3 Proposal
* 5.4 Make-or-Buy
* 5.5 Risk Ranking
* 5.6 Software Tools (some recommendations)
* 5.7 Development Test (how to design)
* 5.8 Engineering Analysis (how to integrate with test)
* 6. The Human Element
* 7. References & Background Documents
* Appendices
1. Introduction
The management of risks is a central issue in the planning and management of
any venture, but it is also something of an orphan within the acquisition establishment
(at least in the U.S.). Risk management has not historically been a "branch
activity" as noted in a bygone version of the Defense Systems Management
College's System Engineering Handbook. (Reference 1 is the latest version of
the guide.) "Branch" in this context refers, of course, to an organizational
element within the engineering-development organizations common two or three
decades or so ago that was probably derived from "branch of service"
designations. The connotation being that there were not proponents per se for
risk management as there were for reliability, safety, systems, electrical,
PP&C, propulsion, human factors, guidance, C3I, etc. The situation is still
somewhat loosely defined.
The purpose here is to provide information for use in risk management by any
and all stakeholders. The objective is not to foster risk management as an identifiable
and separate specialty.
The prescriptive portions of the discussions are cast from the perspective
of a contractor performing an effort for some customer, typically an agency
of government. The emphasis is on cross-specialty, cross-discipline, cross-functional
and cross-technology development programs since such programs maximize risk
opportunities and occurrences. In terms of program phases, the discussions are
intended for a program in the pre-proposal, proposal or start-up phases. The
reason for this timing is that risk management should be proactive, and activities
later than these phases is hardly proactive in terms of avoiding risks.
The underlying themes for what follows are:
* management must know its job
* risks are dominantly engendered by organizations attempting ventures with
elements that push the envelopes of their experience (and capabilities)
* risks are usually well known within an organization
* ownership of risks is a central issue in risk management
* the traditional steps in risk management are actually useful (planning, identification,
analysis, management and tracking)
* the system engineering effort is the key program ingredient for a risk management
program to work.
The discussions in this note are based on the assumption that the programs
under consideration involve significant development activities. That is, the
software, hardware, operational concepts, etc. or combinations of these aspects
do not exist at the start of the program, and the development of these aspects
is accomplished to some specification in some allocated set of time and monetary
constraints.
|
