Incorporating review meetings throughout the project stages is highly recommended for monitoring, and auditors can request a review of the quality of this information. These meetings can be used to discuss or approve change drafts, or reveal changes that need to be considered for implementation. If the board requests a change, it can initiate updates to the project plan. Ultimately, the organization has procedures for implementing change, whether related to engineering or to other procedures within the organization. The change needs to be submitted to the team for approval. If approved, the documentation process may include completing master forms to record justifications, training, effects, or regulatory impacts. Often, the changes are linked to a corrective or preventive action that has its own procedure. The change may require additional validation and verification, but it will prevent performance deficits. Having logs of documents and engineering changes to track their approval statuses is another helpful tool to maintain. Furthermore, the manufacturing process may correlate with the development. Changes to the BOM or other manufacturing documents that impact production can require a design change number for organizations. 

I think monitoring should not be treated as checkpoints, but instead be a system where you can stay up to date on how the project is going and predict roadblocks from the start. Dr. Simon always talks about feedback loops for project management, and monitoring is a feedback loop where you look at outputs and then adjust the inputs accordingly. If you make these changes early on, large issues down the road can be prevented. Thus, it is important to track indicators of larger issues. Seeing larger error rates or small inconsistencies in early design prototypes, for example, should be addressed sooner rather than later so the project doesn’t face a larger and more expensive issue down the line. This also requires flexibility in changing the schedule or project. The cost of change depends on what phase of the project you are in, and changing during the earlier phases before they close out is much less expensive than trying to reopen documentation to reopen a closed phase for change. Thus, ensuring you treat monitoring as a feedback loop is crucial to save money. 

To properly monitor, you can use traceability matrices where every requirement maps to a test. I have used this for my capstone project, and it has helped ensure that we stay on track and do not miss any crucial requirements from the stakeholders. If a change occurs, it is very easy to see exactly what needs to be updated afterward. Additionally, ensuring that all your documents have version control is essential since sometimes you have to go back to a previous model when the new one turns out not to be as expected. It also helps to compare a newer and older system side by side in parallel testing. 

Ensuring that implementing changes without leading to progress loss can be done with parallel work, where a part of the team implements a change while the second part works on keeping the project going forward. This helps ensure that delays do not happen. Having meetings for this to specifically lay out what needs to be done is very important, allowing the team to work smoothly. With design changes, however, how do you decide what the minimum amount of re-testing needs to be done to ensure the change was successful? Do you think parallel testing with old and new models should also be conducted as a mandatory requirement with change, or is it too resource-intensive? Lastly, at what point does monitoring become counterproductive? 

As a project manager, there are several tools and practices I'd use to thoroughly monitor the device throughout development, including regular status meetings with clear agendas focused on progress against baseline, variance analysis to track schedule and cost performance using metrics like earned value management (EVM), milestone reviews at key decision points, risk register updates to track emerging issues, and quality audits to ensure design controls are being followed properly. For medical device development specifically, I'd implement design reviews at each phase transition, regular design control documentation checks to ensure traceability between inputs and outputs, and frequent check-ins with regulatory and quality teams to catch compliance issues early before they become expensive problems. When the board mandates a change from the baseline, I'd follow a structured change control process: first, fully document the requested change and its rationale; second, conduct an impact assessment analyzing how it affects scope, schedule, cost, quality, and risk across all work streams; third, involve the relevant subject matter experts (like Derek for animal studies or Chris for manufacturing) to understand technical feasibility and resource implications; fourth, present the findings back to the board with options and recommendations, including any trade-offs required to accommodate the change; fifth, once approved, update all project documentation including the WBS, schedule, budget, and design documents to reflect the new baseline; and finally, communicate the changes clearly to all stakeholders and team members so everyone understands what's different and why. To prevent significant deficits in product performance, the key is ensuring that any change goes through the same rigorous evaluation as the original design running it through risk analysis, potentially requiring additional verification or validation testing, and making sure it doesn't compromise critical design inputs or regulatory requirements, even if that means pushing back on the board with data showing why certain changes would be problematic. Other processes that occur throughout the product development lifecycle in parallel with monitoring and controlling include the execution processes (actually doing the work), continuous risk management (identifying and mitigating new risks as they emerge), stakeholder engagement and communication (keeping everyone informed and aligned), quality assurance activities (ensuring processes are being followed correctly), team development (building skills and improving collaboration), and procurement management if you're working with external suppliers or contractors. These processes all interact with and inform the monitoring and controlling process for example, execution generates the performance data you monitor, risk management identifies issues you need to control, and stakeholder communication ensures you're getting feedback that might trigger corrective actions. The recursive nature means you're constantly cycling through plan-execute-monitor-control across different aspects of the project simultaneously, with information from one process feeding into decisions in another, which is why project management can feel like you're juggling multiple priorities at once but also why having structured processes and clear communication channels is so critical to keeping everything coordinated and moving forward.

Treating monitoring as a dynamic and on-going process is one of the best methods for a PM to catch any deviations early, when corrective actions are cheaper and less disruptive to the overall workflow of the project. Tools like earned value management and traceability matrices are very useful in this manner, by providing quantifiable data and ties project performance back to the original outlined plan. Especially in our field of medical device development, maintaining tight traceability between design inputs and outputs is not just a best practice, but a regulatory expectation. Regular design reviews at consistent points within the project timeline create a structured rhythm for identifying issues before they compound into larger problems. As dev noted, the cost of change scales significantly with the phase of the project, making early detection an intervention of the highest return investments that a PM could possibly make. 

When the board mandates a change from the baseline, the structured change control process outlined by Nevin, captures the essential steps as well. The critical piece that often gets overlooked, however, is the impact assessment phase, specifically ensuring that all downstream dependencies are mapped before approval is finalized. A change that seems minor in scope can have cascading effects on verification and validation activities, regulatory submissions, and manufacturing documentation, such as the BOM. AT644 even highlights this point, linking changes to corrective or preventative actions and maintaining detailed change an paper trail suitable for audits, properly protecting the team. Ultimately, the monitoring and controlling process works best when it is deeply integrated with change management, risk management, and stakeholder communication, creating a closed loop system where information flows freely across all workstreams. 

I like the points about traceability and feedback loops, but one thing I think is also important is the use of real-time monitoring dashboards and leading indicators, not just lagging ones like completed milestones or errors. For example, tracking trends such as increasing response times, small deviations in test results, or delays in intermediate tasks can help identify issues before they become major problems.

In terms of implementing changes from the board, I think something that could strengthen the process is impact simulation or scenario modeling. Instead of only assessing impact qualitatively, teams could model how a change affects timelines, resources, or downstream testing to make more data-driven decisions before approval.

Also, something I’ve been thinking about is how to balance thorough monitoring with efficiency. At what point does too much documentation or tracking start slowing down progress rather than helping it? It seems like finding that balance is just as important as the monitoring itself.