The Importance Of Risk Documentation In Medical Device Design

It’s a great day for hiking in the woods. The sun is shining, the temperature is just right, and the calmness of the forest is relaxing. After a time, you come to a stream that’s swollen from rain the day before. You have to cross the stream, but you have no way of knowing how deep the water is or if the current would be too much for you. Glancing to your left you see a tree that has fallen across the stream. Is it strong enough to support your weight if you use it to cross? If you walk along the stream bank, would you find a more suitable place to cross? Or should you turn back and take a different trail that may have a bridge or an easier crossing?

All these options have their own upside and downside. Whatever decision you make, there would be varying degrees of risk. If you chose to try the tree, would it hold? What if you slip and fall? Could you be injured? If so, how seriously? If you cross the stream, would the risk be more or less than trying the tree? What are the chances you slip and drown? Or do you take time to look for a more suitable place to cross? If so, how much of a delay would be acceptable? When do you give up trying to find a better spot to cross? Lastly, if you turn back and take a different trail, would you find a way to safely cross or would you encounter other, more riskier options? Would that delay be acceptable?

The scenario described above is much like the questions and challenges a project team wrestle with in designing a new medical device. The pressure of getting a device to market as quickly as possible, the pressure of picking the right design, and the pressure of maintaining a budget and managing project resources all influence a device’s design in subtle ways.

Each aspect in the design of a medical device has associated risks, associated delays, and associated advantages. The key to successful product development is to weigh the risk versus the reward. How best to accomplish this assessment? Through the use of risk documents.

Failure mode and effect analysis (FMEA) documents are designed to work with the medical device’s design team to ensure the new design meets all intended uses and does so in as effective and safe a manner as possible for both the user and the patient. To effectively accomplish this, it is important to any device’s development to constantly assess changes and modifications of the design against associated risks.

Failure Is Not An Option

To quote Gene Kranz, the Apollo flight director who led the team that guided the stricken Apollo 13 safely back to earth, “Failure is not an option.” Nothing is worse than launching a promising new medical device only to have safety and efficacy issues occur that result in negative publicity, lost revenue, and, in some cases, eventual recall. The disappointing aspect is how easily most quality issues could have been avoided if the project team had done a more thorough job of assessing risk.

That is why risk documents are an integral part of design control for medical devices. Risk documents guide the design team to understand all the myriad ways a device could fail or create a potential harm/hazard and the best way to minimize or eliminate the identified risks. This could be through a modification in the design or through the introduction of better controls. This living process, when properly applied, helps ensure a device is safe, efficacious, and reliable.

Risk documents also provide documented evidence of the device’s risks and how the risks have been reduced or eliminated, as well as what controls or specifications are in place to accomplish this minimization/elimination. This important documentation is required under design control for the device’s design history file.

Don’t Treat Risk Assessment Lightly

A friend of mine worked at a company that was designing a new way to administer sealing a tear in a vessel. During the development of the device, it was observed that the device would occasionally cut the sealing device during operation. This small cut was dismissed as a low-risk event. Besides, the project team reasoned, it was occasional and a minor cut at that so what harm would it cause anyway? The project team was under enormous pressure from management to release the device to market. Faced with mounting pressure, the project team decided to move forward with the project despite this potential failure mode. To make matters worse, the project team didn’t even acknowledge this observation in any of their risk documents. What happened when the device was launched? Users started reporting sealing failures. Eventually, the number of instances of failure became so great that the device was pulled from the market.

It is clear the project team did not leverage their risk documents to properly assess this failure mode and make the necessary design changes to eliminate its occurrence. It is possible the pressure from management played a key role in this decision, but, ultimately, it was the team’s responsibility to ensure the device they designed was safe. Their decision, unfortunately, resulted in a negative perception of the company by the market, a negative effect on its revenue, and it negatively impacted the careers of team members.

Weigh The Risks

There are no shortcuts to safety. There are no shortcuts to doing the right thing. The greatest tool in your toolbox to achieve “fast-to-market” is risk documents. Risk documents are essential tools to help a team avoid product performance issues and avoid causing unnecessary harm to patients. It is in every team’s interest and the company’s to be intellectually honest and critical in assessing risk. A project team may make management happy in meeting a launch date but if the product causes field issues, that same management will be coming back to the project team asking questions that will sure to be very uncomfortable to answer.

