Musings on Risk

I have been thinking about the Risks inherent in Product Development: I have found that it is useful to think of risks as a Risk Stream that is a NECESSARY and CONSTANT product of New Product (or Feature) Development. There is much discussion and thought about the Value Stream. Obviously, this is why you do product/feature development, to add value to your clients and to your business. (And one of the underlying tenets of Agile Methodology is to optimize and maximize this Value Stream.)  

But, the Risk Stream is UNAVOIDABLE: By introducing the very change that produces value (whether that be a new product, or a new feature in an existing product), you will introduce risks. And this Risk Stream is generally thought about and talked about, much less explicitly, if it is addressed at all.  

Just as every change can introduce additional value into the Value Stream of the product, EVERY change also introduces additional risk into the Risk Stream. The two streams are inseparably linked. And failure to pay attention to these risks will sink the potential value of the innovation.

Some thoughts on the Risk Stream, in no particular order:

·       Left unmitigated, the Risk (defined as Likelihood times Impact), will increase with increasing value introduction.

·       Risk must be ACTIVELY managed (through mitigation or avoidance plans), or it will persist into production, and affect the business.

·       BTW, Mitigation is technically a set of actions designed to reduce the IMPACT of the risk, while Avoidance is designed to reduce the LIKELIHOOD. In actual practice, both are commonly referred to as Mitigation Plans.

·       One key factor in the choice of mitigation strategy is the cost of mitigation. 

·       To this point, contrary to popular opinion, it is NOT always cheaper to mitigate risks earlier in the development cycle, e.g.:

o  Some design risks are cheaper to mitigate with prototyping, in the Development phase, rather than in the Design phase.

o  Performance risks are key to identify in design phase, but are generally cheaper to mitigate in a quasi-production system (in the Test phase) than in Development or Design. (Simulations sufficient for performance evaluation are often very expensive to create and maintain.)

o  In fact, some risks are cheapest to mitigate with real customers. Think beta testing. (Of course, you would generally not want to address high impact risks with customers, especially critical ones.)