Risk Management
Risk Management is the recognition, assessment and control of uncertainties that may result in schedule delays, cost overruns, performance problems, adverse environmental impacts or other undesired consequences.

Risk Management has many components for careful consideration for optimal management of the Programs/Projects. Using the Risk management Plan as an anchor, following items need to be explored to keep the Programs protected.
*Program and Project have been used interchangeably on this page and shouldn’t be considered differently in the context of Risks mgmt. Both refers to the initiative undertaken by the organizations.
Roles and Responsibilities
Plan Stakeholders
Plan and/or Process Dependencies
Risk Management Process
Identify and Classify Risk
Analyze Risk
Determine Approach to Identified Risk
Track Risk
Mitigate Risk
Milestones
Tools
Measures
Risk Management is the recognition, assessment and control of uncertainties that may result in schedule delays, cost overruns, performance problems, adverse environmental impacts or other undesired consequences. Risk Tracking is the actual process by which identified risks are monitored and controlled. Risk Tracking is a sub-process of Risk Management.
The objectives of Risk Management are:
To focus attention on minimizing threats to the achievement of the Program core objectives.
To provide a systematic approach for:
Identifying and assessing risks;
Determining cost-effective risk reduction actions; and
Monitoring and reporting progress in reducing risk.
The overall goal of this process is to progressively reduce the Program’s exposure to events that threaten accomplishment of its objectives by:
Incorporating approaches into the Program plan that minimize or avoid identified risks
Developing proactive, contingent risk response actions
Rapidly implementing risk responses based on timely identification of risk occurrence
- Roles and Responsibilities
Typically, Program management sets the scope and direction of Risk Management Planning. Program Management is responsible for ensuring that risks are appraised in a continuous process throughout the development life cycle. Major roles include:
Overall Direction: Client Director and Program Manager
Plan Development and Execution: Risk Manager/Program Manager
Participate in Ongoing Identification of Risks: Team Leads/Team Members
Assist in Mitigating/Resolving Risks: Team Leads/Team Members
Risk management is a vital component of Program management. It is a process that requires constant assessment of potential impediments to achieving Program objectives. A properly implemented risk management plan will improve Program results by focusing management attention where it is needed most.
Overview of Program responsibilities:
Develop and maintain Program Risk Management Plan as part of the overall risk management effort
Develop and maintain the Risk Tracking Process as part of the overall risk management process.
Identify risks applicable to the Program.
Incorporate risk mitigation/avoidance approaches into Risk Management Plan.
Discuss upcoming risks and risk mitigation techniques during Program meetings.
Develop contingent risk responses.
Monitor and identify risk occurrence.
Implement risk response actions based on risk occurrence.
Document and report risks via a Program Risk Watch List.
- Plan Stakeholders
The following table lists the audience for the Risk Management Plan. When changes are made to this plan, the stakeholders should be advised. Refer to the Program Communications Plan for more information about these stakeholders.

