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.
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?
What do I mean by Project Risk?
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.
To run a successful business we want to live within our project’s time and budget constraints. Adding Project Risk mitigation activities to our plan turns implicit, unquantified risk into explicit, quantified project Work-units.
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.
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.
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. So, we also contracted with a vendor to build an assembly of single-extrusions. Here, there was no extrusion risk, per se, but a risk that the components could not be assembled reliably or cost-efficiently.
Product Risk: The likelihood that the product design will not meet its specification.
Project Risk: The likelihood that a Project Task will take much longer or cost much more than planned.
Premortem: A really useful technique for identification of product and project risks.
One thought on “Critical Action Planning – How To Manage Both Product And Project Risk”