Locked lesson.

Upgrade

About this lesson

When risks become reality, there are major impacts both internally and externally. Risk-based design incorporates risk reduction into the design of products and processes. The sooner risks are addressed, the lower the impact of risk reduction.

Exercise files

Download this lesson’s related exercise files.

Product and Process Risk.docx
61.1 KB Product and Process Risk - Solution.docx
61.4 KB

Quick reference

Product and Process Risk

Technical product or process risk will result in degrading or dangerous operational and use conditions for both operators and customers.  A risk analysis should always be done during the development of new products or processes to prioritize and reduce significant risks.

When to use

Product and process risk analysis is best done as a preventive analysis to eliminate or prepare for the risk, rather than as a reactive analysis done during a crisis.  New products or processes should undergo a risk analysis before design freeze, so that risk mitigation features and characteristics can be easily incorporated.

Instructions

Proactive risk management is a mindset.  It relies on analysing new products and processes during the concept and design stages in order to identify risks and resolve them early.  This will reduce impact on both the organization and on customers.

Design risk analysis normally creates a risk profile of potential risks and prioritizes those risks to determine which are most critical to resolve.  If risks are not resolved early in the design process, later resolution often cascades into multiple problems.  For instance, a problem resolved at the early concept stage may be as simple as erasing a white board and drawing a new concept.  Once it moves into the preliminary design stage, the cost of resolving the problem goes up by an order of magnitude since now there are analyses to be redone and possibly some prototypes of mock-ups to rebuild.  Progressing on to the next stage, once the design is frozen, the cost to implement a change to resolve a risk goes up by another order of magnitude.  Now, there is the design work to be redone, but also, often the process development has started, vendors are on contract, and capital equipment has been purchased.  All of these may need to change also.  The cost of resolving the change goes up by another order of magnitude if the risk is not identified until after the product or service is in the market.  At this time there is all the redesign effort as mentioned before, and in addition, the product or service must be recalled, repaired, or some concession provided to the customer.  Sales will undoubtedly be affected.  The business often has a publicity disaster on its hands that requires additional expenditures to overcome.  This sequence is known as the Rule of 10’s since the cost to resolve the problem goes up by a factor of 10 as the product or service progresses through each stage.

Design risk analysis prioritizes the risks to decide which risks to address and which to accept.  It is impossible to eliminate all technical risks.  An analysis must be done and a business decision made as to which risks are addressed.

Technical risks can have many manifestations.  The table below is an illustrative, not exhaustive list.

Hints & tips

  • The risk analysis should be a structured methodology to guide the development team in their assessment.  Otherwise, during the rush to develop and launch a new product or process, risks will be overlooked.
  • It is often hard to get a development team to do a risk assessment.  They are focused on cost and schedule of development.  If they miss a risk and it is not recognized until the product or service is launched, it is usually a different set of individuals who are doing the risks response at that time.
  • The Rule of 10s is a principle, not an auditable formula.  In your organization, the rate of increase may be greater or less than a factor of 10.
