Risk Management

[Webinar Recap] Lessons Learned for Reducing Risk in Product Development

By |

reduce risk product development

In this blog, we will recap a webinar on reducing risk in product development

Over the last 20 years, product development complexity has expanded exponentially, creating innovations in areas such as space tourism, autonomous vehicles, satellite communications, and more. In this webinar, Kemi Lewis, Senior Consultant at Jama Software, will demonstrate how Jama Connect© creates Live Traceability™ through siloed development, test, and risk activities to effectively reduce risk in the product development process.

In addition to a walkthrough of the platform and our Live Traceability dashboard, we’ll cover:

  • The critical challenges to reducing risk in product development
  • Why deeming requirements “good enough” to allow teams to proceed with an acceptable level of risk culminates in static requirements, unplanned rework, and compounded product risk
  • How “Project management” activity is a fallacy — it is the management of requirements, people, risks, change, opportunities, expectations, resources, commitment, and suppliers

Below is an abbreviated transcript and a recording of our webinar.

Reducing Risk in Product Development

Kemi Lewis: Today’s agenda covers a deep dive into the critical challenges to reduce the risk in product development, what are the viable solutions to this problem, key takeaways, and wrapping up with a question and answer session at the end of the webinar

Let’s get right into it. What are the main critical challenges that product development teams are facing? In my experience, the main factors that lead to adverse product outcomes and risk are, number one, no upfront and iterative collaboration during requirements and design creation and review stages due to limited customer and cross-functional team involvement in the review and approval of requirements. This lack of cooperation results in missed and misunderstood requirements driving the product design into severely costly errors later on.

Second factor, no digital thread connecting the product and team to the end to end product life cycle process. What do I mean by the digital thread? A digital thread is a data driven architecture that links together information generated from across the product life cycle and is envisioned to be the primary and authoritative data and communication platform for a company’s product at any instance in time. Without this digital thread, there’s no ability to track the life of a requirement through development, test and release.

Related Reading: What Is the Definition of a Digital Thread

Kemi Lewis: This missing digital thread results in static requirement documents rarely viewed by critical stakeholders maintained in Word, Excel or standalone tool used only by a few as a repository. I’ve personally experienced this at companies where only the systems engineers were accessing the repository and the rest of the product development team from product managers down to testing and integration engineers never accessed it.

You can only imagine how this turned out. Countless rework during testing and integration in addition to postlaunch rework this early, which was severely costly to the customer and left them very unhappy. So lacking this digital thread leads to no management visibility into crucial metrics for the end to end process and no identification of process risk patterns, such as delays in development, multiple test failures, rework cycles, etc.

Third main factor is having a low level of requirements management maturity. Let’s discuss this in more detail. Level zero: There are no formal requirements. So no documentation exists for user or system requirements. Instead, development operates off of user stories with no clear distinction between the functionality of the system being built and expected user experience. Level one: Document based requirements. Static requirement documents are created and most often maintained by each author on their desktop with various emails, slack comments containing more information. This especially gets fun when you have to merge 10 different versions of the same document from 10 different people from 10 different timeframes, none of which have visibility to each other’s feedback in real time. I’ve seen this at several companies where they lose technical product proposals due to this inefficiency of being able to get a proposal out in time representing the right design specifications of their product.

Related Reading: Bridge Engineering Silos with Living Requirements Management in Jama Connect

Kemi Lewis: Level two: Siloed requirements tool. A standalone tool in place to draft review, track comments, version and store static requirements documents, compliance steps, limited reuse, defects and recalls. Level three: System based compliance. Compliance is the forcing function to shift from static to live traceability to meet standards for requirement validation, verification and traceability into a single end to end system. Level four: Product risk reduction. A process centric focus to reduce the likelihood of all forms of product risk via a system enabled live traceability. This requires detection and alerts for specification and functional changes, process exceptions and test failures with resulting impact analysis. The risks mitigated include failure to meet the needs of the customer, failure to perform specific functions, delays, cost overruns, defects, compliance and regulatory gaps, delays and fines in addition to recalls.

And the last level of maturity, level five: Development process improvement. Moving past compliance and risk into the spirit of standard based on quality management and process control. These stages place focus on measuring, managing and improving the product development process. The unintended result of this fragmented process is that critical function such of requirement, traceability, verification, validation, risk mitigation, product integration and compliance are often fraught with information gaps, defects, delays, reworks, recalls, missed requirements and significant manual effort. This includes all areas of the complex product system and software delivery life cycle that can experience negative outcomes and should be actively managed to reduce the likelihood of appearance, such as performance.

Watch the full webinar to learn more about Lessons Learned for Reducing Risk in Product Development

Jama Software
Latest posts by Jama Software (see all)