In the end, management is relying upon you, the project team, to make sound decisions regarding risk. After all, doctors and their patients are counting on you to provide the best possible level of care while not causing harm. Medical companies are in business of improving the quality of life. Risk documents are a key to meeting this responsibility. Take the time to execute your risk documents properly and be as realistic as possible with assessments. In the end, we all will benefit.

3 Common Mistakes Using Gantt Charts For Medical Device Projects

In this series of articles, I’ll touch upon areas that I’ve found to be practical advice for project leaders. This article will focus on project planning. Hopefully, the points made will benefit you in supporting or running your next project. As project leader you need to develop a project plan for your team to track their tasks, as a means to see where you are with respect to the project deadline or product launch, and as a way to communicate to management how things are tracking. There may be other uses for a project plan but these are the main ones.

Now that you’re a project leader, your job is to get the project done as soon as possible and get it done right; management is already breathing down your back. Quickly, you assemble your team, now what? The next thing you need is a project plan: what needs to be done, what you need to do a task, when a task needs to be done, and who needs to do what. How best to accomplish this? A Gantt chart.

A Gantt chart is a bar chart used to show a visual timeline of a project and its tasks. It provides a step-by-step road map of the project’s timing, milestones, and overall timeline. Basically, it shows how the project will unfold. I worked at many companies that utilized Gantt charts to control and monitor projects. They are a useful tool, but, like statistics, they are only as good as the inputs from which they’re constructed.

What’s ironic about a Gantt chart is that it is supposed to show a detailed overview of the project, but you compile the Gantt chart at the beginning of a project when you know the least about what actually needs to be done, how long it will actually take, and what issues and obstacles you will face. In effect, you are predicting the future that you hope will happen and the way and when it will happen. What’s worse, once you determine a completion date based upon this conjecture, everyone, especially management, will expect you to make that date. For this reason, some project teams will fudge their completion date by padding the time allotted to individual steps to push back the projected completion date.

Mistakes often occur in developing a project Gantt chart. It’s inevitable that a step is missed or the time it takes to complete a task is underestimated. Of the mistakes made with Gantt Charts, three typical mistakes are: not enough detail/steps delineated, unrealistic timing assigned to project steps, and not keeping the Gantt chart up to date. Let’s take a closer look at these mistakes and what can be done about them.

Mistake #1: Not Enough Detail/Steps Delineated

In putting together a Gantt chart, a lot of teams will define general steps and gloss over the actual number of steps. For example, a company requires a protocol for any testing to be conducted. The protocol needs to be submitted for approval, which is defined in company documents as taking a minimum of 10 days. Once the protocol is approved, materials may need to be procured and time set aside in manufacturing to run the protocol. Lastly, the results need to be compiled, analyzed, and a final report written, which is then approved. Here is a simplified summary of how the project team listed this in their Gantt chart:

STEP DURATION START DATE END DATE

Write Protocol 3 days Monday, 6 Feb Wednesday, 8 Feb

Protocol Approval 5 days Thursday, 9 Feb Wednesday, 15 Feb

Run Protocol 10 days Thursday, 16 Feb Wednesday, 1 Mar

Completion Report 3 days Thursday, 2 Mar Monday, 6 Mar

Approval 5 days Tuesday, 7 Mar Monday, 13 Mar

Immediately you see there is a problem. Let’s look at each step in the example. Will writing a protocol really take three days? Is all the information that needs to go into the protocol available on day one? While approvals take a minimum of 10 days, the Gantt chart is only giving them five days each. If the 10-day minimum requirement is held, already the Gantt chart is off 10 days – five days for the approval of the protocol and five days for the approval of the completion report. The section pertaining to running the protocol does not reflect whether manufacturing’s operators need training on the protocol or account for extra time if the protocol fails. What if there is a material issue? Is there enough time to procure everything needed for the protocol? The step related to the completion report lacks details. Is complex and time-consuming testing required of the data collected? Do you need to send material to an outside company for analysis or specialized testing? If so, where is that time accounted for? Is statistical analysis needed that is complex and requires a lot of time?

