The Risk Management Process

A Risk is "an Unknown"; it has not been determined.  It is not an Issue (or a Problem).  That is, a risk has at least two attributes that differ from an issue or problem:

1. A risk may occur or may not occur; an issue has occurred.
2. If a risk occurs, it will be in the future; an issue has occurred, which means it's here and now.

This implies that a risk has a probability of occurrence may be accepted, that is, and the person need do nothing but watch the probability.  If the risk increases in its probability of occurrence, then the person may want to do something.  Therefore, the person can change the design to avoid the risk, or the person may transfer the risk to someone who understands the unknown (converting it into a known), or the person may research or investigate the risk thereby mitigating it.  Consequently, when a risk is identified and assessed, it may be:

• Accepted--The person does nothing but watch for changes in the probability of occurrence and impact on effort if it occurs. 
• Avoided--The person changes the direction of the effort to avoid the unknown.
• Transferred--The person hires a person knowledgeable in the field of the risk
• Mitigated--The person plans and execute a research effort to turn the unknown (risk) into a known.

In creating, developing, or implementing a new product or service a risk is an unknown in the design to meet the customer's requirements. The process for managing risks during development has the following activities.

1. Identify--Knowing what you don't know is always THE key problem.  It's hard know know what you don't know.  That is why risk identification is so important.  Therefore, everyone on the team from the production worker and administrative assistant to the most senior Systems Engineer must be able to add candidate risks.

2. Assess--A Systems Engineer must assess all risks in terms of the probability of occurrence and the impact if it occurs.  The probabilities can range from highly improbable to highly probable and the impact can range from minimal to catastrophic.  The systems engineer will use a team of Subject Matter Experts (SMEs) to help determine both the probability and impact.

3. Disposition-- Once the Systems Engineer has assessed the risk, he or she will disposition it in one of the four ways described above.

• Accept--attach it to a risk "watch list".
• Avoid--change the design to reduce the risk.
• Transfer--get insurance against the risk and/or hire an expert in what you don't know.
• Mitigate--investigate and research the risk to turn the unknown into a known.

4. Watch--create a risk watch list of the risk assessments.  This list must be updated on no less than a bi-weekly bases, since risks assessments can change quickly as the detailed design is created.

5. Feedback--When a risk assessment changes, it may need to be re-dispositioned.
6. Mitigation Planning--if the Systems Engineer decides that the risk must be mitigated (the most expensive way to reduce a risk), then a team will need to create an investigation or research plan.
7. Mitigation Execution--Once the mitigation plan has been created and the resources for executing the plan have been allocated, the design and development team will execute the (mitigation) plan.

This completes the ongoing, cyclic, activities of risk identification and management; one of three or four standard Systems Engineering processes and responsibiltiies.  PS--All risks have cost, schedule, and technical impacts; to say a risk is a schedule risk or a technical risk is plain silly.