1.2 Risk Management Definition

* proactive
* management
* accommodate
* acceptably
* professional
* possibility

It is possibilities that are being accommodated. It is management's job to do the planning that will accommodate the possibilities. The customer is the final judge, but internal goals should be to a higher level than customer expectations.

Risk management as a shared or centralized activity must accomplish the following tasks:

* Identity concerns
* Identify risks & risk owners
* Evaluate the risks as to likelihood and consequences
* Assess the options for accommodating the risks
* Prioritize the risk management efforts
* Develop risk management plans
* Authorize the implementation of the risk management plans
* Track the risk management efforts and manage accordingly

The highlighted activities are those that must be reserved for management's attention and action in those cases for which a risk management staff/secretariat are employed. This list exclusive of the management functions is consistent with the list espoused for years by the Defense Systems Management College (DSMC): risk planning, risk assessment, risk analysis and risk handling. The managerial functions are highlighted to once again emphasize that management is responsible and accountable for risk management.

1.2.1 Identify Concerns & Identify Risks
A concern to be evaluated as a potential risk is literally any issue about which a doubt exists in some context. Later a procedure will be recommended for accomplishing the review of concerns and identifying those that actually engender risks. Some differentiation is needed because difficult things often get confused with risky things. Also, some people use the risk tag to justify additional funding when, in fact, no risk exists.

Since risks will not be arbitrarily dropped as key management issues once they are identified, it is smart to spend the necessary time to identify concerns and then to assess the existence of the risks. Of course, risks identified by the customer in the RFP or some other formal fashion are automatically risks for the program.

There is also a need for differentiating between identifying concerns and identifying risks to reflect the fact that in a contracting organization the Program Manager is responsible for all risks for the contract, and it is his exclusive right to formally declare that an issue is or is not a risk. (Common sense indicates that the PM had better listen to his subordinates, but the responsibility is still his.)

Within the performing organization it is necessary for the PM to allocate responsibility for resolving risks to the appropriate function, specialty or discipline. Also, some individual needs to be tagged as the organizational focus for actions for each risk. The ownership of risks is essentially an allocation process tailored to the organization doing the job. Some organizations may elect to keep risk ownership and leadership at relatively high levels (e.g., functional leads, department heads, etc.) whereas in other cases it might be appropriate to allocate the ownership as low as possible in the organization considering spans and scopes of control for appropriate resources.

A point to be made at this time is that risks are seldom deeply held secrets. Experience indicates that virtually all risks of consequence are more or less common knowledge. This point will be discussed again later, but it is worth noting that program-killing, lawsuit-engendering risks have been common knowledge on more than one doomed program!

1.2.2 Risk Manager
A risk manager is recommended if a program is large enough to afford one. The role for this position will be to capture and formalize risk management activities and results. This role includes being spokesperson for the program for risks for major reviews and reports. For example, at the SRR and SDR, it is invariably necessary to describe the common elements of the risk management program before specifics are discussed on a subsystem-by-subsystem basis otherwise there is much repetition in formats. The risk manager can lay out the whole approach, and later presentations can focus on details of specific elements of the system.

The risk manager's domain is essentially a secretariat-type function. It is not a shaker-mover position. The risk manager does not have direct responsibility for any risks per se. This position is somewhat analogous to that of program planning and control (those persons responsible for C/SCSC-driven activities, performance management reporting, etc.). The reality is less exalted that the title. Specific duties are discussed below.

Experience indicates that programs of $100M/year will require a risk staff of probably no more than 3 persons for early phases (through SDR) and only one person later, possibly augmented by one or two staffers at the time of major reviews. Smaller programs can use proportionally smaller staffs to the point of having some person designated as a part-time risk manager.

Experience also indicates that major programs also tend to be segmented into major subcontracts (or teaming relationships). For subcontracts appropriate to the scale of a $100M/year prime program, a one-person risk staff for each subcontractor is probably adequate with some help at major reviews. It is assumed that the prime and lower-tier companies work in concert in risk management if not in cooperation.

Note: It is a fashion in some circles to project a risk management role that is considerably enhanced in scope relative to what is recommended here. In effect, there is one risk owner, the risk manager. In theory such a position sounds nice, but in fact it is felt that such an approach will not be as effective as having the risk owners also be the owners of the expertise, the resources and the mission to do the job. A separate highly-empowered risk manager will just be a nuisance in most cases, and a program manager who abdicates his responsibilities for risk management to such a position is truly at risk (and probably not too bright).

