Recently I've taken on a role as a production scheduler at my company, so in terms of being a "leader" for one of the management sectors I've taken on planning for some of these projects. I think one of the biggest challenges in planning is having something surprise you. You can be planning for a project and have all your risk assessments done and believe that you should have everything figured out, and then all of a sudden something happens that brings a whole new complexity to the project. For me, that part of planning is difficult but it's also something that I enjoy, as there is always some problem solving to be done in planning. I think also getting the team to also have their input in planning can be a challenge as well. Most people want everything to be laid out for them and all they have to worry about is execution, but I believe a project doesn't become successful without the input of those involved in the execution in the planning process. It's so important to have a good baseline at the planning stage, and without that key information, it can be disastrous for the rest of the project timeline.

I agree with what njq3 has said about planning and surprises, as unexpected events can throw the trajectory of a project completely off course. Additionally, for planning, things like troubleshooting, the time it takes to coordinate, or back-and-forth in regulation may not get fully captured, leading to issues in scheduling. Something else that I think causes issues between sectors is false alignment. Everyone might think they are on the same page because of the documentation that has been signed off, but each team might interpret the scope slightly differently. In execution, when things don’t fit together, the issue becomes clearer. 

Another issue I see that could potentially arise is overly relying on historical data. The slides for this week mention how teams can use past projects for estimates. However, in medical devices, new technology and new regulations can make old data very misleading. There can also be a lag between making decisions and the impact that these decisions have later down the line. A decision that is made in scope or procurement might not cause clear harm until weeks later during the testing or validation phase. This will become more expensive to fix later on, so having models or ways to see the impact of certain decisions down the line would be very beneficial. This also plays a role in assumptions as well. In planning, assumptions that become too locked in/relied on too early can lead to many issues in planning and budgets. In the third simulation we just completed, our team made an assumption that we never confirmed regarding the molecular specificity of the surfactant. This assumption made our solution take two posts longer than it could have, since we locked in our assumption without confirming it. From a planning sector standpoint, this could cost thousands of dollars and many weeks in real life, showing the impact of assumptions. Additionally, other sectors will use the assumptions made in planning, and then the issue becomes intertwined in the fabric of the entire project. 

How do you think teams can detect false alignment or assumptions early on, before it shows up during execution or testing? Have you experienced a situation where an early assumption led to major downstream issues? Additionally, do you think relying on historical data helps or hurts more in innovation projects like medical devices?

Both points about false alignment and the danger of locked-in assumptions really resonate with me. During my time at Boston Scientific, working on a delivery system for a next-generation heart valve, early-stage assumptions about component tolerances were often treated as confirmed facts across teams before any validation had occurred, and by the time discrepancies surfaced during testing, multiple downstream workstreams had already built on those faulty foundations. This directly speaks to Dev's point that decisions made in one sector can quietly create expensive problems in another. What helped in that environment was building structured assumption logs into design reviews, which forced the team to explicitly distinguish between what was confirmed and what was still hypothetical. On the false alignment front, I'd argue that sign-off on documentation creates a false sense of shared understanding, and brief cross-functional alignment checkpoints (where each team verbally articulates their interpretation of scope) can surface mismatches far earlier than execution will. Regarding historical data, in a cutting-edge application like a next-gen heart valve delivery system, legacy data often reflected older catheter technologies that didn't translate well to the new design constraints, so it served more as a rough anchor than a reliable estimate.

Similar to Sami, in my time working as an intern at a medical device company, I was onboarded into a team at a later stage of a project, before FDA submission. One part that I believe is overlooked is when and how information can move between people and functions. As other responses have mentioned, surprises, assumptions, and false alignment are true, but another important factor is communication of specifications and preserving the rationale behind decisions. This becomes more vital as teams evolve over time and at the later stages of the project. For example in a team I was in, the tolerances of an outer diameter of a catheter were uncertain within the team. The team knew that there was a tolerance but did not know whether the limit was an absolute maximum, a target with a tolerance, or just a suggested boundary. Specifically, the team was misaligned as to why the specification was designed that way. I experienced a situation where during my validation testing, the current members did not know the rationale of the tolerance from the original team from 8 years prior. Only the engineers who were involved in the early development of the project understood the “why” but the knowledge was never fully transferred or captured, which created production complication. This truly highlights a challenge that many management sectors must overcome, which is not only documenting decisions but also recording the justification behind them, including why alternatives were not pursued. Additionally, it is vital that design intent is not lost when teams change or develop. The hardest challenge is sometimes not only the technical issue but also reconstructing the reasoning behind past decisions when the reasoning was not preserved. Through this, do you think project teams should preserve design rationale as a part, or is there an improved alternative to record and emphasize documentation?

I really like the points raised about assumptions and knowledge transfer. One additional challenge I think isn’t talked about as much is decision latency and feedback loops. In many projects, especially in regulated environments, there’s often a delay between when a decision is made and when its impact is actually visible. This creates a situation where teams continue building on a flawed path simply because there isn’t immediate feedback to correct it. One way to address this could be incorporating short-cycle validation checkpoints or “mini-testing loops” earlier in the process, even before formal testing phases. This would help surface issues sooner rather than allowing them to propagate across teams. It also ties into integration management (ensuring that outputs from one sector are continuously validated by others). Overall, I think reducing the time between decision-making and feedback could significantly improve alignment and reduce costly downstream fixes.