How can IVD manufacturers avoid product development process mistakes that result in poor designs, cost overruns and delayed time to market?

Strategic Program Management is a development approach focused on continually identifying and mitigating technical and commercial risks while allowing flexibility to change and adapt the program strategy to deliver the best outcome. It has proven to be an effective method of delivering successful products to market within cost, schedule and resource parameters.

The risk mitigation aspect of Strategic Program Management can be perceived as somewhat negative given the focus on, “What can go wrong?” However, when well executed, this approach is designed to not only ensure a positive outcome but can foster innovation and improved product design.

Based on our experiences, below are eight key components for effectively managing risk throughout the IVD product development process as part of a Strategic Program Management approach.

It is critical from the very beginning to look at things from an end-to-end perspective and create a development road map that aligns with the “big picture” project objectives.

After your core technology has reached the necessary level of technical maturity, take a step back and invest time upfront to define the product requirements, basic project architecture and infrastructure necessary for successful implementation. This process should include identifying the associated risks (both technical and commercial), as well as the sources of those risks. This information helps to decide where and when to invest resources and effort, and to identify potential early-stage strategic actions to overcome some of those risks.

Once the risks have been identified, prioritize them by evaluating their severity in relation to the project outcome and the potential rate or likelihood of occurrence. If a risk affects the core technology, this may have implications in ultimately being able to achieve the project objectives and needs to be assessed from the beginning.

Finally, frontload the project schedule with those riskier activities (e.g., if a given risk is on a critical project path or if its impact duration is significant) to allow more time for resolution.

Creating an environment of trust and transparency within the project team is a foundational building block of successful Strategic Program Management. By creating a safe haven, you will encourage more effective collaboration and communication and help ensure risks are escalated appropriately from the bottom up.

• Overcome the natural tendency to avoid talking about risk and challenges by setting a tone where the team is comfortable regularly asking the question, “What could go wrong?” Lacking a safe environment, people will be afraid to speak up and escalate something that might be a true risk.
• Guard against being critical of people or asking questions in an accusatory manner. When things are not going well, strive to curb the “blame game” and not taking ownership of outcomes. Without this, issues will not be raised, discussions will be muted, and opinions will not be offered which can ultimately stifle problem solving and creativity.
• Instill a feeling of empowerment by encouraging the team to challenge assumptions, raise creative ideas and make decisions. This allows the strengths of the entire team to be leveraged, often coming up with clever and unique ways of doing things that one person wouldn’t necessarily have the capacity or capability to deliver. Furthermore, challenging constraints found to result in a risk can potentially eliminate the need to resolve that risk altogether by making a trade-off early in the process.

Establishing regular and routine venues and leveraging visual management can help encourage team discussions around risk mitigation. One approach is to institute a risk management forum that provides the team with a dedicated framework for asking questions and discussing risk.

When establishing a risk management forum, you should consider the following best practices:

• Encourage all project stakeholders to participate so teams can get buy-in on their recommendations and secure the resources needed to work on a particular problem.
• Focus the discussions and hone in on those things that are really challenging the program and the greatest value to address. This will result in more practical discussions within the team identifying and resolving risks.
• Set ground rules to foster engagement. This is particularly important in those meetings with a senior presence, where the questions that are asked and the tone that is used will persist within the program long after people leave the meeting.

Using established tools provides a framework for identifying all types of risks and the associated issues – functional, safety, design, etc.

A variety of tools are available for both identifying and managing risk at multiple levels throughout the program. For example, Failure Mode and Effects Analysis (FMEA) is useful for managing technical risk, while its extension Failure Mode, Effects and Criticality Analysis (FMECA) is applicable for managing hazard risks to patients and operators.

One simple and fundamental way to capture risk is by creating a risk watchlist. Start by breaking down a project into its functions or steps and asking the question, “What could go wrong?” That can be quite easy to answer for known risks that have quantifiable impacts; however, the key is to similarly apply this analysis to known risks whose impacts are not clearly defined or are completely unknown. In these cases, the team needs to imagine the next things that could go wrong. This type of deep review can put the team ahead of a risk by mitigating it before it starts happening.

Structured identification helps make the distinction between an actionable risk and a fear since it can be a natural tendency to go overboard. For example, there is always a fear that something might fail, but that is not defined or specific enough to be considered a real risk to the project.

Risks should be prioritized by mapping their severity relative to the project or the user. Considerations should also include whether the risk affects the core technology, market viability or product launch timing.

Prioritization can be done systematically by rating each risk using three distinct parameters (severity, probability and detectability) and combining the scores to determine a risk priority number.

1. The severity or potential impact a risk might have. When looking at impact, broad level categories include cost, schedule, scope, quality, customer usability and product reliability. The team can define the guidelines and scale to be used for the specific project, but typically, the bigger the impact, the larger the value.
2. The probability of occurrence. This should be ranked as a percentage from 0 to 100, taking into account when and how often a risk is realized and becomes an issue. “Is it likely to happen 1 in 1,000 times or 1 in 10,000 times?”
3. The detectability. When it is a technical risk as opposed to a program risk, detectability can be determined. “How likely is a user or the instrument going to detect that the risk has occurred, and prevent it from getting too severe?”

