The kind of problem that throws things out of schedule dictates the response. Before jumping to discussing the approach, one concept I feel is important to be aware of is the part of the PM's role in a project. When creating the project schedule and the Gantt chart, they need to put in extra time to allow for delays. If there is extra time baked into their schedule, it helps mitigate and sometimes prevent the overall timeline from being delayed.
That being said, not every problem can be accounted for in this way. Sometimes issues are unforeseen. If a machine were to be down, the teams best option would be to look for a work around. Do we have a duplicate that can behave similarly? Can we pay to have it done elsewhere if the cost<benefit of having it done in time. In the case of other scheduling issues we sometimes unfortunately have to present the situation as it is to the customer and inform them that we won't be able to meet what was agreed upon. To help smooth this, we need to ensure that we keep consistent communication with the customer and updates on the situation throughout. 

In one situation I encountered, my team was working towards a hard regulatory deadline for FDA submission. Initially, as in most engineering projects, there was a built-in buffer time that made the timeline feel manageable. However, right at four weeks before submission, an issue emerged from verification testing. The measurement system we were relying on had failed and could not produce reliable data. Since the system was essential for our validation process, the team needed to work efficiently to prevent the submission pathway delays, which can be costly to the project. As a project manager, it was essential for the first step to be escalation; ensuring that engineering leadership, R&D, quality, and manufacturing were immediately aligned on the severity of the issue had been crucial to prioritize resources and expedite the solution process. Structured problem solving using root cause analysis allows there to be an improved understanding of the failure and if it was system or process related. At the same time, parallel recovery pathways were developed, such as reaching out to external sites to identify a measurement system that matched our specifications to be leveraged under our constraints. Before implementing the solution, there were revisions and approvals needed to be made to meet quality requirements. Ultimately, the team was able to recover within the four-week window due to the engineering team's effort, cross-site collaboration, and rapid validation work. The role of a PM is fundamentally about communication flow, escalation timing, and ensuring that problem solving can be facilitated across engineering, quality, and operations. In situations like this do you think it’s better to take extra time to ensure long-term system reliability or focus on efficiency to meet the hard deadline?

I like the questions that mmk68 poses, as this is a real issue that I have seen and encountered before. The first step to preventing major damage from a delay that is out of your control is for the PM to build a lot of buffer time into the initial scheduling and Gantt Chart. This buffer time is meant for such delays. However, sometimes the delays are longer than anticipated, and this necessitates the team to think creatively to work around the delay that is out of their control. 

An example that comes to mind is my capstone project, for which we had to design calibration washers for an existing haploscope and eye tracking system. These washers were meant to have fixed diameters to test if the readings from the haploscope were accurate, mimicking a real pupil. We had finished the code for the calibration module and needed to actually develop the calibration washers to test the system. The washers were supposed to be resin printed, but we encountered a delay in which the resin was not arriving for two weeks. These delays were completely out of our control, and we had to keep the project moving forward for our midterm presentation. Instead of panicking, we thought of alternative solutions to at least get a test in for the system. The reason for using resin was for the accuracy of the printing, which is something we needed for the test. However, we realized that we could do a preliminary test with regular PLA printed washers with a new, quick design and then do a second test with the correct material. This led to the delay change from 2 weeks to just a couple of hours, allowing us to finish a test before our presentation. The new washers had size inaccuracies when we measured the physical dimensions, which was another issue that arose from our alternative solution. We embedded these inaccuracies into the new code, seeing if the machine could give the correct output pupil diameters with weird numbers. This solution worked, and we saw how accurate the system really was, and it gave us an alternative way to test the system as well. 

Even though this example is not as involved as a delay in industry, it showed the bare bones of dealing with an issue. Alternative paths have to be found in order to ensure that precious time is not simply lost. Additionally, hidden opportunities were discovered from a simple delay. We found a new way to double/triple-check our module. A longer delay could provide opportunities to strengthen other areas. For example, if there is a delay in a material, then the team could spend time updating documentation and making sure other areas of the project are strong. A delay also shows where the project schedule is the weakest and what needs to be done to prevent an issue like this from arising again. Our parallel validation strategy allowed for flexibility and progress, saving us from a disaster. 

With our delay being from a shipping issue overseas, I started thinking about the current state of the world. With the more volatile political environment around the world today, how do you think projects will be affected? What delays could happen, and how do teams prevent those delays by staying up to date with the news? Have you faced issues and delays due to what was happening in the rest of the world? 

