{"id":60562,"date":"2022-02-17T03:00:29","date_gmt":"2022-02-17T11:00:29","guid":{"rendered":"https:\/\/www.jamasoftware.com\/?p=60562"},"modified":"2023-01-12T16:47:37","modified_gmt":"2023-01-13T00:47:37","slug":"requirement-debt-a-medical-product-program-risk","status":"publish","type":"post","link":"https:\/\/www.jamasoftware.com\/legacy\/blog\/requirement-debt-a-medical-product-program-risk\/","title":{"rendered":"Requirement Debt\u2122: A Medical Product Program Risk"},"content":{"rendered":"

\"Requirement<\/p>\n

In this blog, we discuss key takeaways from a recent whitepaper, written by Ivan Ma, discussing Requirement Debt\u2122.<\/em><\/p>\n

\n

What is Requirement Debt\u2122<\/h2>\n

Requirement Debt is defined as the gap between product requirements + requirement traceability and the perceived maturity of the program + product.<\/p>\n

How Reducing Requirement Debt Reduces Project Risk<\/h3>\n

It is imperative that development teams understand the value of having written requirements early in the process to increase program predictability and reduce downstream risks. The impact of poor requirement definition and closed loop requirements (i.e. traceability) is real and can be significant in time, scope, and cost.\u00a0<\/span><\/p>\n

The holy grail of any program is to deliver a product on time, within budget, and that meets specifications. It is a rather simple measure, with a massive number of variables along the way from concept to product shipped to customers.\u00a0<\/span><\/p>\n

Leadership teams often apply a disciplined program risk management process to identify and be proactive in managing risks that can impact the timely delivery of a product.\u00a0<\/span><\/p>\n

To objectively evaluate which risk to prioritize, the following action table can be used.\u00a0<\/span><\/p>\n

\"Requirements<\/p>\n

 <\/p>\n

Most organizations do not identify requirement clarity and management as a high effort, high impact to the product item, if it is even identified at all. Some organizations believe requirements do not pose a traditional existential threat to the program because the cost of poorly defined or missed requirements is not immediately measurable.\u00a0<\/span><\/p>\n

In fact, some individuals in an organization see requirements management as a high effort low impact activity.<\/b><\/p>\n

\n

RELATED POST:<\/strong> The Costly Impact of Ineffective Requirements Management in the Medical Device Industry<\/a><\/span><\/span><\/h4>\n
\n

The Impact of Requirements Debt on Medical Device Development\u00a0<\/span><\/b><\/h3>\n

Medical product development efforts are often driven by the need to show tangible results. Agreeably, there is nothing more tangible than a physical prototype, functioning experiment on the bench, or an interactive software user interface. However, increasing adoption of the Agile development method encourages bringing tangible demos to potential customers early and often leads development teams to take on Requirement Debt to satisfy short term needs.\u00a0<\/span><\/p>\n

Further magnifying the Requirement Debt issue is the occasional misconception among the team that design control and by proxy, requirements, is the responsibility of the quality group. When in fact, if applying a responsibility assignment matrix (RACI Model), the quality group is accountable for design control \u2014 the one who ensures the prerequisites of the task are met. The rest of the organization (research and development, systems, test, manufacturing, etc.) is responsible for implementing design control \u2013 those who do the work to complete the task.\u00a0<\/span><\/p>\n

It\u2019s absolutely ok and even encouraged during the feasibility phase to build prototypes with no requirements. A smart organization will build prototypes to help clarify requirements. However, as the feasibility phase comes to an end, direct output of the feasibility phase should be a set of draft requirements to enter into the design phase.\u00a0<\/span><\/p>\n

With each successive round of prototyping, requirements and requirements trace should mature just as the product does.<\/b><\/p>\n

If product teams are building prototypes for verification with incomplete requirements, broken loop trace, and TBD acceptance criteria, Requirement Debt is at its maximum.\u00a0<\/span><\/p>\n

The smaller the Requirement Debt gap, the higher probability of a successful product launch.<\/b><\/p>\n

\"Requirements<\/p>\n

\n

RELATED POST:<\/strong> Medical Device Startup, Proprio, Chooses Jama Connect\u00ae to Drive Innovation<\/a><\/span><\/span><\/h4>\n
\n
Per 21 CFR Part 820<\/a> Subpart C, manufacturers of Class III, Class II, and some Class I devices \u201cshall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met.\u201d <\/em><\/h5>\n

The following are direct excerpts from 21 CFR Part 820<\/a> Subpart C:<\/p>\n

(c) Design input.<\/strong> Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.<\/p>\n

(d) Design output.<\/strong> Each manufacturer shall establish and maintain procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements. Design output procedures shall contain or make reference to acceptance criteria and shall ensure that those design outputs that are essential for the proper functioning of the device are identified. Design output shall be documented, reviewed, and approved before release. The approval, including the date and signature of the individual(s) approving the output, shall be documented.<\/p>\n

(f) Design verification.<\/strong> Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF.<\/p>\n

The code of regulation is very clear about the role design inputs, design outputs, and design verification play in design control.<\/p>\n

To learn more about the value of proactively writing traceable requirements, mitigating costly late-stage changes,\u00a0 and the benefits of proactive traceability, download the full whitepaper.<\/a>\u00a0<\/em><\/p>\n

READ MORE<\/h4>\n
\n

<\/p>\n

<\/div>\n