Another prejudice about this super role is that today's systems are too complex for any one person to really understand at the level of professional competence. Remember the following as a hard and fast rule: Having an opinion is a far cry from understanding, but an opinion is closer to understanding than understanding is to professional competence, and professional competence is the starting point for solving difficulty problems. From this perspective, understanding is a relatively cheap commodity, but even understanding is almost impossible across the full span of today's systems. So, avoid the trap of an over-empowered risk management role if the system is at all complex.

The risk management role as recommended here is not as attractive as a direct design role, but it will have its moments.

1.2.3 Evaluate the Risks as to Consequences & Likelihoods
One of the more useful constructs of traditional risk management is that a risk as a possibility actually consists of a likelihood and of consequences. This definition is probably derived from the elementary mathematical concept of expectation of an event. Expectation for some event is defined as the product of its probability of occurrence and its value (in a generalized sense) if it occurs. Thus, a one-in-forty million lottery ticket for a prize of $20,000,000 has an expectation of fifty cents.

For risk management the situation is normally much more fuzzy than the simple lottery example, and there is usually very little precision in either the metric for the probability of occurrence or the metric for the consequences. Therefore, the possibility expressed as a combination of probability and consequences is usually subject to debate even if some of the pseudo-mathematical approaches are used (and some of these are recommended).

The recommendation here is to use whatever tools that are available and meaningful in a given situation (and, as noted, some are recommended below), but to not get hung up on mathematically appearing artifices that do not really have any more precision than an informed judgment. Again, avoid trying to untie a Gordian Knot, just cut the thing.

There may be situations in which effectiveness analyses, engineering analyses, bean counting of interfaces, etc. may be necessary, but these are sideline issues to the exercising of judgment about the risks.

Note: It is somewhat surprising that the cost and schedule aspects of risk consequences are not cast in terms of a C/SCSC perspective that provides an effective if not scientific tie between cost and schedule parameters.

1.2.4 Assess Options for Risk Management
Risk management options are usually cited as risk handling options subdivided as avoidance, control, assumption, risk transfer, and knowledge and research Generally, the assessment of management options is a hip shot since the necessary decisions must occur early in a program when things are still fuzzy. However, if experienced personnel are given the facts, one can expect very good decisions since there is seldom any real mystery about the practicality of options available. (The practicality of any option is usually just an issue of schedule and funding.)

Avoidance: Use an alternate approach that does not have the risk. This mode is not always an option. There are programs that deliberately involve high risks in the expectation of high gains. However, this is the most effective risk management technique if it can be applied.

Control: The DSMC Risk Management Guide (RMG) defines this mode as: "Controlling risks involves the development of a risk reduction plan and then tracking to the plan." The key aspect is the planning by experienced persons. The plan itself may involve parallel development programs, etc.

Assumption: Simply accepting the risk and proceeding. A word of caution: There appears to be a tendency within organizations to gradually let the assumption of a risk take on the aura of a controlled risk. This mental evolution is the kind of wrongly conditioned thinking that led to the Challenger failure.

Risk Transfer: An attempt to pass the risk to another program element. Typically, used in the context of a government agency passing the risks to a contractor.

There are some discussions in the DoD acquisition literature that this mode trades government risk for profit to the contractor. This belief is apparently founded on elementary economic theory and the mistaken belief that an executive in a procuring agency has avoided risks by passing the buck. What the executive will have done is, at best, a CYA exercise.

Knowledge & Research: The DSMC RMG cites this mode as not being "true" risk handling, but rather a technique for strengthening other techniques. From a program management perspective this approach can best be viewed as an adaptation of the approach used by graduate students for their theses: intensive study associated with specialized testing. In effect, the student develops intellectual ownership of his problem in all of its aspects: theoretical, empirical and practical.

Essentially, this mode is simply doing one's homework.

This mode is critical for testing. The DoD's Test, Analyze, and Fix (TAAF) has a nice ring, but it is valid only in a vary narrow context: testing of production and preproduction prototypes to remove bugs. However, TAAF has been mistakenly applied to earlier development phases. Failure to analyze prior to testing generally poses a risk that trends in the test data will not be understood or key test results will mistakenly be taken as inconsequential.

1.2.5 Prioritize the Risk Management Efforts
Once the risks have been evaluated in terms of likelihood of occurrence and consequences, and when options for risk management have been reviewed, it is then meaningful to rank the risks for the program manager to assign priorities. The task of prioritizing the risks is performed at the senior staff level to assure that all political, business and programmatic factors are weighted in the priority assessment. The purpose is to avoid the "successful operation, but the patient died" syndrome. The risk manager earns some of his pay at this point by sorting all of the mechanical aspects of the risks (ranks and risk management options) and presenting them to the senior management as a package.

