What stood out to me from this week’s lecture slides is how different project management phases are from design control phases. In project management, the lecture discussed how phases can overlap and blend together, so there is no concrete, clear distinction between one phase and the next. However, for design controls, there is a review meeting that clearly marks the end of the phase. This is where ensuring that everything in that phase is properly done is essential, as going back costs a large sum of money and has documentation and clinical consequences. 

If a PM had to return to a completed phase, I think the first skill they would need is humility. It takes some guts to admit that you messed up and need to back track, and ensuring that one does not let their ego get the best of them is essential to make sure that the transition goes smoothly. The next thing needed is very thorough and structured documentation. Updates must be traceable in the living Design Development Plan. Scope changes need to be recorded and risks must be assessed. There must also be meetings with the stakeholders to ensure they understand why the reversion to previous phases is happening. 

To prevent going back altogether, the PM needs to be very thorough during the design control phase close-out meetings. Everyone should be involved, and all nooks and crannies should be checked. The risk management should be central with ongoing evaluation that allows issues to be caught early, reducing the likelihood of late-stage surprises. Discussions should be active instead of a formality. The initiating phase should have a very strong project proposal and scope statement so issues with the phases can be avoided later on. This would lead to a detailed DDP, DID, and risk plan. Gaps will enhance when details are not clear from the beginning. Everything should not feel like a box that needs to be checked. It should feel active and satisfying, bringing real impact to the project. 

Overall, being rigorous in planning and documentation, followed up by review, will allow issues with going backto previous phases to be avoided. A PM who treats the design control phases as interconnected will be less likely to be blindsided. 

What other ways can issues like this be avoided? Can AI be incorporated into the workflow so that any issues missed by humans can be caught, or will AI lead to more unnecessary discussion and/or laziness from workers? In what ways have you seen proper design control meetings be conducted? 

For a project to return to a previously "completed" phase in the PDCA cycle, a PM needs strong skills in risk assessment, change management, and stakeholder communication. This is an extremely expensive and frustrating process, financially and politically. In such a scenario, it is common for leadership to question earlier decisions and for timelines to be severely impacted. Thus, a PM must be able to objectively conduct reassessments and root cause analyses to ultimately present rework as a quality/risk mitigation effort rather than a failure. Emotional intelligence is critical in this phase, as morale must be reinforced while accountability is still demanded. Structured documentation and traceability can also help teams to efficiently isolate particular steps requiring revision rather than relaunching entire phases. 

To minimize the risk of revisiting phases, a PM must maintain clear exit criteria, rigorous reviews, and cross-functional sign-offs before marking a phase as complete. This would include validating assumptions early, engaging downstream stakeholders during upstream planning, and performing risk workshops to predict failure points. Based on this discussion, I am wondering if anybody has experience with how project managers help their teams balance the pressure to comply with aggressive timelines with the need for thorough validation at each stage?

As Dev said, there should be multiple design review meetings and controls such that there is no need to return to a completed phase. If a PM and their team are thorough, and the proper design documents have been maintained and followed, there should be minimal chance of having to redo part of a project. In the case of having that big of a setback, there would be massive issues for the company as that sort of major delay would be costly both internally and with the device customer/shareholders who have been promised a certain timeline. Frequent reviews of the device, associated documents, and compliance to both FDA standards and customer needs are key to quickly catching oversights. To answer Dev's question, I think that AI may make employees lazier. They may not double-check their work to the same extent, assuming AI will catch the mistakes for them. AI, at least as it currently is, is also known for making significant mistakes because it can only make "decisions" based on the data it is fed. AI may, in the future, be helpful for device testing and simulations, but I think it would be incredibly dangerous if AI were to replace any part of the design and testing process.

I really liked everyone’s points about documentation and risk management. One thing I’d add is the importance of continuous feedback loops within each phase rather than relying only on formal phase-gate reviews. If “Check” and “Act” are happening throughout the process, issues are caught earlier and are less likely to require a full phase reversion.

I also think psychological safety matters. If team members feel comfortable raising concerns early, even if it slows progress, it may prevent much larger setbacks later.

Regarding AI, I see it more as a decision-support tool and not a replacement for human judgment, especially in regulated environments. Do you think companies sometimes avoid going back to earlier phases because of optics or sunk cost pressure, even when it might be the safer decision?