- Plan and/or Process Dependencies
When changes are made to the Risk Management Plan, the Program Manager should also review the Program Plan, Program Measurement Plan, Program Work Plan and Issue Management Plan to ensure overall consistency of the plans.
- Risk Management Process
-- Identify and Classify Risk
Focusing attention on the value in determining risks facing each area of concern, and ensuring that risk planning is not perceived solely as an administrative exercise, is a process driven by the Program Manager.
Initially, focusing management attention on risks is assisted by reviewing the following information sources for direction:
Risk and Constraints
Program Area Descriptions and deliverable definitions
Existing Program documentation, or documentation employed from other Programs
Knowledge transfer from functional/technical experts with experience in similar Programs, application software, or technology platforms
Previously identified risks from similar development Programs
The risks identified by the Program Manager and Team Leads are documented into specifically defined, tangible risk items, for which a response/action may be well-defined and be measurable. This ensures that all analyses and reporting of risks maintain a deliverable-focus, for which progress towards high-level objectives can be compared. It is important to distinguish between risks and issues. Risk are items that could occur in the future. They are intended to proactively consider events that could impact the Program. Issues are events that have already occurred and need resolution.
Identifying vague or non-specific risks results in responses/actions that are ambiguous, intangible, unclearly defined, and difficult to implement adequately.
Additionally, it is important not to attempt to document all possible risks and outcomes, as this can often introduce improbable scenarios, which:
Create unnecessary concern and confusion
Shift the focus away from the real or probable risks
Dilute the pool of risks, leading to diminishing returns on effort
Reduce credibility for the risk mitigation process
Risk documentation is more concerned with identifying the areas where the consequences of the risk are most severe, and where corrective responses or actions will produce the largest benefits in risk reduction.
Furthermore, risk documentation takes the areas where risks are most likely to occur and develops detailed assessment criteria from which specific risks are documented.
Typical sources of assessment criteria are shown below:
Unrealistic budget or schedule estimates
Delivery on critical path, or unrealistic deliverable and milestone deadlines
New technologies and platforms, complex/leading edge technologies, and complex environments
Functionally complex data models, including processing functionality
Staffing considerations for experts, numbers, and experience required
Categorization of Risks: Risk categorization is achieved by defining five characteristic sources of risks. These describe the generic areas where specific risks are likely to occur, and formalize the categorization initially performed during Risk Planning:
Cost: Cost-based risks outline the non-achievement of the financial benefits of the Program. These cost risks include additional costs in changing/solving design, application program, or operational problems.
Schedule: Schedule-based risks focus on the non-achievement of the GREAT System benefits within the specified time frame. These schedule-based risks arise from extensions from scope changes, resource unavailability, and additional schedule extensions from solving those risks outlined in Cost above.
Technological: Technology-based risks consider the non-achievement of the application specifications and benefits expected. These risks include new/non-standard platform technology, integration problems with existing systems, migration problems, performance expectations not achieved, environment complexity and functionality, and system operability.
Operational: Operational-based risks focus on the peripheral organizational and business operational re-engineering changes, arising from the GREAT Application Development. These risks consider both the transitional and the long-term effects of the System's introduction, including the organizational and behavioral change required, the human and physical resource planning, and communication required to facilitate a smooth transition to the new structure.
External: External-based risks consider the environmental factors largely outside of the control of the Program Management, which can directly/indirectly, affect the successful delivery of the Program. Risks arising from legislative regulations, legal requirements, and the strategic direction and priority conflicts of a controlling body, are profiled under this category.
The Cost and Schedule risk sources are known as the risk indicators, as they are often the most tangible measure of overall progress towards Program objectives or goals. The Technological, Operational, and External risk sources are referred to as risk drivers, as these are the sources of all Program risks, which additionally drive the Cost and Schedule risks.
The recognition that the management of the sources of Technological, Operational, and External risk is inter-related to the management of Cost and Schedule risks is an important link in effectively responding and reporting risk-reducing activities.
-- Analyze Risk
Following specific definitions of the risks above, the most likely overall response to the risk should be decided. This may be an obvious set of actions that annul or limit the risk occurring, or alternatively may be an intuitive best guess of the available actions that are likely to be effective.
Risk quantification extends the value of the understanding, documenting and reporting on Program and Work Unit level risks, by attempting to assign each risk to a numerical scale.
This introduces a common format to risk quantification, based on easily understood numerical scales. These assist in realizing and focusing on the true impact of each risk, and in the prioritization of the risk-reducing activities and responses identified. The following three parameters for each risk are quantified:
Impact
This is an estimate of the overall scale of the impact following an occurrence of each risk. This is rated on the following scale:
6 Critical impact; threatens success of the Program
5 Extreme impact; significant disruption to successful delivery of Program objectives, products, and benefits
4 High impact; significant disruption to Program schedule, cost, and products over the medium and long terms
3 Medium impact; progress disrupted with large extensions to schedule and cost, across short and medium terms
2 Moderate impact; progress disrupted with manageable extensions to short-term schedule and cost
1 Marginal impact; exposure slight
Probability
This is an assessment of the probability of an occurrence of the risk, given the responses identified, and the other factors or risks on which it is dependant. This is rated on the following scale:
6 Extremely likely occurrence
5 Very probable occurrence
4 Probable occurrence
3 Possible occurrence
2 Unlikely occurrence
1 Highly improbable occurrence
Level of Control
This indicates the relative control that can be exerted on the probability of the risk occurring. Moreover, Level of Control attempts to introduce a modifier that quantifies the level of control that can be exerted over implementing that response. For example, the implementation of a risk response may need to be performed by an external contractor or body, and is outside of the direct control of the management team. This is a risk in itself, and is rated as follows:
6 Total direct control
5 Extensive direct control
4 Moderate hands-on control
3 Shared or partnered control
2 Minimal realistic control
1 No control

It follows that a risk with a high probability, high impact and low Level of Control are those risks that indicate a high level of exposure. Similarly, those risks with a low probability, low impact, and high control offer the lowest levels of exposure.
Consider the five separate and independent risks, A to E, shown in the following example:

