Project Risk Management

Definition

Project risk management is the risk management subactivity consisting of the cohesive collection of all tasks that are primarily performed to lower a project’s significant risks to acceptable levels.

Goals

The typical goals of project risk management are to:

• Reduce project risks to acceptable levels.

Objectives

The typical objectives of project risk management are to:

• Identify and understand the major risks to the project.
• Avoid the risks that can be avoided.
• Mitigate the impact of risks that cannot be avoided.

Examples

Typical examples of project risk management include the management of risks on a:

• Small, simple, low-criticality project.
• Large, complex, distributed, business-critical project.

Preconditions

Project risk management typically may begin when the following conditions hold:

• The project is started.
• The project team is:
  • Initially staffed.
  • Adequately trained in risk management.

Completion Criteria

Project risk management is typically complete when the following postconditions hold:

• The project is retired.

Tasks

Project risk management typically involves the following teams performing the following tasks in an iterative, incremental, parallel, and time-boxed manner:

• The project team, which performs:
  • Risk Analysis
  • Risk Control
  • Risk Identification
  • Risk Management Planning
  • Risk Monitoring

Environments

Project risk management is typically performed using the following environment(s) and associated tools:

• TBD
  • Risk management tool

Work Products

Project risk management typically results in the production of all or part of the following work products:

• Risk Management Plan
• Risk Analysis
• Risk Monitoring Report

Phases

Project risk management tasks are typically performed during the following phases:

Guidelines

• The importance of a risk is the product of its probability and its impact.
• It is typically better to avoid a risk that to mitigate its damage once it has occured.
• Risks can be divided into the following categories:
  • Business Risks:
    • Requirements Scope Creep
    • Changing Market Pressures
    • Loss of Market Share
    • Bad Public Relations
    • Loss of Life or Property
    • Litigation
  • Financial Risks:
    • Cost Overrun
    • Inadequate Cost Estimates
  • Resource Risks:
    • Inadequate Staffing
    • Inadequately Trained Staff
    • Inadequate Staff Productivity
    • Inadequate Development Tools
  • Schedule Risks:
    • Unrealistic Schedule
    • Inadequate Schedule Estimates
    • Upgrades to COTS components and tools not available when promised (vaporware)
    • Excessive Time To Market
  • Technical Risks:
    • The project will not provide all required functionality.
    • The project’s transactions will not be auditable.
    • The project will not adequately support internationalization.
    • The project will not provide personalization.
    • The project will contain excessive defects.
    • The project’s outputs will be inadequately accurate or precise.
  • This activity is documented using the typical configuration for large projects. It is intended to be configured (i.e., instantiated, extended, and tailored) to meet the needs of specific projects.
  • The preconditions of this activity should be the union of the preconditions of its constituent tasks.
  • The completion criteria for this activity should be the union of the postconditions of its constituent tasks.