To many, risk management is a mysterious subject that is difficult to get your arms around. The PMI’s Practice Standard for Project Risk management adds to the confusion. It has many methods for analyzing, identifying, and responding to risks, but they may not be practical.

This article aims to help identify and handle risks in small to medium-sized projects in our product development services.

Definition of Risk
The Project Management Institute (PMI) defines risk in this manner:

“An individual risk is an uncertain event or condition that, if it occurs, has a positive or negative effect to one or more objectives.”

PMI Standard for Risk Management in Portfolios, Projects, and Projects. Project Management Institute, 2019. Page 7.

Many know negative risks as things that will harm a project’s budget or timeline.

However, the project can benefit from identifying positive risks or opportunities and should exploit them.

For this exercise, we will focus on the negative risks or threats as they are more prevalent in the management of projects.

We should also acquaint ourselves with different types of risk, beginning with our attitude towards it.

Understanding the risk attitude of the project development stakeholders and your organization is critical to being able to prioritize and rank risks. Risk attitude consists of three factors: 1. Risk Appetite, Risk Tolerance, and Risk Threshold.

Risk appetite is the amount of hunger one has in anticipation of a reward.

Risk tolerance is the amount of risk one will withstand. Imagine you insert $5 into a slot machine. If you continue playing until you deplete your $5, irrespective of your potential winnings, your willingness to take risks lies within the range of $1 to $5.

Risk threshold refers to the level at which risk becomes intolerable. To illustrate, consider the example of the slot machine and the $5 bet. If the risk stayed below $5, it was deemed acceptable. However, once it exceeded $5, it became unacceptable. Hence, your risk threshold is set at $5.

Risk Identification

Identifying the source of risks is a major step in creating a risk management program. Four categories can break down sources of risk.

1. Internal: Internal risks drive the make-up of the organization. Internal policies, limited resources and limited resource experience are all examples of internal risk.
2. External: These are risks outside the organization that impact the project. Changes to scope, regulations, markets, and technology are all risks that the organization cannot control.
3. Practical: We have identified these risks, but we do not know the probability of occurrence. These are also called “Known Unknowns.”
4. Impractical: We have not identified these risks and we also do not know the probability of occurrence. We know these as “Unknown Unknowns.” Examples of impractical risks are weather, war, and pandemics.

Risk Management Plan

The risk management plan is the key for successful project risk management. The plan must set the guidelines for the roles and responsibilities for the project team to follow:

1. Normally, we identify risks from a work breakdown structure and make assignments according to areas of specialization.
2. The most common way to assess risks is through qualitative and quantitative analysis. Consulting SME’s is also an appropriate way of analyzing risks.
3. Risk responses – Transfer, Mitigate, Avoid, Accept

Now, let’s examine risk responses more closely.

Transfer risk – This response transfers the risk to some other entity outside the project engineer’s team. In most instances this would be to someone who has more experience or is better equipped to mitigate the risk than the team is.

Mitigate risk – This reaction requires the project team to change the product development plan to reduce the risk if it happens. They could find more resources to add to the project if the risk occurs to lessen the impact. Another option is to buy a machine for the product development team that would decrease the effect of the risk.

Avoid risk – This response is to not take on the task that contains the risk. Remove the task from the project’s work breakdown structure.

Accept risk – Accept that the risk is going to happen and work through the issue. In most cases of accepted risk, the cost to avoid, transfer, or mitigate the risk outweighs the cost of the risk occurring.

The final part of the risk management plan is to monitor, track, and control risks. Treat monitoring of risks with the same discipline as the budget and the schedule. Ultimately, managing risks throughout the project will keep the budget and schedule on track to success.

Project Mechanics

The risk management plan plays a significant role in the development of the project mechanics. Below are nine project modules that the risk management plan must have influence upon:

1. Stakeholder register – this is a list of stakeholders along with their roles, expectations, and project priorities. Refer to the chart below which contains a sample stakeholder register:
   
2. A communication or governance plan. This plan outlines how the project team and stakeholders will communicate about important matters such as changes to the project scope, weekly meetings, schedule reviews, and budget reviews. The project manager is responsible for writing and maintaining this plan.
   The governance plan identifies the individuals who are responsible for approving changes in scope, timeline, or budget. It also outlines the specific approval processes for these changes.
3. Work Breakdown Structure (WBS) – This is a highly detailed chart of every task required to complete the project. The WBS also becomes the basis for the risk register, calculation of reserves, and project budget. A sample WBS is shown below:
   
4. Risk Register – Based on the WBS, the project team creates a risk register and analyzes it using qualitative, quantitative, and SME analysis. The sample WBS is shown below:
   
5. Reserves – There are two types of reserves. The first is the Contingency Reserve which addresses known unknowns. Refer to the sample contingency reserve chart below:
   

The project team calculates the contingency reserve by multiplying the impact of the risk by its probability of occurrence. This results in a dollar value that represents the potential cost of the risk.
The second type of reserve is the Management reserve. The management reserve addresses unknown unknowns and is typically between 5% and 10% of the project cost estimate.

6. Project Cost estimate – To estimate the project cost, labor hours and their associated costs are calculated using the work breakdown structure (WBS). Project expenses are also included in this calculation.
7. Project Budget – Project budget is the sum of the Project Cost Estimate, Contingency Reserve and Management Reserve.
8. Project Implementation – Project implementation is the initiation of the project plan. The project team follows the work breakdown structure (WBS) to complete the project tasks. They monitor progress and ensure that the project is on track using the Governance or Communication plan.
9. Project Closeout – In the final step of the project plan, the project team verifies that all deliverables are complete and finalizes the project budget. When all parties are satisfied with the project deliverables and spending, the project is closed.

Fixed Price Projects

A word about fixed price projects as they involve a higher level of risk.

A fixed price project is one in which the client is purchasing a set of services at a set price:

• If the effort to complete the scope of work exceeds the approved budget the client does not pay more than the budgeted amount.

The client will not pay for performing work outside the original scope.

• The project team will not refund the client any remaining funds if the project scope is completed under the budgeted amount

The supplier assumes most of the project risk from the client. Because of the transfer of risk, all the previous steps in project mechanics become extremely important:

• Project requirements and deliverables must be ironclad.
• Accuracy of labor and expense estimates is crucial.
• A strong and comprehensive risk plan is critical.
• Identification and communication of out-of-scope activities during the implementation of the project is paramount.

Summary

At first, the management of risk for a product development project can be daunting. Carefully following the simplified risk management approach outlined above will effectively manage and integrate risk into the project management process.

To learn about our ’12 Keys to Successful Product Development: How Product Development Teams Manage Risks for Better Outcomes,’ click here.