How to Identify and Manage Product Development Risk

Project risks come in many different forms, from those the project team anticipates to the ones they discover when an unexpected problem crops up. In product development, there are many sources because you interact with so many parts of the organization in order to commercialize the product.

Learn how product development risk and project risk are different.

However, there are some simple steps you can take to identify and manage risk AND deliver a product development project to meet management expectations.

What is Risk and Why Plan for It

According to the Project Management Institute (PMI), risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.[1] In addition to what is commonly considered risk, things like uncertainties, constraints, and assumptions are all additional forms of risk.

While we don’t talk often about the positive impact of risk on a project, they can be very valuable to identify and prepare for. An example of positive impact could be a window opens in the production line so we can start our product verification runs early, saving 3 weeks on the project schedule.

Product development teams often believe they know the risks to a project. However, they tend to focus on the technical risks and perhaps customer acceptance risks, but miss other important risks. Properly captured and reviewed risks should become part of the project management process used by the project team. By anticipating what could happen and developing response actions, the team can respond quickly when a risk occurs, instead of losing time in hastily called meetings trying to figure out how to react to the latest crisis. In addition, many risks may already be known by someone on the team. They simply forget to bring it up, especially if risks are discussed infrequently. A process that regularly solicits and proactively manages risks leads to better project outcomes.

How to Identify Risk

Before you start identifying risk for your project, determine whether there is an internal list or database of common risks in your organization. These could apply to all projects or just apply to your product category. You should also use lessons learned from other projects to help populate this list. If a list doesn’t exist, talk to other project managers to get their input based on their experiences.

Next you identify risks for your product development project. Below are the typical steps we recommend.

• Assemble a cross-functional team. At a minimum, the team should include project manager, product manager, technical lead, operations, and quality. We often include regulatory if the product is subject to approvals or certifications. You may also wish to include sales and customer service.
• Review the internal list, if available, for inclusion in this project’s risk identification. Take some time to talk through why each item is on the list before dismissing it. Sometimes less obvious risks may apply to a new product in a different category.
• Work through the different functions or areas of the product to identify risks, uncertainties, constraints, and assumptions. If you have a framework for identifying new risk, use it to structure the discussion. The PMI standard[2] contains many techniques to help uncover risks.
• Capture every risk identified. Use the right tool for your organization. A spreadsheet may be sufficient, or you may find a software tool like the Product Risk Framework helpful.
  • You may also want to include some very specific items, such as Bob is the only person in the company with the specific skills needed for this project. We will need him for 4 weeks of work, but he is assigned to 5 other projects, too.
• Evaluate each risk based on the probability that it is may occur against the impact if it is true. You should use a quantitative (i.e., score) or semi-quantitative (i.e., high, medium, low) method to evaluate each one.
  • Each risk should have an individual assigned, by name, who is responsible for monitoring that item. That person is usually from the functional area that is impacted by the risk. For example, if the risk is that the product can’t be sold using the existing sales channels, that assumption would be monitored by sales or marketing, depending on your organization.
• Prioritize each risk. All high priority risks need an action plan. Medium priority should have an action plan. Where possible, seek to eliminate the risk versus creating a contingency plan if it occurs.
• Incorporate action plans, as appropriate, into your project plan.
• Update and maintain the master database of risk exposures and learnings to reuse and inform future projects

Managing Product Development Risk

Product development risk identification is not a one-time exercise when starting your project or getting ready for a management meeting. It needs to be part of regularly managing your projects. While the details depend on the specifics of your project, you should do the following.

• Establish a regular schedule for reviewing all risks you have already captured. Every 1-2 weeks is ideal.
• Evaluate each risk to determine whether it still applies, whether the scoring may have changed (up or down), or whether it no longer matters and should be removed from tracking.
• Solicit new risks from all team members, add them to your list, then evaluate and prioritize them.

You may also decide to track the risk reduction for your project. A product development risk burndown graph is very useful in monitoring the overall risk level for the project.

Closing Thoughts

Product development risk is manageable. When you incorporate a risk process into your product development process, identifying and managing risk becomes a way to proactively address keep your project on track.

Our Exploratory PD™ process incorporates and prioritizes risk reduction to improve time to market and increase project success. Learn more by visiting https://www.exploratorypd.com/.

[1] Project Management Institute. Practice Standard for Project Management Risk. 2009. Newtown Square, PA USA. Project Management Institute

[2] Ibid.