You can see from this small example that omitted steps through a lack of experience in knowing what needs to be done can throw a Gantt chart off significantly. To avoid this type of oversight, rely upon your experienced team members. Talk to manufacturing to determine what they need to run the protocol. Will they be on shutdown? Will key manufacturing personnel be on holiday or will there be enough personnel available?

Speak to the person or persons responsible for the completion report and any analysis needed. How much time do they feel they need? Is there anything you need to be aware of when it comes to doing the data analysis? One footnote to this: Does the protocol ask for all the data needed for the analysis and in the format the analyst needs?

As for approvals, take the time to see what the approvers will be looking for. Ask team members if they have had dealings with the approvers. If so, what do they look for in approving a document? What if an approver is out traveling, sick, or on holiday? Is their backup aware of the protocol and are they willing to approve?

There are a lot of “what ifs” to think about. Of course, you can’t be paranoid and include everything, but you can be realistic about what needs to be done and what will most likely occur. Talk to other teams that have done something similar and ask them what potential setbacks or issues they ran into and see if you need to compensate for them. There is no magic formula here. It comes down to being experienced with how things work in your company and knowing the people who will be involved and what their natural tendencies may or may not be. A Gantt chart is an educated guess at the future, but you should be making honest, realistic guesses and not ones that reflect a utopian scenario.

Mistake #2: Unrealistic Timing Assigned To Project Steps

As in the above example, it is easy to underestimate timing. Often timing is entered as wishful thinking: “We’ll push them to get it done within the dates we have” or “I’ll talk to their manager to get them to focus on it.” In either case, do you realistically think that will happen? Maybe once, but every time you need something done? More often than not, their cooperation will lessen over time. You can only call in so many favors. Is there a holiday during the time you will need to execute the step? Did you account for that? One thing I’ve seen play out time after time was expecting things to get done between Thanksgiving and New Year’s Day. Believe it or not, a lot of people take days off then. In Europe, it’s not unusual for a company to shut down for an extended period between Christmas and New Year’s. Workers tend to not be as productive, either. I would tell my team that we would be lucky if anything got done during that period. Someone is out, an emergency order needs to be filled, equipment needs maintenance, etc.

Be honest and realistic with timing. If not, it may cost you dearly in the end when you need to inform management that you will miss the promised date. That usually doesn’t bode well for the project leader.

Mistake #3: Gantt Chart Is Inadequately Maintained

This seems such a simple thing to do, but so often it is relegated to an intern to update or completely forgotten. Some project leaders treat the Gantt chart as something carved in stone and refuse to accommodate changes. Often that is because they promised a date to management and it’s the project leader who will be held accountable if they do not meet the date.

Updating and adjusting a Gantt chart should be done weekly at minimum. Changes should be communicated upward. This is very important. You must keep management informed of the project status and any changes that would affect the deadline or project launch. Yes, you’ll take some heat for the changes, but if you have a solid reason for the change and explain things so they are understood, management should be understanding. If you’re lucky they may even give you more resources or help with the delay. It never hurts to be honest. Better to get it over with than to sweep things under the proverbial rug until the end. Management doesn’t like it when that happens, especially if they could have ameliorated the situation.

Another reason to keep a Gantt chart updated is to understand what has to shift or how the current issue may cascade into future tasks that might have their timing impacted. By maintaining the Gantt chart, you can see the big picture and make adjustments accordingly to minimize the “damage” to the schedule.

If you do have an intern or co-op handling the updates, be sure to check that they are capturing the adjustments properly and not causing issues themselves. Things can easily go from bad to worse through such a compounding of errors.

Conclusion

Gantt charts are a very effective tool, but, like any tool, it has to be used properly to be the most effective. Gantt charts are an excellent way to quickly determine the project’s critical path, seeing where your potential trouble spots are, helping to understand the tasks each team member is responsible for, and communicating the project’s progress. You maintain your car to ensure you can count on it to get you where you want to go. A Gantt chart is your project’s car. Constantly monitor and diligently maintain your Gantt chart. If you do this, your Gantt chart will become an invaluable aid in successfully completing your project.