Managing evolving requirementsVery few first product realization versions meet the expectations of end users. That is normal and should be anticipated and addressed with “enterprise business agility.” Managing evolving requirements is now a core competency given our changing business requirements (and technical specifications) based upon a better understanding of the likes, wants and dislikes of health care professional end users and medical device purchasers.

While working in Health Care for over twenty years I have noticed a trend of improving the requirements gathering phase to shorten product development and prevent unnecessary re-work and associated costs. This blog outlines the three main phases of product requirement evolution for a successful medical device productization.

Phase I – Product Concept with Business Vision

A product idea emerges from observing an inefficient process or using a poorly designed instrument. That idea ignites a business opportunity for an enhanced product, a replacement technology, or a completely different approach (e.g. new therapy). Part of creating a business plan is to document business requirements with a description of functionality and proposed user interface, all of which take into consideration the targeted market.

Phase II – Technical Specifications with System Integration

The concept is presented to a technical team for review. Each technical expert (architect, software engineer, mechanical engineer, industrial designer, etc.) will have questions when thinking about technical specification, integration, and constraints. These questions help clarify the product vision. Is the product to be used in community hospital or large tertiary centre? Is it for a single or multiple users? Is there need for data upload? Would the system be able to recharge overnight or it is used 24/7? And so on. As a result of healthy discussion between the product owner and the technical team, the business advantage is reviewed and product requirements are updated.

Phase III – Functionality Adjustment with Sensible Product Launch Strategy

The product design and development cycle begins with great optimism and velocity, and project funding and time are burned in good faith. First generation prototypes land in the hands of investors and first-time users for the much anticipated product review. Design feedback arrives and the need for additional requirements becomes apparent; the very nice first product version has gaps in required functionality, difficult ergonomics and challenges in anticipated manufacturability. That is normal and should be anticipated.

The concept of product requirement evolution is borrowed from software agile development to rapidly integrate features that users did not know they wanted in the first place. When developing an idea for the next great medical device, remember to include input from end users and technical experts as early as possible and expect several cycles of requirements iterations.

Martine Janicki was our first full-time Project Manager and PMO. She has a wealth of experience in the Project Management world, specifically medical devices and healthcare, and her education is in Mechanical and Biomedical Engineering.

 

 


2 responses to “Managing evolving requirements to improve medical device design”

  1. Hi Martine,

    I’d like to hear your thoughts about implementation of requirements changes across the phases – it becomes tricky late in the race, but is really a desired occurrence early on that should be encouraged.

  2. Martine Janicki says:

    Hi Bruce,

    You are right about costly changes later on in the product design cycle, the cost of change is minimal at the product definition stage and increase significantly at the implementation stage. I encourage planning for a conservative (lengthy) requirement period so stakeholders have time to think about the product /program /service vision thoroughly.

    I consider the requirement document to be dynamic and evolving until the first prototype is distributed, and I book frequent check points to run use cases scenarios. Later on in the project cycle, I conduct impact analysis on late coming requirement request for basic project elements (quality, timeline, cost) and introduce a formal review and decision making process.

    Finally, I encourage the sponsor to consider signing up for a program including a number of releases / products with increasing functionality so they can be in the hands of the end users for a period of time and settle on the “right” requirements.

    Hope that helps, and good luck!
    Martine

Leave a Reply

Your email address will not be published. Required fields are marked *