Note: The recommended risk management options will generally be of the "risk control" category above, and the risk management will be just special emphases or possibly additions to existing plans. For example, the risk management plan might be additional development tests, a re-review of make-or-buy decisions, a shift in schedule, etc.

Management must exercise its judgment to prioritize resources for risk management purposes. The ranked risks are reviewed in terms of combined likelihoods and consequences and in terms of program level concerns with missions, functions, business objectives and political aspects. Assuming that the senior management is satisfied with the completeness of the risk management efforts leading to the review (identification, evaluations, options, etc.), the risks can be ranked or re-ranked in terms of program priorities and the primary options selected for each for the planning of risk management.

The risk owners should be present to support the ranking and to assure that the priorities are reflected in their subsequent planning efforts.

Note: The customer should not be a part of these reviews since business interests beyond the customer's purview will be discussed. Risks stipulated by the customer are, of course, included as required.
1.2.6 Develop Risk Management Plans
At this point a hiccup in the average RFP will be discussed so that what is meant by risk management plan will be understood.

Most RFPs from beginning to end refer to a risk management plan in the singular, and this plan in the singular refers to all of the topics discussed here. However, allowance is typically not made for multiple risk plans for risks that often have significantly different characteristics. Therefore, the recommendation is that the risk management program encompass a two-tier approach to risk management plans: a risk management program plan (RMPP) and risk-specific risk management plans (RMPs). The RMPP essentially captures all aspects of risk management at the program level and those aspects common to all risks.

Note: In some risk manuals, plans roughly equivalent to Risk Management Plans are sometimes denoted as Risk Abatement Plans.

For example, the DSMC RMG provides a suggested outline for a risk plan that is not attuned to the recommendations and suggestions presented here. Four of five sections of that outline refer to common elements, and specific risk planning is limited to portions of the fifth and final section. With some slight modification this outline can be used as a basis for the RMPP that, in turn, defines the scope of risk specific plans.

Suggested contents for RMPPs and RMPs are given in Appendix A.

The RMPP should encompass an approach to risk management that commits the program to significant emphases for all risks considered to be of moderate to high. Such risks will have specific risk management plans, and each risk will be referenced in C/SCSC-based reporting, e.g., Variance Reports by CAMs will have a flag indicating that a high or moderate risk is associated with the effort being reported.

Risks considered to of a low ranking can be delegated to routine management, and such risks do not require specific risk management plans. Note: The relative treatment of high, moderate and low risks corresponds closely to the treatments suggested by Blanchard (Reference 3).

Note: The use of high, moderate and low categories does not preclude finer numerically-based rankings, but the finer grained rankings are not usually recommended.

For a large program (say hundred of millions of dollars) the RMPP can be developed with a page count of no more than 35 pages (assuming a large number of graphics). Individual RMPs can be on the order of 75 pages for high risk and 25 pages for moderate risks. The difference in the RMPs as a function of risk category is that the RMP for a high risk should be a stand-alone document with minimal references (directly including budgets, schedules, technical data, etc.). The RMP for a moderate risk can be largely based on references to appropriate sources.

1.2.7 Authorize the implementation of the risk management plans
This step is usually accomplished by the simple act of the program manager's signature on the signature pages of the RMPP and lower-tier RMPs. The plans are under configuration control following this step.

1.2.8 Track the risk management efforts and manage accordingly.
After the planning is accomplished and the RMPP is underway, the risk manager should be responsible for presenting the status of all risks at all reviews. Risk reviews should be a part of both technical and programmatic reviews.

A part of this risk management effort will be the implementation of a risk management board consisting of senior managers. These persons do not have to be risk owners although they may be. This board is convened routinely to provide high-level visibility to the risk management process. The risk manager and owners of significant risks present summaries of progress or non-progress in managing the risks. Also, the program is routinely reviewed for the occurrence of new risks.

The frequency at which the board meets will depend on the risks, the organization's structure (e.g., primarily internal responsibility versus significant subcontracting) and the overall schedule. As a minimum, the board should be convened prior to all major program reviews (SRR, SDR, etc.) to assure all parties have a mutual understanding of these critical areas before going to the customer.

Monthly risk board sessions can be appended to normal internal management reviews. These monthly risk reviews will normally be intra-organizational affairs (intra-prime, intra-subcontract, etc.). The risk managers of subordinate organizations can transmit summaries to the risk manager for the prime for inclusion in the prime's risk review. The special reviews should include all organizations. These reviews are normally difficult to schedule since they will occur in the hectic periods prior to major reviews, and they may have to be via videoconference or teleconference. The video-based conference is preferred, but either mode works relatively well since the risk issues tend to be relatively static. (A program with highly volatile risk management issues across the board would be in a world of hurt.)