Any kind of Project Plan should build in tasks to mitigate both product and project risk. It’s fundamental, but we don’t always do it.
- No location available
-

Product risks are the risks addressed by your plan already. In the concept phase, product risks relate to feasibility. For example, can we get adequate torque transfer along our thin flexible catheter in a tortuous anatomy? Can we achieve adequate signal-to-noise in our imaging system? In later phases, product risks relate to reliability. For example, will we meet the tensile spec with 0.95 reliability at 95% statistical confidence?
- No location available
- 1todo evernote, feasibility, product risk, project risk, reliability,
- [note::I don't think I've heard of the concept of a
"product risk" before, but seems like a pretty important thing to keep in mind when it comes to building both physical and digital products.]

Project Risks relate to risk of not hitting project timelines or development cost. A common project risk occurs when we ask a vendor to make a difficult part, incurring the risk that it will take them longer than planned to get the part right. Regulatory submissions are another source of project risk. One never knows why regulators sometimes make the decisions they do.
- No location available
-

The most common ways of mitigating both Product Risks and Project Risks are to get started early (to leave time to recover), or to pursue multiple independent paths in parallel.
- No location available
-

One of the best ways to identify Product Risks and Project Risks is to Perform a Project Premortem.  My team does this often. To uncover Product Risks, assume the the product did not perform as designed (safety, efficacy or usability problem), and ask what must have gone wrong. To uncover Project Risks, assume the the project went over timelines or over budget, and ask what must have gone wrong.
- No location available
-

Pursuing multiple independent paths reduces risks more when the failure modes of each path are different. Recently we wanted to build a multi-lumen subsystem. We contracted with two different vendors to make multi-lumen extrusions, each using slightly different materials. This reduces the risk of a vendor-specific problem (e.g. they can’t dial in the right settings) but doesn’t reduce the risk that the design may not work.
- No location available
-
- [note::Is there an equation to model this? e.g. Risk = # of Possible Failures Modes / # of Approaches Taken]

Product Risk: The likelihood that the product design will not meet its specification.
- No location available
-

Project Risk: The likelihood that a Project Task will take much longer or cost much more than planned.
- No location available
- project risk, 1todo evernote,

Premortem: A really useful technique for identification of product and project risks.
- No location available
-

Any kind of Project Plan should build in tasks to mitigate both product and project risk. It’s fundamental, but we don’t always do it.
- No location available
-

Product risks are the risks addressed by your plan already. In the concept phase, product risks relate to feasibility. For example, can we get adequate torque transfer along our thin flexible catheter in a tortuous anatomy? Can we achieve adequate signal-to-noise in our imaging system? In later phases, product risks relate to reliability. For example, will we meet the tensile spec with 0.95 reliability at 95% statistical confidence?
- No location available
- 1todo evernote, feasibility, product risk, project risk, reliability,
- [note::I don't think I've heard of the concept of a
"product risk" before, but seems like a pretty important thing to keep in mind when it comes to building both physical and digital products.]

Project Risks relate to risk of not hitting project timelines or development cost. A common project risk occurs when we ask a vendor to make a difficult part, incurring the risk that it will take them longer than planned to get the part right. Regulatory submissions are another source of project risk. One never knows why regulators sometimes make the decisions they do.
- No location available
-

The most common ways of mitigating both Product Risks and Project Risks are to get started early (to leave time to recover), or to pursue multiple independent paths in parallel.
- No location available
-

One of the best ways to identify Product Risks and Project Risks is to Perform a Project Premortem.  My team does this often. To uncover Product Risks, assume the the product did not perform as designed (safety, efficacy or usability problem), and ask what must have gone wrong. To uncover Project Risks, assume the the project went over timelines or over budget, and ask what must have gone wrong.
- No location available
-

Pursuing multiple independent paths reduces risks more when the failure modes of each path are different. Recently we wanted to build a multi-lumen subsystem. We contracted with two different vendors to make multi-lumen extrusions, each using slightly different materials. This reduces the risk of a vendor-specific problem (e.g. they can’t dial in the right settings) but doesn’t reduce the risk that the design may not work.
- No location available
-
- [note::Is there an equation to model this? e.g. Risk = # of Possible Failures Modes / # of Approaches Taken]

Product Risk: The likelihood that the product design will not meet its specification.
- No location available
-

Project Risk: The likelihood that a Project Task will take much longer or cost much more than planned.
- No location available
- project risk, 1todo evernote,

Premortem: A really useful technique for identification of product and project risks.
- No location available
-