The basic objective of risk management is to minimize the number of risks that become issues.

Hopefully, you will have mitigated most of the major risks before this occurs and have fewer major issues to deal with during the project’s lifecycle. Project risk management is the systematic process of identifying, analyzing, and responding to project risk. Project risk is an uncertain condition or event that, if it occurs, has a positive or negative effect on at least one project objective. A risk may have one or more causes, or triggers, with one or more impacts. Risk conditions may include aspects of the projects organizational environment, contractual obligations or dependencies, or stakeholder relations.

Risks can include the possibility of suffering a negative impact to the project, whether it is decreased quality, increased cost, schedule slip, or project failure. The process should assign specific responsibilities for the management of risk and prescribes the documenting, monitoring, and reporting processes to be followed.

This section presents the process for implementing proactive risk management. Risk management is a project management tool to assess and mitigate events that might adversely impact the program. Successful implementation of risk management will increase the program’s likelihood of success.

This process will:

  • Serve as a basis for identifying alternatives to achieve cost, schedule, and performance goals
  • Improve service and product quality
  • Assist in making decisions on budget and funding priorities
  • Provide risk information for Progress Reviews or milestone decisions
  • Allow monitoring the health of the project as it proceeds through the lifecycle

 The five key elements of risk management are:

A. Risk management planning

B.  Risk identification

C.  Risk analysis (qualitative and quantitative)

D.  Risk response planning

E.  Risk monitoring and control

The following figure illustrates the risk management process as it relates to a software project lifecycle.

Risk Management Process SW Development Example

Something in writing should define the roles and responsibilities and processes to be used by project key players to manage and control risk. Also, get agreement on acceptable risk tolerances – for those times when will you sound the alarm! For instance, when there is more than a one-week schedule slip, or a projected cost overrun occurs by a specified date.

A. Risk identification

Risks should be identified at the beginning of every project/task and should include:

  • Business (cost and contract)
  • Technical
  • Schedule
  • Resource availability
  • Programmatic

It doesn’t have to take very long to identify “what if scenarios” but you should definitely involve the key Project Team members. The product of this exercise is several “what-if” scenarios such as:

  • What if key personnel leave?
  • What if requirements change?
  • What if budget is reduced by 20%?

Some of the techniques that you can use to identify and document the various risks that might occur on your project are:

  • Brainstorming
  • DELPHI technique
  • Expert interviewing
  • Historical records
  • Checklist

Some of the common situations that can negatively impact the project schedule are:

  • Tasks on the critical path
  • Overly optimistic estimates in terms of cost, schedule, technical, or some combination of the three
  • Tasks reliant on external dependencies
  • Tasks with a large number of predecessors
  • Changing specs/requirements

Some of the common situations that can negatively impact the project resources are:

  • Scarce resources
  • Many different resources to coordinate
  • Changes in corporate funding priorities
  • Changes in costs
  • Unqualified resources

Some of the common situations that can negatively impact the project scope are:

  •  New products
  • Changing or creeping requirements
  • Availability of technology
  • Unexpected defects
  •  Supplier failure

B. Risk analysis

The key to risk analysis is to isolate the risks that have the highest probability of occurring and the greatest potential negative impact of the project.  Then to identify steps that can be taken to minimize the probability of these risks happening or at least minimize the negative impact if they do occur.

This figure illustrates a technique to identify the potential cause of a specific project risk.


Of course, you can also use this technique to identify the cause of a problem that has already occurred.

Qualitative risk analysis

There are three key risk analysis components – the potential risk events, the probability that the risk will occur and the potential impact on the project if the risk occurs. The following matrix can be used to evaluate a potential risk.

Risk evaluation matrix with colors

Risks that fall into the red-shaded cells of the matrix are the highest priority and should receive the majority of risk management resources during response planning and risk monitoring and control. Risks that fall into the yellow-shaded cells of the matrix are cautionary risks, followed by the lowest risks that fall into the green-shaded areas.

During risk analysis, the potential impact of a given risk is assessed and an appropriate risk probability level is selected. Here is a standard set of risk probability and risk impact definitions.

Likelihood (Probability)

  1. Not Likely
  2. Low Likelihood
  3. Likely
  4. Highly Likely
  5. Near Certainty