I absolutely have encountered this issue during capstone and for my thesis project. In both cases, this involved a machine failure. These issues would have been catastrophic for the project as both a thesis and our capstone were time sensitive projects. In both instances, failure mode analysis was put in place to diagnose and take corrective action against the issue to solve it. This ultimately did not become a major issue in either project as additional "slack time" was built into each project phase to ensure that when issues popped up they could be properly dealt with without derailing the entire project. I think the measures to get back on schedule depend specifically on the project itself, however whenever a issue does arise you need to be ready to pivot and have a plan b. Sometimes getting back on track can mean reducing the overall scope of the project or (if your able to) expand the overall deadline for the schedule. Both have their consequences but depending on the situation one choice may not be as bad as the other. To answer @dev-doshi questions, I think the most obvious issues projects will face will be supply limitations and tariff volatility. I will avoid involving politics too much but we live in a very volatile time where supply chains and resource schedules can be impacted and become unpredictable. I think the most effective way to handle this is to practice risk mitigation strategies and implement them before the issue even arises. An example of this would be dedicating a department of the company to tracking global politics and identifying potential risks to come up with mitigation strategies. In terms of tariff or supply issues, ensuring that your company is not reliant on a singular supplier can also prevent delays and issues down the line should any complications arise. 

I agree with the idea of building buffer time and finding alternative paths, but one thing I think is really important that hasn’t been emphasized as much is task decoupling and parallelization. When a critical task is delayed, teams can often reorganize the workflow so that dependent tasks are broken down into smaller components that can still be partially completed. For example, even if a key system or material is unavailable, teams can continue with simulation work, documentation, or preliminary validation steps to reduce the bottleneck later.

Another approach is prioritizing tasks based on dependency and impact, rather than original scheduling order. This can help ensure that once the delayed component is resolved, the team can reintegrate quickly without causing further cascading delays.

I also found the example of alternative materials really interesting, and it made me think how do teams decide when a temporary workaround is good enough vs when it risks compromising long-term reliability or regulatory standards?

As other members of this discussion have mentioned, one of the most most effective ways of anticipating and combatting delays is to actually embed them into your project plan. It is almost impossible for a project to go entirely smooth, and there will almost always be an unforeseen circumstance which will causes delays in the timeline. A proactive PM will anticipate this, and include time for anticipatory delays in the project, so that the timeline does not get disrupted in the event that an actual delay occurs, as the PM will have planned for it, leading to less severe disruption to major milestones for the overall project plan. 
In my personal experience, I've experienced this firsthand, not entirely in a medical device manufacturing sense, but rather in a systemwide installation sense. At the hospital I currently work at, there was a recent Emergency Department expansion project which oversaw the addition of 24 new rooms, in addition to a new patient intake bay. Following the actual construction of these rooms, we were given a timeline of 2 weeks to install patient monitors, blood pressure machines, and all other accessories that would be required of a patient room. This was in addition to performing functional tests to ensure that all monitors were wired correctly, and all connected to the proper access points to be monitored from a central point. The aim of our department was to complete this task for all 24 rooms with at least 4 days to spare, in the event that we required extra time for a certain stage of the installation. Without this planned buffer or goal to work towards, not only have we might've worked slower, but we also wouldn't have set aside time for any unforeseen circumstances which would've caused us to go beyond the allocated timeline, delaying the opening date for an essential expansion and pushing back the entire project by an unknown amount of days, which can be detrimental to a project as important as this. 

When unexpected delays happen that are out of the team’s control, I think the best approach is to stay flexible and focus on what can still be done while waiting on the blocked task. I have experienced situations where progress depended on one issue, and instead of stopping completely, the team shifted to smaller tasks like documentation, testing, or preparation work to stay productive. Communication is also key, especially with stakeholders, so expectations and timelines can be adjusted if needed. Once the delay is resolved, the team should reassess priorities, possibly redistribute work, and increase coordination to catch up. Overall, the goal is to stay proactive during the delay and then move efficiently once progress can continue.

Often, sudden unexpected delays should be anticipated during project planning, where task windows can compensate for the offset, such as by deploying slack time. However, there are cases in which the project can't move on without a specific task being completed and nor can any of the other tasks be worked on at this time. In that case, say the machine not working, attempt to find alternative equipment. Maybe modify the product design in a way that it's functionality is not largely impacted. Pay another vendor or company to complete the equipment task. You should ideally plan critical tasks early on in the schedule so that delays don't spring up later in the project timeline, especially near deadlines. By starting critical components earlier, the schedule has adequate time to be changed. Although we can't anticipate every scenario and some situations may not have workarounds, in such cases, it is crucial to communicate and document the problem effectively with the team, stakeholders, and all affected parties so that next steps can be planned out clearly. That said, what is such an immediate scenario, and how do large companies handle such issues?

During my last internship, I ran into a delay that impacted a key milestone. I was responsible for performing model compensation on additively manufactured parts, which required CT scanning to measure distortion. However, the CT scanner malfunctioned, and what was expected to be a short delay kept getting pushed back.