Login to download
  • 00:05 Hi, I'm Ray Sheen.
  • 00:06 As we start to explore the FMEA methodology,
  • 00:09 I want to lay some ground work by discussing product and process risk.
  • 00:13 Let's look at the processes of design and control from a risk perspective.
  • 00:19 A risk-based design focuses on the risks that the product or
  • 00:23 process design enables or inhibits.
  • 00:25 It's technical risks that occur, because the customer uses the product, or
  • 00:29 design, or technical risks to the internal user when following a process.
  • 00:34 Now, it's impossible to eliminate all risk and still actually do something.
  • 00:38 So a key aspect of risk-based design and control, is to prioritize the risks and
  • 00:44 to make decisions about how to address the big ones.
  • 00:47 You know, an interesting thing often happens when we try to fix a technical problem.
  • 00:51 That fix, either creates or exposes two more problems.
  • 00:55 The risk begin to cascade through the product of process.
  • 00:58 That is why we need to recognize and
  • 01:00 control the risks right up-front in the design, and not wait until the product or
  • 01:04 process is in use, and then come in and try to put a band-aid on it.
  • 01:08 A risk-based design and control analysis will prioritize the risks based upon
  • 01:12 the overall profile of that risk.
  • 01:15 That means that the impact the risk would have, if it occurs,
  • 01:18 the likelihood that the risk will occur, and the ability and preparedness
  • 01:22 of the user, product, or process to respond to the risk when it does occur.
  • 01:28 Let's take another look at why we would want to do a risk-based design analysis,
  • 01:33 and we'll do this by highlighting the cost of a change to a product or
  • 01:36 process design, as we proceed through the design process, and just to be clear,
  • 01:41 this is a design change to fix a problem, and resolve a risk situation.
  • 01:46 This problem is such,
  • 01:47 that we can't release the product to the market with this issue.
  • 01:50 Notice that on this little graph, we will go from left to right as we consider
  • 01:55 the cost and effort needed to change a product during its development life cycle.
  • 02:00 We refer to this principle as the rule of 10's.
  • 02:03 Now, 10 is just an approximate number.
  • 02:05 In your organization, it might be lower than 10, but probably it's higher.
  • 02:09 So first,
  • 02:10 we consider the case when the product is just in the early concept stage.
  • 02:14 If at that point, we recognize that there might be a problem, well,
  • 02:17 all we need to do is erase that part of the whiteboard on which we've been
  • 02:21 brainstorming the design, and try something different.
  • 02:24 For our illustration, we'll say that that change only cost $1.
  • 02:27 Now, we go a little further in the design process.
  • 02:31 We have decided on a concept, and we are starting to do some design work.
  • 02:35 Maybe we have started writing some software code, or building a mock-up.
  • 02:39 Now, we see the problem.
  • 02:40 Well, we have to stop what we were doing and start over, write new code or
  • 02:44 change the mock up.
  • 02:45 This is more work than just erasing the white boards, so
  • 02:48 we'll say that this change is a cost of about $10.
  • 02:51 Onto the next phase.
  • 02:53 And now, we have finalized the design.
  • 02:55 We're starting to line up suppliers.
  • 02:57 We are creating all the product information in our customer-facing
  • 03:00 systems.
  • 03:01 Not to mention, we've been doing a lot of verification and validation testing.
  • 03:06 And then, we find the problem, but we have to go back and redesign.
  • 03:10 We can't go to market with this problem.
  • 03:12 So there's all that work to redesign, retest, plus,
  • 03:16 we have all the contracts with suppliers that now require a change order.
  • 03:19 And there will probably be a delay to the launch of the product.
  • 03:23 If the problem is found at this stage, it's 100 times more expensive to fix.
  • 03:26 Then if we have found it, back when were just working on the white board.
  • 03:30 Finally, we have the worst case.
  • 03:33 We've released the product to the market, and we find the problem.
  • 03:36 In addition to all the design work I just mentioned at the $100 level.
  • 03:40 Now, we have a problem in the market.
  • 03:43 We may need to do a recall or go out and do warranty work for the customer.
  • 03:47 We have to spend marketing effort to explain the problem and
  • 03:49 reassure our customers that there won't be any more problems.
  • 03:53 If you've had to live through a recall or a public relations disaster with a new
  • 03:57 product, you know that saying it was 1,000 times more expensive
  • 04:00 than fixing it on the white board, is an understatement. So what is the take away?
  • 04:05 We want an easy-to-use analysis tool that helps us to identify significant risks,
  • 04:10 back when we are working on the white border or at the mock-up stage of
  • 04:13 development, and not wait until we're writing to launch the product.
  • 04:18 Or worse yet have already launched a new product, and
  • 04:21 then uncover the risk problem.
  • 04:23 Well, let's wrap up this discussion by just by considering for
  • 04:26 a moment all of the types of technical risks and their potential impact.
  • 04:30 Of course, there are safety risks that result in harm or
  • 04:32 injury to either customers or our employees.
  • 04:35 The quality impacts have to do with degraded operations.
  • 04:39 A poor quality design doesn't operate as it should, and
  • 04:42 a poor operational process leads to premature failure.
  • 04:45 And performance impact occurs when the product doesn't do
  • 04:48 all that it's supposed to do.
  • 04:50 Functions either don't perform, or
  • 04:52 don't perform in the manner in which they're expected to perform.
  • 04:55 Reliability impacts will take one of two forms.
  • 04:58 Either the product fails before it is expected, and
  • 05:01 doesn't live up to its promised life expectancy, or
  • 05:03 the product requires ongoing excessive maintenance to keep it operational.
  • 05:07 And there may even be environmental impacts.
  • 05:10 The product may create unnecessary waste streams that require cleanup or disposal.
  • 05:14 Or just the complexity of containing the expected waste may be difficult and
  • 05:18 irritating.
  • 05:19 Any and all of these will be considered a failure in the design and control process.
  • 05:24 We need a tool or technique to help us analyze at the early design stages
  • 05:28 to avoid these types of problems.
  • 05:30 And the failure mode effects analysis, or FMEA, will do just that.
  • 05:36 Risk-based analysis during design,
  • 05:38 considers the impact of the design decisions and attempts to minimize
  • 05:42 the likely negative impacts while optimizing for possible positive impacts.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course