Risk Mitigation, Monitoring and Management

All of the risk analysis activities presented to this point have a single target to assist the project team in establishing a planning for dealing with risk. With an effective planning must consider 3 issues:

1. Risk avoidance.
2. Risk monitoring, and
3. Contingency planning and Risk management

Software team adopts a proactive approach to risk avoidance is always to best strategy.   This is achieved through building a strategy for risk mitigation example for suppose that high staff turnover is noted as a project risk, r1, which is  Based on management intuition and past history the likelihood l1, of high turnover is estimated to be .70 impact, x1 is projected to have a critical impact on project schedule and  cost.

To mitigate this risk project management must established a planning for reducing turnover.  Between the possible steps to be taken are these:

1. Meet with present staff to determine caused for turnover example for poor working conditions low pay and competitive job market
2. Act to mitigate those causes which are under management control in previous the project starts.
3. Once project commences suppose turnover will occur and establish techniques to ensure continuity when people leave
4. Organize project teams so which information about each development activity is broadly dispersed.
5. Define establish mechanisms and documentation standards to be sure which documents are developed in a timely manner
6. Conduct peer reviews of all work so which is more than one person is familiar with the work
7. Define a backup staff member for each and every critical technologist.

The project proceeds, risk monitoring activities commence.  The project manager monitors factors which may give an indication of whether the risk is becoming less or more likely.  In this case of high staff turnover the following factors can be monitored:

Additionally to monitoring the factors noted above the project manager should also monitor the effectiveness of risk mitigation step.   Example for a risk mitigation step noted above called for the definition of documentation standards and mechanisms to be sure that documents are developed in a standards and mechanisms to be sure which documents are developed in a timely manner.  The project manager should monitor documents carefully to ensure that each can stand on its own and that each imparts information that would be necessary if a newcomer were force to join the project. This is one mechanism for ensuring continuity should a critical individual leave the project.  

Contingency planning and Risk management suppose which mitigation efforts have failed and that the risk has become an original.  Continuing the example assumes in which the project is well underway and a number of people announce that they will be leaving. In that case if the mitigation strategy has been followed backup is available information is documented and knowledge has been dispersed across the team.  Additionally, the project manager might temporarily refocus resources to those functions which are fully staffed enabling newcomers who must be added to the team to get up to speed.  Those individuals spend their last weeks in   knowledge transfer mode and who are leaving is asked to stop all work.  This includes video based knowledge capture the development of commentary documents and/or meeting with the other team members who will remain on the project.

This is important to note that RMMM steps incur in addition project cost example for, spending the time to back up each and every critical technologist cost accrued by the   RMMM steps are outweighed by the costs associated with implementing them.   The project   planner performs a classic cost advantages analysis. If risk aversion steps for high turnover will raise project cost and duration through an estimated 15 %, but the predominant cost factor is backup management might decide not to implement this step. In the other hand if the risk aversion steps are projected to increase costs by 5 % and duration by only 3 %, management will likely put all into place.

For a large project 30 or 40 risks may be identified. If among 3 and 7 risk management steps are identified for each risk management may become a project in itself. For this reason we adapt the Pareto 80-20 rule to software risk. Experience indicates that 80 % of the overall project risk can be accounted for through only 20 % of the identified risks. The work performed during earlier risk analysis steps will help the planner to determine which of the risks reside in that 20 %. For this reason some of the risks identified assessed and projected may not make it into the RMMM plan-they don't comprise the critical 20 % (the risks with highest project priority).