Mapping risk priority numbers provides a good starting point for prioritization. For example, if severity and occurrence are both rated a “5” using a scale of 1 to 5 (with 5 representing the greatest impact), those rankings are multiplied to generate a risk priority number of 25, placing it as one of the first things to address.

Within the full range of risks on the program risk watchlist, the top five items based on their risk priority numbers are identified for the project team to focus on with a sense of urgency and drive out of the program. Progress is reviewed weekly; decisions are also made, and new problems are raised at that time.

Visibility through metrics is key to ensuring that risks are being appropriately managed and should exist in a structured way throughout the process. This routine practice starts with daily management and weekly risk reviews, rolling up into monthly steering committee and quarterly project reviews, and culminating in a stage gate review. A metrics-based assessment at each of these levels is crucial to ensure that, when a stage gate is reached, risks are already under control. Considering risks at that point is too late.

Structured visual management tools are valuable in supporting this metrics-based process by helping communicate where and how bottlenecks are occurring in a process, prioritizing and escalate risks that are unnecessarily stalling the program, and exposing previously unidentified risks. Visual management can take the form of burndown charts (a run chart of work left to do versus time). The project risk watch list can also be translated into a wall-mounted progress board, or Kanban. Both examples can be posted in a central location for weekly team stand-up reviews of what needs to be delivered technically against a key set of criteria.

The DIVE (Define, Investigate, Validate, Ensure) method for problem solving can be applied during these routine reviews to help guide discussions:

• Define the risk.
• Investigate and develop proof of concepts or countermeasures.
• Validate their effectiveness by testing or trialing to see if they have the expected impact.
• Ensure sustainment by continued monitoring. By keeping a watch post-implementation for some period of time, perhaps a few months, the team can make sure that the issue itself has been properly addressed rather than just its symptoms.

Investing time and effort upfront on Defining the risks, enables the team to start the Investigation phase of the DIVE process. This calls for targeting a very specific problem with a clear definition of acceptance at the end, while at the same time exploring and Validating solution options.

Below are some best practices to consider as the team investigates and validates solution options.

Permit people to develop a hypothesis, do proof of concept testing and trial different ideas to see what impact they might have on the risk. Encouraging experimentation within the team to look at options and alternatives is really the point where innovation and creativity are unleashed.

Employing an ideation methodology when a new risk with new technical constraints arises can help get the process unstuck. During ideation sessions, the team brainstorms different ways of attacking the problem. Proposing multiple solutions in this setting may result in bringing together different technologies in novel ways to solve the problem.

Rather than pursuing a single solution to discover it doesn’t work, best practice is to keep multiple options open and rapidly test them to get quick answers by “failing fast.” This provides flexibility to change approaches as needed and arrive at a best-case solution.

A critical component of a project’s success is understanding how much flexibility is needed while still maintaining stability throughout the process. Both over- or under-constraining the project too early can result in a poorly constructed foundation and reworking defects or significant changes later in the schedule. By striking the right balance, the team can evaluate different options against certain criteria that are important to the project at the time.

In these instances, a trade-off study framework is a useful tool to guide stakeholder decision-making. For example, Options A, B and C are rated against the criteria for their impact on cost, schedule and achieving the product requirements. The outcome may be that Option B is the right compromise because, while it might have a moderate impact on costs, it’s the best choice considering schedules and technology.

The tendency is to view risk assessment and mitigation as a process focused on the negative. However, just as assessing risk focuses on problems and constraints, it also can uncover or highlight opportunities. Being presented with a challenge can often stimulate new and creative thinking.

One way to focus on the positive is to cultivate a coaching atmosphere. It is natural for frustrations to grow when breakthroughs are not happening, or the team feels like it is not making progress. Take the time to tackle this head-on by acknowledging these challenges and flipping the thinking to one that focuses on practical discussions. Encouraging the team at these moments to continue their “outside the box” thinking can produce surprising results. Just when it appears like a “Mission Impossible,” this approach can drive more creativity and innovation to yield great improvements.

Remember to continually celebrate progress. The duration of IVD product development projects can span years. This makes it difficult at times for the team to perceive that progress is being made, so it is very important to formally recognize even the small achievements. For example, the DIVE process offers opportunities at each of its four checkpoints to celebrate progress, rather than waiting until an issue is resolved. Doing little things every time a risk moves from one stage to the next can give the team a sense of achievement.

Effective risk management for IVD product development is an ongoing, daily process. It starts by taking a step back and looking at things from an end-to-end, “big picture” perspective, and is implemented using a systematic approach including visibility through metrics to ensure that risks are being managed appropriately throughout the process.

Managing risk this way from the beginning ensures that the team travels down the right path, rather than arriving at the project completion date and discovering risks that have gone unaddressed. The objective is to provide a level of assurance that the final project stage gate review is more of a formality. Otherwise, it’s simply too late.

When well executed, Strategic Program Management is designed to not only ensure a positive outcome but can foster innovation and improved product design.