As others have mentioned, a methodology for design review can be crucial when assessing changes from a completed project. A perspective that can also be considered is the importance of decision structures. This structure can relate to distinguishing between a reversible and irreversible decision in a PDCA cycle. A successful PM doesn't only focus on the completion of the phases, but they continuously identify if the decisions are of high cost to reverse or move backwards. A PM will ensure that decisions are supported by evidence and data before a conclusion. On the other hand, a PM who takes their time and delays irreversible commitments until there is enough data is able to reduce the chances of needing to revisit the decision that was made. The ability to understand early assumptions that can evolve downstream in a project and how a risk may amplify if it is not validated is crucial.
Furthermore, a PM can also garner the practice of developing knowledge based milestones instead of schedule time based milestones. In many teams, phases of a project can be completed early on or later, it is essential for uncertainty to be reduced based on data. A PM should consider the unknowns in the project and if there is sufficient data or evidence to resolve the challenge. Therefore, this mindset could lead to more testing, simulations, and fast prototyping before determining something as complete. Emphasizing the reduction of unknowns instead of moving forward based on a timeline can allow a PM to ensure each phase has data driven decisions. It is also important to question if most projects in industry prioritize collecting sufficient data before continuing or if meeting timelines is at the highest priority. How does a PM successfully balance competing priorities and deadlines before ensuring a project is finalized?

Dev's point about humility is a really substantiative topic that I think needs to be addressed more in actual practice. A PM who has the humility and confidence to say a phase needs to be reopened, without getting defensive or dismissive is not only an effective one, but a responsible one. Especially in a field with regulations as rigorous as medical devices, letting an ego overrule flaws can lead to negative consequences in the long run, not only for the patients who use them, but the company and team who developed and manufactured them. Especially in the field of engineering, people who develop and create new prototypes (or anything for that matter) take great pride in their work and often will take an criticism or failure personally. A PM who is able to separate themselves from that thinking and look at criticism or failure and turn it into actual productivity can become extremely effective and can actually be what a project needs to properly move forward, and can be infinitely more valuable than one who lets things slip for the sake of feeding their ego. And the point that is made on traceability and stakeholder alignment is exactly what prevents rework from turning the entire project into chaos.
Then to answer a point about balancing speed vs. rigor, the solution is not about choosing one. If you can front load risk identification and high uncertainty assumptions early, aggressive timelines can be met properly when the projects overall uncertainty is systematically reduced. 

There is an appreciation to what is being said about having an emphasis on humility, documentation and risk management. I agree in regards that emotional intelligence is important when a phase needs to be reopened as well. In medical device development, revisiting a phase could be easily framed as failure, but a strong project manager could reframe it as risk mitigation and patient protection. In regulated environments, protecting safety and compliance should always outweigh the optics or schedule pressure. Additionally, in regards to AI, it should function as a decision supporter rather than a decision REPLACEMENT. In medical devices, AI could help flag inconsistencies in documentation, traceability gaps or even highlight risk patterns across similar projects. Ultimately, responsibility and judgment should remain human. An overreliance on AI could create complacency and a common saying I used to hear is, "complacency kills." Thoughtful integration could strengthen the review process without replacing accountability.

Additionally, in order to balance aggressive timelines with thorough validation could be using front loading risk and assumption testing, as mentioned before/ If there are high uncertainty elements that are validated early, the later phases can be able to proceed with more confidence and less reworking.

Dr. Simon’s point about the PDCA cycle highlights one of the hardest realities of project management: once a phase is closed, the cost of reopening it increases exponentially, especially in regulated environments. When a PM must return to a completed phase, the most critical skills are change control discipline, risk reassessment, stakeholder alignment, and structured impact analysis. A PM needs the ability to quickly evaluate how the change affects scope, budget, schedule, regulatory documentation, and downstream deliverables, while maintaining traceability and clear communication across cross-functional teams. Emotional intelligence and conflict management also become essential, since revisiting prior decisions can create friction or defensiveness among team members. To minimize the likelihood of reopening phases, strong upfront planning, clearly defined phase exit criteria, formal design reviews, robust risk analysis, and documented verification of deliverables are key practices. Embedding quality checks and stakeholder sign-offs at each gate ensures that completion is not assumed but validated. Ultimately, while it’s impossible to eliminate all rework in complex projects, disciplined governance, thorough documentation, and proactive risk management significantly reduce the probability—and impact—of having to revisit prior phases.

@dev-doshi Very valid input. However, to comment on one of your suggestions, in order to make the 'nooks and crannies' check easier, the team should be aligned and clear on what their roles and expectations are. The PM needs to ensure that they regularly follow up with the team and quickly provide support whenever/if ever any obstacles are faced. This, in a small way, would help ensure that the cycle in the project process is not repeated again and that mistakes would be caught early on.