Why Projects Go From Best to Worst Case

We always go into our medical device and healthcare IT projects with the best of intentions and the grandest of hopes. However, these are complex undertakings with patient safety and mission critical statuses in all but the most trivial cases. If you’re leading or participating in these projects you’ll be asked for launch estimates — I recommend that you never give one answer.

We always go into our medical device and healthcare IT projects with the best of intentions and the grandest of hopes. However, these are complex undertakings with patient safety and mission critical statuses in all but the most trivial cases. If you’re leading or participating in these projects you’ll be asked for launch estimates — I recommend that you never give one answer.

Try and give a “best case” (where everything goes right), “nominal case” (the likely scenario), and “worst case” (where lots of mistakes are made). If you’re ever doing a project type (e.g. new software or new device type) for a first time you’re likely to hit  the “worst case” scenario more often than any others. If you’ve done a project of the same type before, you’ll be able to hit the nominal cases frequently. If you do the same project over and over then you’ll be able to hit the “best case” routinely.

When you’re asked “what can cause the project to go from ‘best case’ to ‘worst case’?” here’s are some traits:

• Slow decision-making: the faster you can make decisions, the easier it is keep the project moving through its phases.
• Inaccurate understanding of the regulatory environment: ONC, FDA, and other regulatory bodies can change their approaches to interpreting statutes and regulations without necessarily informing vendors;  it’s crucial that a regular regulatory review be conducted at least quarterly or biannually.
• Incomplete risk management documentation or inappropriate risk mitigation strategies: medical devices and MDDS systems are inherently risky. Detailed requirements are important but a risk assessment and mitigation strategies for each requirement or requirement group are just as important.
• Introduction of new technology components: when possible, no new technology component should be introduced unless it’s already in use somewhere else. When possible, you don’t want to do new science or use components that are untested when existing components can easily do the same job. Regulatory requirements are easier to meet when predicate devices, techniques, and algorithms exist.
• Arbitrarily aggressive time schedules: if you choose to release based on arbitrary marketing or self-imposed dates instead of specific requirements and actual release capabilities then poor decisions are made early which snowball into a bad product at the end. Schedule estimates must be scientifically arrived at with some evidence for understanding why the estimates are what they are.

Of course there are many other reasons for complex safety-critical projects to be delayed. Share your traits as comments below.