Risk Management Lessons Learned

There were some thoughts on the allocation - or not allocating - risk on a web forum. The "agile" approach was to share the risk amoung the team members.

After responding to those postings that the allocation of risk is one of four risk management steps, I poked around a bit and find some lessons learned on risk management from some "high risk" programs. One example was the Genesis vehicle that orbited the Sun and returned to earth earlier this year. It crashed in the Utah desert, but most of the science was recovered.

There are several "lessons learned" from the initial risk management plan. First some previous lessons learned.

1. The greatest risks are often overlooked
2. Inappropriate attention may be given to one risk over another
3. Often a risk driver (source of the risk) will impact many facets of the project
4. Often risk are managed by lists that are ranked by subjective qualitative measures resulting resulting in resources being spent with little return. This by the way is one of the approaches defined in PMBOK
5. Risk identification is the most critical step in risk management, but it is usually poorly done

From these learning on many spaceflight programs several solutions have been derived.

1. Devolved - means the actions and the responsibility, accountability and authority are delegated downward as a matched, inseparable set. The term devolved is used in place of allocated, delegated, or deployed because the definition of devolved is more restricted. The intent is to increase the confidence that the best effort has been performed to identify and manage risk by placing responsibility at the appropriate level. Oversight and external risk management are less effective because they do not "own" the risk. Identifying a person who experiences the risk as the risk owner is the best assurance that the risk  will be managed.
2. Integrated - all risks are integrated into one collection. Cost, Schedule and Technical risk. The integration is managed by the project risk manager.
3. Trained - there must a consistent application of the risk management processes across the project.
4. Tailored to the Organization - the organization has specific requirements. A "one size fits all" approach is not effective.
5. Quantification - is absolutely necessary in order to manage the mitigation investments. A Triage process can be applied here to assign the likelihood and consequences numbers. An impact matrix can be used to make visible the risk across the work breakdown structure.

The major outcome here is that risk CAN NOT is collectively "owned" it MUST be devolved to the parties effected by the risk. These parties will then be responsible for mitigating the risk in a manner most appripriate to the risk, their technical, financial, and schecule domain.