Why Projects Go From Best to Worst Case

March 4, 2011
59 Views

 

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.

You may be interested

Care On The Road: How Telemedicine Can Reach Truck Drivers
Mobile Health
12 views
Mobile Health
12 views

Care On The Road: How Telemedicine Can Reach Truck Drivers

Larry Alton - August 21, 2017

Telemedicine is considered a powerful tool for individuals living in rural areas, far from adequate services or in need of…

Where Is The Balance? Pushing Back Against Consumer Health Tech
eHealth
3 views
eHealth
3 views

Where Is The Balance? Pushing Back Against Consumer Health Tech

Larry Alton - August 18, 2017

When Republican Congressman Jason Chaffetz glibly remarked that Americans struggling to afford insurance should choose between that and their smartphones,…

What to Look for in Patient Solutions Software
eHealth
365 views
eHealth
365 views

What to Look for in Patient Solutions Software

Robert Cordray - August 17, 2017

The medical sector is one area where technology has had a significant impact, largely by providing tools that simplify many…