Risk Identification And Response Planning

A Risk List is created by the project manager during the Inception Phase and presented to you prior to a LCO Milestone.

The project team participate in the process of identifying possible Risks, and assist the project manager in answering the question, 'what could go wrong?'. A Risk List may include hundreds of Risks, but a maximum of 20 are presented to you for Risk Strategies selection and Risk response plans approval.

You are responsible for choosing which Risk Strategy you wish to implement for each Risk. The following is an example of a Risk List:

Risk ID and Description	Mitigation Plan	Contingency Plan
RISK1, Data provider changes the API on its own schedule, without prior notification. The next change may happen before the project release Milestone, and the system won't work.	Develop a configurable XML-based integration module that will allow dynamic API changes without code re-factoring (240 staff-hours)	Integration module re-factoring (180+ staff-hours, 10+ days)
RISK2, Video compressing module is open-source software and doesn't have any guarantees or support. Defects may be revealed in the module.	Perform module testing (70 staff-hours) and re-identify Risks	Defect removal in the module (220+ staff-hours)

The Mitigation plan is what actions will be taken in advance to remove Risk responsibility from you. The Contingency Plan is what shall be done when the Risk occurs.

When a Risk List is presented, you select a Risk Strategy for each item listed. You can choose to accept the Risk, or select to implement the Mitigation Plan. For example:

Risk ID	Rank	Strategy
RISK1	Mitigate	Extend budget for 240 staff-hours and develop a configurable XML-based integration module that will allow dynamic API changes without code-refactoring
RISK2	Accept	Do nothing, but if defects are revealed, the budget will be extended for 220 staff-hours in order to remove the defect. If this does not help, the budget will be extended for 500+ staff-hours for the development of a custom video compressing module

If you accept the Risk, it means that you agree to take full responsibility for it. If the Risk happens, the Contingency Plan will be implemented, resulting in an extension of the project Schedule, Specification, and Budget. In the example above, the customer has chosen to accept RISK2. As a result, the customer may have to pay for an additional 220 hours in the event that the Risk takes place, as detailed in the Contingency Plan.

If you choose to implement the Mitigation Plan, this means that the project team will attempt to prevent the Risk from happening at all, and try to neutralize the Risk consequences. In any case, you will not be held responsible for the impact to the project if the Risk should occur. In the example above, if the customer chose to use the Mitigation Plan for RISK1, the project team would add a XML-based integration module to the Scope. If the Risk happened to occur in spite of this measure, the team would then have to implement the Contingency Plan, however, the customer would not be responsible for additional staff hours.

As shown in the examples above, each Risk has the probability to impact the Cost, Scope and Schedule. Qualitative and quantitative Risk analysis is done by the project manager in order to select the top 20 Risks.

As shown in the diagram, Risk management is an iterative process:

New Risks can possibly be revealed during the whole lifecycle of the project until the final Release Milestone is reached. A Risk List is only provided to you during the Inception Phase. You are not responsible for any Risks identified after the LCO Milestone, as long as subsequent Risks are not related to new Specifications.

The Risk List is a very important document in any software development project and is used by all project team members. The Risk List is not a part of the project Deliverables, but you still can access it for review.