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.
All the frameworks mentioned highlight how important it is to slow down and really understand the problem before making a decision under pressure. I think one key takeaway is that it's not just about choosing the technically correct fix, but also about understanding the ripple effects across the entire project. Even a small tweak could have unintended consequences if it's not fully understood. In regulated industries, it seems like the safest route is often the one that introduces the least change late in development, but that only works if the team has a solid grasp of the root cause. Clear communication with stakeholders using tools like decision trees can help make sure everyone is on board with the risks being taken
One way to deal with this kind of situation is through project execution and project control․ During project execution, the work contained in the work breakdown structure is performed․ Progress is monitored, and if performance deviates from the project plan, corrective action is taken to bring the project back into alignment with the plan․ When a biological compatibility issue appears late in development, the project team is essentially facing a situation where the work results no longer match the planned outcome. The next step becomes determining which corrective action can bring the project back in line with the plan while causing the least disruption to schedule, documentation, and regulatory commitments.
A practical way to evaluate the decision is to determine where the problem originates. If the problem relates to a manufacturing process parameter, such as the thickness of a coating or the curing process temperature, it can be solved through changes in manufacturing rather than design․ This path usually protects previous verification work and avoids resetting regulatory documentation. However, if investigation shows that the design output itself is responsible for the problem, continuing to adjust the process may only hide the underlying flaw. In that case a design change may be necessary even though it could require repeating verification and updating documentation.
Another way to understand this trade off is to think about diagnosing a car problem. If a car begins running poorly, a mechanic first checks smaller adjustable elements such as spark plugs, fuel mixture, or sensor calibration before replacing the entire engine. Replacing the engine might eliminate the problem, but it would create major cost and downtime if the root cause was actually a minor adjustment. Product development teams face a similar decision when choosing between modifying a process parameter or redesigning part of the product.
Communicating these options clearly is also important. Showing stakeholders two possible paths can help them understand the consequences. One path outlines the timeline and regulatory effects of a design change. The other path explains the expected outcome and risk of adjusting the process. By displaying both cases, the stakeholders see that any decision involves balancing technical reliability, schedule pressure, and business impact.
A useful question to consider is how teams determine when a process level adjustment is sufficient and when the evidence shows that a deeper design change is the safer long term solution.
Late stage decisions in development require carefully evaluating both the technical problem and the overall impact on the project. During the executing phase, teams are expected to monitor progress and implement corrective actions or change requests when something does not align with the project plan. Because of this, it is important to first understand the root cause of the issue before deciding whether the product itself needs to change or if the manufacturing process can be adjusted instead. Teams should consider factors such as regulatory implications, additional testing requirements, timeline delays, and business risks. Clearly explaining these trade-offs to stakeholders helps ensure everyone understands the reasoning behind the decision, especially when the project is under pressure and uncertainty remains.