Both risks A and B have equivalent low levels of exposure, as shown in the risk factors. However, the impacts of each are arguably indistinguishable, while there are larger variations in each risk's probability.
Risks D and E, which have equivalent extensive levels of exposure, have a substantially wider gap in risk impact. Risk D carries a medium impact with progress disrupted over short/medium terms, whilst risk E carries an extreme impact with significant and costly disruption to the delivery of the Program. However, the probabilities range only from probable to unlikely.
The value in quantifying each risk according to the above formula comes not from being able to assign a numerical value to each parameter, but from the subjective decision-making experience of the senior management involved in understanding the relative importance of each parameter between each risk. It is through this focus that a true value-added process is achieved. Therefore, the model is designed only to be a catalyst for focusing Program Management on the relative importance of the risks perceived.
Risk Analysis is primarily concerned with developing specific, discrete, and measurable responses to each risk.
This is not necessarily limited to the development of only one response per risk; two or more alternative responses may be defined, if the response to that risk is contingent on the outcome of a prior event.
Additionally, the combination of two or more interdependent risks is evaluated. The quantification or summation of individual risks that are linked may produce a different combined result to the individual totals, and should be recognized by area management during the quantification process.
-- Determine Approach to Identified Risk
Risks are acted upon on a prioritized basis. Risks are recorded in the Access database on the Program LAN with the appropriate priority.
-- Track Risk
Risk tracking is an important part of risk management. In it, the team monitors the status of risks and the actions it has taken to mitigate them. Risk tracking is essential to effective action plan implementation. This means devising the risk metrics and triggering events needed to ensure that the planned risk actions are working. This can do done through reporting. The Program team will use an Access database located on the Program LAN for documenting of risks.
Risk tracking includes:
Monitor risk scenarios - Risk scenarios are monitored to determine if the probability of risk occurrence is changing. Tracking risk scenarios over time increases the level of confidence that risk probability has been accurately Programed.
Compare thresholds to status - Through status reports and other Program documentation, thresholds outlined during the Risk Planning are monitored. Once a threshold has been exceeded, the risk action plan is executed.
Provide notification for triggers - Triggers are set to notify the Program when unacceptable risks are encountered. Triggers can indicate the need to revisit the risk action plan, inform the Program that the risk action plan can be put on hold, or signal the release of an action plan.
Report risk measures and metrics - Measures and metrics are used to determine the effectiveness of the risk management process and risk planning. The Program reports on risk measures and metrics to verify that risk management and tracking are occurring according to plan.
-- Mitigate Risk
Overall, Program risk response analysis covers five characteristic responses, discussed below:
Avoidance: Avoidance-based responses are employed at any point in the development lifecycle where future planning work is performed. Typically, most risk avoidance occurs during the Program definition and planning phases of a Program, where objectives, scope, key success factors, work breakdown, and Program outputs or deliverables are defined. An example of risk avoidance is the use of a stable, established technical solution in preference to an untried, or complex new technology. However, risk avoidance solutions may limit the ability to achieve high-level Program objectives, by unnecessarily constraining a desirable solution.
Control: Control-based responses occur at all points throughout the development lifecycle, and are typically the most common response. They identify an action or product that becomes part of the Team or area working plans, and which are monitored and reported as part of the regular performance analysis and progress reporting of the Program.
Acceptance: These describe the factors that may directly affect the success of the Program, but are outside of the sphere of influence of the Program Manager, and can therefore only be accepted. In addition, acceptance of risks as a response may be based on the cost-ineffectiveness of any available response or solution. An example: acceptance response could be created from a legislative or legal risk, over which no control could be leveraged.
Transfer:Transfer-based responses target the party who are best placed to analyze and implement the response to the risk, based on their expertise, experience, and suitability. Typical transfer responses include the sub-contracting to specialist suppliers who are able to reduce the overall risk exposure.
Investigation: Investigation-based responses do not define any mitigation for reducing an individual risk. They are responses to risks where no clear solution is identified, and further research is required. However, investigative responses should not be ignored, as they immediately and directly lead to a greater aggregated Program risk. This is because the probability quantifier for each risk includes the effect of the applied response, for which there is none, and the level of control quantifier indicates the level of influence to apply that response, which is low.
Individuals will list the identified risks and identify and record potential actions that could be taken to avoid or mitigate the risks. Actions will be identified which should be immediately incorporated into the Program plan to partially reduce the risk, as well as actions that should be treated as contingent risk responses. Also risk mitigation owners will be assigned to each risk.
- Milestones
Program level risks will be initially identified as part of the Program Risk Mitigation Plan. To provide visibility of risks and progress in mitigating them, the following reports will be provided on a regular basis:

The Program Manager will prepare a Program Summary Risk Report that summarizes the results of the previous risk mitigation process steps. This Program Summary Risk Report will be included with the monthly status report. New risks and status of existing risks will be discussed at the weekly manager’s meeting.