Consequence (Impact)

  1. Minimal
  2. Some
  3. Moderate
  4. Significant/High
  5. Critical/Severe

Quantitative risk analysis

There are several major quantitative risk analysis techniques that may be used on more complex projects. Some cost estimating techniques for risk analysis, for instance, include:

  • Analogous Estimating (Top-down)
  • Bottom-up Estimating
  • Parametric
  • Three-Point Estimating
  • Project Management Software
  • Vendor Bid Analysis
  • Reserve Analysis (Manager’s Reserves)
  • Interviewing
  • Decision tree
  • Simulation (Monte Carlo)

C.  Risk response (mitigation) planning

There are four basic strategies for treating (mitigating) the risk on your project.

1. Avoidance. This is using an alternate approach that does not have the risk.  This mode is not always an option, but this is the most effective risk management technique if it can be applied.

2. Control: The Risk Management Guide from the Defense Systems Management College defines this mode as “the development of a risk reduction plan and then tracking to the plan.” The key aspect is the planning by experienced persons. But the plan itself may involve parallel development programs.

3. Assumption: This is simply accepting the risk and proceeding without any mitigation.

4. Risk Transfer. This is attempting to pass the risk to another program element. This could entail passing the risk onto a subcontractor, customer, or another outside organization.

A table with the following column labels can be used to document project risks and mitigation steps for the high and, where practical, medium probability and impact risks.


Once you have identified a potential risk that has a potential impact and probability of occurrence that is great enough, you will need to identify and select the best risk mitigation approach.

A matrix with the following information can be used to analyze each mitigation alternative.

  • Look for how to make the risk go away so that is it no longer a risk.
  • Develop a workaround plan
  • Implement corrective actions
  • Process a change request
  • Update the project and risk response plans
  • Document lessons learned

If risk elimination or minimization is too difficult or impossible and all you can do is to wait and see if it occurs, then you might devote some time developing a plan to be ready to react to the risk.

Your Risk Register should be maintained on the your company enterprise portal.

The following list describes many of the risk scenarios that can occur on government projects.

  • No sound management approach to the project proposal through start up
  • Poor start-up, late Baseline
  • Viable methods proposed and available but seldom used
  • Cost based on bid productivity but productivity never measured during life of project
  • PM lacking in prior, successful experience; i.e., never completed a successful PM job before or never managed a fixed price program
  • Initial and follow-up planning insufficient to provide clarity and completeness
  • Little up-front attention paid to necessary architecture of the intended system and, when attention is paid, no viable analyses of “workability/doability” of the architecture defined
  • Planning and progress tracking mostly by subjective means vs. objective measures
  • CM/CC methods/controls insufficient to meet evolving system
  • Risks not identified early-on and/or no risk identification-mitigation program in effect
  • Policy adherence given “slow-roll” by all concerned
  • Employees leaving early to seek “better opportunities”
  • Metrics not followed
  • Management reviews seldom held
  • During reviews, “accomplishments” presented without being tied to things that were “planned”
  • Acceptance criteria for deliverables seldom defined/agreed upon with the customer prior to delivery or customer acceptance of criteria not documented
  • Requirements definition(s) not clearly nor completely specified sufficient for the viable use of the intended implementers
  • System’s performance characteristics not sufficiently identified, allocated, tracked, nor well understood
  • Efforts in progress not consistent with baselined planning
  • Capabilities continually moved to later releases to “ease” schedule pressures
  • Sufficient QA methods not employed
  • Program team not committed to cost/schedule objectives because they view superior technical performance more important
  • A different team is performing the program than the one that bid it and the technical approach is now deviating from the original vision
  • PM does not believe in assigning formal action items at staff meetings
  • The Bill of Material is inadequately defined or controlled
  • Viable task interdependencies not defined/maintained and/or used as a management “tool”
  • No viable/approved “business case/plan” defined or used
  • “Completion criteria” not defined for individual task assignments
  • Adequate training/mentoring of management staff not done
  • The PM has never fully read the contract
  • PM does not set and communicate priorities between cost, schedule and superior technical performance
  • Relationships with subcontractors, customer-furnished equipment, or associate contractors not included in the schedule
  • PM  does not effectively delegate and becomes a single-point failure, delaying all decisions
  • The PM does not develop nor implement a communications plan

– Mike Lisagor