Instead of waiting with no progress, I shifted my focus to other areas of the project that could still be advanced independently. At the same time, the team developed a contingency plan and decided to send the parts to an external lab for scanning. Although this increased costs, it allowed us to stay on schedule. Once the delay was resolved, we prioritized critical path activities and adjusted resources to get back on track. This experience showed me the importance of flexibility and having backup plans for risks that are outside of the team’s control. In real projects, things will not always go as planned. That is why it is very important to be able to quickly pivot to the next task while things are being resolved. In my personal opinion, there is always an answer for the issue and by just sitting back and hoping it will resolve itself is never a good choice. 

Do you think it’s better to absorb extra costs to stay on schedule, or accept delays to keep the project within budget?

The proper response to such a situation will be to adapt to the new conditions rather than stop all the work. It is also critical to continue the implementation of minor stages of the task that do not depend on those elements of it that cannot be completed due to reasons beyond the team’s control. In addition, it will be necessary to inform the manager or client about the problem and its impact on the schedule. Such situations occur quite often in industry where it is necessary to wait for certain parts or equipment. Teams usually respond by adapting their schedule, moving to work on another element of the task, and, if possible, finding alternative ways to solve the problem. Being caused by external factors, such a delay can easily lead to misunderstanding. Thus, it is essential to communicate clearly and transparently. In case the delay is corrected, the next step will be the recovery from it. The work may be carried out selectively, divided among the employees, or intensified in case of necessity. Currently, at work, we ran out of a part that we ordered a long time ago and we got in contact with the company that makes that part and they said it won't be available until September, which is 5 months from now. They did not let us know that information before we ordered it. Since we cannot pause our project for that long, we are finding alternative materials and parts while still working on the portion of the project that does not require that piece. Also, all parties are aware of this situation. 

Project delays can happen even when the team is doing its best If the problem is outside the team’s control, they should first find the cause and make a new plan. The team can keep working on other small tasks while waiting for the main problem to be fixed. It is also important to tell the customer or manager about the delay. I think this kind of problem can be solved by changing priorities and updating the schedule. After the delay ends, the team should focus on the most important work first. Good teamwork and clear communication help the project move forward again.

I have found when project delays are due to events outside of a team’s control, reassessing the project plan is the most effective way to determine the actual critical path of the project. When there are major milestones being delayed as a result of a critical task that is dependent on someone else, the team should use that time spent not working on the critical task to increase productivity in those areas of the project that are not dependent upon that critical task (i.e., documentation, refining design, etc., or even performing testing that could run in parallel with the critical task). 

I experienced a similar situation during BME Capstone when hardware failures caused us to burn through our motors and key components, preventing us from testing the software. Because of this bottleneck, we placed an order for replacement parts immediately and used the downtime to work on smaller tasks and prepare for testing. In order to stay on schedule and to make sure that we tested as quickly as possible once we received the replacement parts, we came in during our break to rebuild and test. Through this experience, I have learned that although delays are sometimes unavoidable, a team’s reaction, particularly with respect to adaptability, ownership of the problem, and timeliness of recovering lost time, has a large impact on the success of a project. Would you prefer to have a built-in buffer time for these situations or rely on a team’s ability to respond appropriately to delays once they occur?

Honestly this is a very typical scenario. Often times projects are dependent upon factors beyond the team's control such as suppliers and equipment. Although it may not be the team's fault for the delay I believe that being adaptable and making the most of the time available to complete smaller tasks unrelated to the delayed task will help to get back on track.
In addition to adapting to the situation in order to move forward Communication is also key. The team should notify all parties involved with what has occurred and provide a revised timeline as quickly as possible. Upon resolution of the problem, the team can then attempt to recover lost time by adjusting priority levels, working on several items simultaneously and redistributing the workload to move at a greater pace. Ultimately, this further shows why having some form of contingency plan is crucial for critical elements of a project. However, not every eventuality can be anticipated. Do you feel that teams are able to reasonably anticipate and prepare for potential delays similar to those described above or do you feel that certain events are simply outside of their control?

In a professional engineering environment, a delay caused by external factors can require a transition from standard operations to crisis management. The first step is practicing proactive transparency; because the setback is outside the team’s control, you must immediately notify stakeholders or regulators of the issue, providing clear documentation of the failure alongside a revised recovery schedule. While the major milestone is stalled, the team should remain working on low-dependency tasks, such as front-loading regulatory paperwork, finalizing secondary documentation, or running software simulations, to ensure some progress is still being made. This ensures that once the bottleneck is cleared, no administrative work remains to distract from the technical recovery. Once the delay has subsided, the team should employ a crashing strategy, which means resource leveling, diverting all personnel to the critical path task, and possibly implementing parallel shifts to maintain 24/7 progress. The ultimate goal is to demonstrate that while the team was not responsible for the failure, they remained fully accountable for the solution, ensuring the project's momentum never truly hit zero.