When a potential issue arises near the end of development, deciding whether to modify the product or the process can be challenging. A change in formulation, for example, might fix a biological compatibility issue but it could also trigger the need to repeat Verification testing, delay the launch, reset regulatory documentation, or even risk losing a key client who is counting on the original timeline. In contrast, adjusting the manufacturing process (like controlling coating thickness or curing time) may resolve the issue with far less disruption but only if the root cause is clearly understood and the risk is manageable.
This trade-off highlights a key tension in project management: balancing speed with certainty. Late-stage changes especially in regulated industries require not only technical justification but also cross-functional coordination across quality, regulatory, and business teams. The challenge is knowing how to assess when a change is truly necessary.
How can we approach decision-making in situations like this? What frameworks or criteria could be used to weigh technical fixes against broader project risks? And how can these trade-offs be communicated to stakeholders especially when urgency and uncertainty collide?
A structured decision-making framework like Failure Mode and Effects Analysis (FMEA) can be invaluable when late-stage development issues arise. FMEA helps identify potential failure points and assess their impact on the project, allowing teams to prioritize actions based on risk severity and likelihood. A cost-benefit analysis can also weigh the technical fixes against broader project risks, considering regulatory implications, client expectations, and timeline impacts. Effective communication with stakeholders is crucial; presenting a clear comparison of options, supported by data and potential outcomes, can help align cross-functional teams and ensure informed decision-making. Open-ended questions like, "What are the potential long-term impacts of each option?" can further stimulate discussion and uncover insights that might not be immediately apparent.
As the last post mentions, FMEA is a great and effective decision-making framework to use in such a scenario. It is extremely effective because it presents data to help calculate a risk priority number (RPN). This is an easy way to tell the members in the project what problems require more of a priority and which issues are best left alone. I think pairing this with a risk matrix to help with decision making in a project.
Simulation 3 is a perfect example of a project about to make a successful closing until a major problem occurs. The product passed all in house verification protocols until it was tested by another company. This would lead to a destructive outcome for many stakeholders involved in HydroSurf. That is where risk matrix analysis and RPN can come into play and assess what the best course of action is. If changing the cure time fixes the cytotoxicity, what is the risk in changing it? If changing the coating thickness fixes the cytotoxicity, what is the risk in changing the thickness? These paths may deviate from what was originally planned, but if the risk of changing the products scope and effectiveness is relatively low it may be the best choice for a solution.
When facing a late-stage development issue, one method to consider is using the "5 Why's" Method, where you're keeping asking why the failure is happening up to 5 times to determine whether the root of the problem is due to a product flaw or can be fixed by tweaking the process slightly. This allows full clarity of the issue before deciding to make any hasty, detrimental decisions. To balance the technical fixes with broader projects, you can apply Real Options Analysis, where you work on immediate potential fix which invites risks of not working, but also work on gathering data to keep the other option of having to redesign the product so if there's that the immediate fixes aren't enough, there's still information to start working on the product design. For communicating the methods and trade-off to stakeholders, a visual tool and example scenario for comparisons can be a simple and more digestible way to give stakeholders an idea of what the difficulty is and how it can be dealt with.
To expand on the points above, I would like to add that decision-making in these high-pressure moments can benefit from a multi-criteria decision analysis (MCDA) approach. MCDA allows teams to compare multiple options by assigning weighted values to different criteria such as : Regulatory impact, cost of change, supply chain implications, client/stakeholder trust, etc. Emotion and bias can be removed by scoring each potential solution, think: entire product reformulation vs a small process tweak, across multiple categories. Combine this with providing a transparent rationale to the team, and MCDA is a great option! MCDA can be combined with decision trees integrated with risk scores to visualize outcomes. This is particularly useful in deciding whether to change an entire formulation or just adjust the process. For example, if the formulation is changed, the company would have to redo verification and validation, which delays the product by 10 weeks, which leads to risking the loss of a client. If the process is adjusted, there is minimal revalidation and verification, a minimal delay to the product, and a lower risk of recurrence and losing a client. These tress make it easier to communicate trade-offs to non technical stakeholders by showing different pathways, and not just technical data.
