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.

Quality Engineers: Are You Making The Right Call?

by Eric Hinrichs, senior principal quality engineer (retired), Ethicon, part of the Johnson & Johnson Medical Device Companies

As a quality engineer, have you ever had the following conversation with a project leader?
Project leader: “Hey, do you have a minute?”
You: “Sure, what is it?”
Project leader: “Well, we need your signature on this validation completion report. As you know, the project is hot and the product launch is due next week. This approval is all we need to get the product released. You’re the last signature. Everything is fine, so just sign it and I will get things moving.”
You look at the report the project leader has handed you. You had reviewed it earlier when it showed up in your queue, but you saw red flags in the data analysis. There were outliers that were “explained away” and not included in the final analysis. Not just one or two, but many, and they were outliers by a lot. Something wasn’t right about them and the explanation to exclude them didn’t sit well with you. You know the product launch is the company’s number one priority; everyone is looking to this launch as a big win for the company, but these outliers….
You: “Sorry, but I need to understand these outliers you excluded. I do not align with the rationale in the completion report regarding them. I think there needs to be more investigation as to how and why they occurred.”
Project leader: “Ah, c’mon, the rationale is good. Everyone else has signed off on the report. They’re no big deal. Yeah, a few outliers happened, but that happens all the time. C’mon, we need this product launch to happen and you’re the last person to sign off. C’mon, as a favor for me. Trust me, the outliers are a fluke; there isn’t anything that is going to go wrong.”
So, what do you do? Sign off on the report as a favor or reject the report and ask for more data analysis and risk having management upset with you for the delay?
In quality we are often faced with such dilemmas. The above scenario is based upon a more innocent request early in my career. I wanted to be viewed as a team player. I was new and I didn’t want to look bad to management. I gave the project leader the benefit of the doubt. What happened? There was a problem with the product, and I became the project leader’s and management’s scapegoat, with the oft-stated comment, “Well, Quality approved it.” As if I was the only one that could have stopped the launch.
This is the tough part of the role Quality plays in a company: having the ethical fortitude to make the right decisions. Did I have a choice? I did, but I caved in favor of my rapport with the project leader and the fear of being perceived as a roadblock to the company’s goal of getting the product launched. My gut, my intuition, my sixth sense all told me not to approve the report, but the emotions behind helping a friend and not looking bad overwhelmed my common sense. The product did have issues and had to be redesigned.
What were my options? Did I have any? I did. What I should have done was get with the project’s quality engineer and review the raw data and their findings. Gain alignment on what really occurred during the validation. Once done, work up a synopsis of our findings, what options were available to ameliorate the situation, and what resources would be needed to fix the issue, as well as the best-case scenario for a new launch date.
True, no one would like this scenario, but I found that it’s best to be late and right then early and wrong. Management should understand the situation and align with it if the information and situation are clearly and properly framed and presented. No one likes delays, but delays for the right reason should be understood.
Pressure in the workplace is real and often overwhelming. Sometimes one needs to step back and take a deep breath and look at what options are available that are best, not only in the short term, but in the long term as well; remember to look at the bigger picture. One thing to consider in making a decision is what is often called the red-face test: In an audit, could you look at the auditor and tell them why you approved something without being embarrassed? Could you defend your decision and feel comfortable doing so?
That approach has helped me immensely in my career. You will often get people that will try to use your friendship or position to get something done and when there is a problem later, they are the ones leaving you hanging.
Ethics and doing the right thing are difficult conversations to have when a job, a career, or a reputation is involved. Doing the right thing in the end is the best solution regardless of what influences are happening around you. Remember to utilize data to support your position, present your position in a clear and concise manner, and provide options as solutions with timing and resource needs. Doing this will leave you in the best light with management and show that you are also coming to the table with solutions. If you ever seem at a loss as to what to do, remember what Teddy Roosevelt said: “In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing.”
Good luck; you’ve got this.

The Role of the Project Leader- The Team

Which are the true statements about a project leader?

Unfortunately, these statements are often viewed as the true role of a project leader. I’ve experienced and been a part of many teams where the above statements were truths. I’ve learned there is no magic formula or process that is foolproof in achieving a successful project outcome. Nor can any one training course prepare you for the myriad of circumstances that will manifest themselves during a project.

In this series of articles, I’ll touch upon several areas that I’ve found to be practical advice for project leaders. It may take some time for you to ‘master’ these, but the effort is well worth it. Hopefully, these lessons and approaches will benefit you in supporting or running your next project.

Team Members- Make or Break

Let’s start with the obvious. A project is only as good as it’s team. A good project leader will try to get the most talented team members to support the project, though, in many cases, the project leader doesn’t get to pick their team members. Rather, their team members are assigned without any say in the matter. Like the coach of a sports team, the project leader needs to assess the strengths and weaknesses of the assigned team members and figure out the best way to optimize their capabilities. This is key to ensuring they can successfully complete their task(s) with the most autonomy.

I was a project leader where the team members were assigned to the project without my input. In one particular project, I was given a packaging engineer that no one wanted to work with. Their reputation was one of being difficult to work with, their work was typically rifted with errors, and they were late delivering their designs, which often required numerous revisions. When they were assigned to my project, I was apprehensive, but what choice did I have? I had to make the best of it. ‘Good luck’, I was told. I knew I had my work cut out for me with this particular engineer, but I knew I had to make things work. When the project was done, the packaging was done early, there were no mistakes or revisions needed, and the packaging engineer wanted to work with me on my next project. What did I do differently than other project leaders to make this particular packaging engineer successful and, as a consequence, this aspect of the project? Here was my approach.

At the beginning of the project, I knew I needed to see exactly what the packaging engineer needed to do and what they needed to execute each of their tasks. To accomplish that, we sat down and laid out all of the packaging steps for the project Gantt chart. We drilled down so every decision, every step, was listed along with all of the inputs feeding into each step along with all of the outputs. As we identified each step, I asked them what were their concerns; what were the typical issues they encountered in completing that particular task. The engineer told me what they needed. I took note, asked a few questions as follow-ups, and ended by telling them I will help them in ensuring their concerns were proactively addressed; they had to make an honest effort to complete each task while I worked behind the scenes to make sure they got what they needed.

After telling the engineer that I was going to do this, imagine my shock when they were surprised at my response on several levels. First, that I actually asked about any concerns they may have and that I took an interest in ensuring they were addressed. They explained that when they told past project leaders what concerns they had the project leader either dismissed them outright, or said they will deal with them if and when they occurred. When the concern did occur, the project leader addressed the issue by putting the engineer on noticed that it was their responsibility to get the task done and intimidating them further with the typical “you need to make this date or I will be forced to tell your manager you’re holding up the project.” Seems like the project leader had a different interpretation of support than the engineer. All the project leader’s approach did was increase the engineer’s anxiety, causing them to rush, which only caused them to make more mistakes. Not the kind of support anyone would want from their project leader.

The difference between the packaging engineer’s past experience and their experience with my project was that I listened, verified their needs, and took note of their concerns. I was involved because, quite frankly, their success was my success; I had a vested interest in their performance. During the project I kept in touch with the engineer to ensure they had everything they needed, I also made sure what they needed was available when the time came. This meant working behind the scene with other team members and departments to get the information the packaging engineer needed but were in no position to do so.

Team Members- People Skills

Another issue that plays into this is that not everyone on your team has good people skills. They may come off to others as abrupt or indifferent. Traits such as these can negatively impact the support they need. As project leader, you need to recognize your team’s people skills and work to ensure they do not interfere with the project. This is something that is overlooked or ignore way too many times by project leaders. When an instance occurs, typical project leaders are quick to blame their team member. Do you think that helps you and the project? If there is a personality conflict you need to get involve early and work with both parties to ensure the situation does not escalate to the point of impacting the project. When I saw this in my projects, I would participate in the discussions to ensure things went smoothly. Being there as a mediator and as project leader showed both sides that I was aware of what was going on and that it was important enough to me that I was present. It sent the right message to everyone.

As project leader, you have the added flexibility and authority to get needed information and resources that team members would not necessarily be able to. Yes, team members would and should try themselves, as they should, but sometimes people do not respond the same to someone without authority as with someone who does have a level of authority. That is one difference a project leader can make in a project; opening up doors that may be closed to team members. Simply put, work to break down barriers to the project’s success.

In essence, as project leader, I made sure the path ahead for the packaging engineer was clear of obstacles and they were working with correct and accurate data. I also make sure I was clear on and understood their expectations by explaining back to them what they told me. This is a two-way street. Conversely, I explained what I needed from they, gave them my instructions and needs and made sure they understood me as well by summarizing what I requested of them. The result was a smooth problem-free packaging effort.

What I did was no magic formula or took special training or a high-priced training course. All I did was what I would expect from any project leader. As a team member, give me the right tools (data), help remove obstacles in my way before I get to them (get the data needed in time and/or alignment from other team members and support departments so they are ready), and support me along the way (listen to my needs and get me the needed assistance). As a project leader, your role is not to just lead but, more importantly, make the team members lives as easy as possible so they can focus on their jobs.

An analogy that may help you would be the general contractor (project leader) building a new home. The general contractor hires the necessary subs (always trying for ones they know are good and reliable- see the similarity here?) and starts the build. The sub-contractors will need to see the plans (Gantt chart) to see what is expected and when. Based upon the plans, they will let the general contractor know what materials they will need (data, suppliers, etc. or what materials they will supply) and what concerns (obstacles) they believe might impact their tasks. The general contractor then works to get the materials to the job site and make sure the building is ready for the sub-contractor when the time comes. If the general contractor doesn’t communicate properly with the sub-contractors, they may arrive at the job site before its ready for them or there’s confusion as to who was to supply the materials, or perform their job incorrectly. The result- the job is delayed, there could be misgivings between the sub-contractor and the general contractor (potentially ruining their business relationship (e.g.- the team member doesn’t want to work with that project leader in the future) and the project incurs cost overruns (management (future homeowners) are not happy) and delays.

A good project leader treats their team members as sub-contractors. Team members are given their tasks/roles in the project and they all go off and work on their assignments. The project leader in turn is the glue or general contractor that keeps everything moving in the right direction and stays one step ahead of team members.

Conclusion

It really comes down to being an honest, supportive, and involved project leader. This is your team; they are counting on you to help them get things done as much as you are counting on them; you cannot get the project done without them. It sounds trite but the Golden Rule applies here too. Treat your team members as you wish to be treated. Simple in concept, hard for some to grasp. Good luck.

The Role of the Project Leader- Execution

This article focuses upon project execution. The points made will benefit project leaders in avoiding pitfalls that could impact a project’s success.

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, you developed your plan, now what?

Hurry Up and Go Slow

It’s natural to want to push forward with your project as soon as possible. Action is everything, right? Management sees things happening, the team feels enthused, and all is right with the world. Stop. Action does not mean you are accomplishing anything, especially in the beginning of a project. Often, in a project, it is the decisions made in the beginning, that could mean success or failure for your project. What makes things more difficult, is when the planning is most critical- in the beginning- is when you know the least about what you need to do, or what issues you may be confronted with.

Let’s look at this further.

You have a project that will need to be run in several plants. When you get to the point in the project where you need to run tests in one of the plants, you discover that they do not have adequately trained personnel to perform the testing, or you find their testing equipment does not have the range to test your product. Suddenly your project is on hold, losing valuable time, when you can least afford it. Management was expecting this phase to be done- you told them in the last project update, remember?

This is where that rush in the beginning of a project sometimes backfires. I like to say ‘hurry up and go slow’. It is meant to convey that you should move a project along as quickly as you can but not at the sacrifice of thoroughly planning out the stages you need to execute; make quick but well-thought out decisions.

A well-planned project will go through various scenarios in the planning stages and pull in team members to find out what will be needed for each phase of the project. Even more valuable is to pull from each team member’s experience to see what issues other teams they were on ran into that you can guard against. This same approach would be useful to execute with the plants where you will be testing. Check that they have the trained personnel, the proper equipment, tooling, and capacity you will need. Each and all of these approaches help your team avoid delays that are avoidable through proper planning. Having a well detailed Gantt chart and thoroughly vetted resource needs will save your project from unexpected delays.

I’ve experienced teams that jump right into projects and assume resources will be there when they are needed, only to find that was not the case. It is for this reason teams need to carefully plan up front and be sure they have thoroughly planned out what is needed to be done and needed to be available so they can move smoothly through testing/validation, etc. to a successful product launch.

Forewarned is Forearmed

Planning also means getting out in front of the project’s schedule. This means letting whoever  is needed for upcoming tasks know that you are almost ready for them. I built my own home and hired and directed my own subcontractors. Things went smoothly during construction. The main reason for this was I would get with subcontractors weeks before they would be needed and review with them where things were. We would also go over what was needed to be done by them and what, if anything, they will need to get their job completed. This approach worked very well in ensuring the job site was ready for them. It was also useful that I gave them advance notice so my job could be scheduled into their schedule. Nothing is worse than when you need a subcontractor or a plant and they tell you they have other commitments and cannot make your date; they weren’t aware you needed them for those dates or times.

To avoid these situations, inform well ahead of time and review your needs and their needs to gain alignment.

Verify, don’t Assume

The worst thing you can do as a project leader is assume you have the materials and resources available when they are needed. Proper planning involves verifying material and resources are obtained or reserved for when the time comes to be used or employed. I’ve been in situations where we had purchased material for the project, only to have the plant use the project’s material for their own needs because they had ran short. We did not find this out until we went to start validations in the plant. They did not tell us nor did we check to make sure we had everything for the planned testing. It was a hard lesson for the project team to learn and it was an avoidable delay. You can imagine how management took the news that our project was delayed until we could get additional material.

Conclusion

Plan thoroughly in the beginning of a project, anticipate potential problems that are likely to occur, inform your resources prior to needing them, and gain their alignment as to timing and resource commitment. Verify materials and resources are available before they are needed. If you focus on these aspects of a project, the likelihood that you will have a smoothly running project will be high.

The Role of the Project Leader- Project Planning

This article focuses upon practical advice for project leaders and project planning. I hope the points made will benefit you in supporting your current project or running your next project.

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.

The best way to accomplish this is with a Gantt Chart. As project leader, you need to develop a project plan for you and your team to track tasks, as a way for you and your team to see where things are with respect to the project deadline or product launch, and as a way for you, as project leader, to communicate to management how things are tracking. There are other uses for a project plan but these represent the main objectives.

Gantt Charts

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. In basic terms, it shows how the project will unfold. Many companies utilize 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 in 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, 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 out the projected completion date.

Being that a Gantt Chart is a projection of events in the future, it’s inevitable that a step is missed, or the time it takes to complete a task is underestimated. More often than not, this is compounded by teams not putting enough effort into compiling the Gantt Chart; they want to jump right in on the project. As a result, the Gantt Chart induces project errors because there is not enough 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 Steps Delineated

Many teams will define general steps and gloss over the actual number of steps it takes to complete a task. 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 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 must 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:

StepDurationStart DateEnd Date
Write Protocol 3 daysMonday 6 Feb Wednesday, 8 Feb
Protocol Approval  5 days  Thursday, 9 FebWednesday, 15 Feb
Run Protocol10 days  Thursday, 16 Feb Wednesday, 1 Mar
Completion Report3 days   Thursday, 2 Mar Monday, 6 Mar
Approval5 daysTuesday, 7 MarMonday, 13 Mar

Immediately you see there is a problem. Let’s look at each step in the example. Will writing a protocol really take 3 days? Is all the information that needs to go into the protocol available on day one? If approval is allowed a minimum of 10 days, the Gantt Chart is only giving 5 days. If this 10-day minimum requirement is held, already the Gantt Chart is off 10 days- 5 days for the approval of the protocol and 5 days for the approval of the completion report. The section pertaining to running the protocol does not reflect:

The step related to the completion report lacks detail. The Gantt Chart’s completion report step does not provide for:

The steps omitted may have been caused by a lack of experience in knowing what needs to be done. This 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. Make sure there isn’t a shutdown scheduled during the time set to run the protocol. Confirm that all key manufacturing personnel have not scheduled to be on holiday and there will be enough personnel available to execute the protocol.

Speak to those responsible for the completion report and any analysis needed. How much time do they feel they need? Is there anything that is a watchout 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 an aside, in considering approval, take the time to see what the approvers will be looking for. Ask team members if they had dealings with the approvers. If so, find out what the approvers look for in approving a document. If an approver may be out traveling, sick, or on holiday verify that their backup is willing to approve as an alternate and they are aware of and familiar with the protocol.

The best advice I can give you regarding Gantt Charts is don’t develop a Gantt Chart in a vacuum. The more those involved or will be involved in your project provide input to the Gantt Chart the more accurate and realistic it will be.

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 in 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 utopia 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 markers. Is there a holiday during the time you will need to execute the step? Did you account for that? One thing I’ve seen played out time after time was expecting things to get done between Thanksgiving and New Years 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’s 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. More than 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 your Gantt Chart and diligently maintain your Gantt Chart. If you do this, your Gantt Chart will become an invaluable aid in successfully completing your project. You may also be surprised at how well you predicted the completion date!

The Role Of Trust And Communication In Successful Medical Device Teams

If you work in the medical industry, you know that new products, revisions, and updates to existing products are typically accomplished by teams. Teams can range from small groups of technical experts to elaborate team structures that are spread out over several company facilities and key suppliers.

But why do we experience teams that seem to start out well, then stumble throughout the project, resulting in delayed launches, product defects, and poor sales? How do they differ from teams that start out similarly and appear to seamlessly breeze through the project development and validation stages to launch a successful product that meets post-launch expectations?

Getting To The Root Cause

It is important to a medical device company that teams perform at optimum levels. Teams that underperform typically result in poor product quality or post-launch product issues. These can significantly hurt a company’s reputation, lead to unnecessary lawsuits, or result in patient or user harm –all good reasons for a company to desire high-performing teams. Companies try multiple methods to try to get all teams to function at an optimum level.

One technique employed is “lessons learned.” In this case, a team will assemble post-launch and discuss among themselves what went right and what went wrong in an effort to use this information to improve future team performance. Unfortunately, while this is a value-added effort, it falls short more often than not. This is due to companies failing to convey these lessons to others in the company or at suppliers and not integrating these lessons into procedures and policies. Teams performing this exercise often do not have any objective outsider involved in the process. As a result, teams can easily overlook the root cause(s) they were faced with. Across my long career, I have observed, more often than not, that teams will identify communication as the reason for obstacles or delays. While this is a fair conclusion, the real root cause goes much deeper than that.

Teams fail to see that communication is fundamentally based upon trust. Team members need to trust each other, including trusting that team members have each other’s back, that team members are looking out for each other, and that they are being mutually supportive. When trust is present among all team members, communication is abundant. Team members are willing to talk about the project and actively and immediately seek out other team members for their input when they perceive an issue is arising or could potentially occur.

A good analogy is a marriage. Healthy marriages have excellent communication between partners. They seem to know what each other is thinking. They trust each other to be supportive and empathetic. When a marriage is not working, you notice a lack of trust (where one of the partners is not being honest with the other, etc.). This lack of trust negatively impacts communications; partners stop talking to each other or convey the bare minimum of information. If trust is not instilled back into the marriage, the outlook is bleak for its survival. Teams function much the same way. If the team leader trusts their team members and the team members trust their team leader, then communication is heightened, team members are more engaged with each other and are more willing to speak up and provide their opinion, knowing it is valued and not dismissed.

How Trust Can Make A Difference In Teams’ Performance

I was once a team member on a project that had a team leader who was “always right,” and when anything went wrong, regardless of the reason, the team leader would automatically blame a team member and do it publicly in team meetings, often attacking the person instead of the issue at hand. You can imagine how team members reacted to this. No one wanted to be publicly chastised like that. If we could get a task done early, did we tell the team leader? No way. We would check and double-check our work and only hand in the task when the deadline was reached. This behavior only served to slow up the project, as everyone was doing this, causing delays. There was no trust with the team leader, so communication was at a minimum. No one volunteered information or suggestions. The team suffered. How did the project fare? We were late, we missed forecast, and we had manufacturing issues that caused customer complaints. These issues most likely could have been avoided if the team trusted the team leader and there was good communication. Teams that operate like this are often less than successful, have trust issues and poor communications, lack team empathy, and commitments are often late or incomplete, if they deliver at all.

On the opposite end of the spectrum, I was once on a high-performing team that was actually refreshing and exhilarating. We trusted the team leader; the team leader would ask for all of our input, and they would be in constant touch with us to see if we needed anything or had any issues they could help with. In turn, we trusted that the team leader would support us and respect our input and efforts. You can recognize teams that have trust and great communications. You see team members going to lunch together or getting together after work. They joke and seem relaxed. The work seems effortless and fun, yes, fun, because you feel like everyone appreciates your efforts on behalf of the team and team members recognize your work. You want to get your part done in time, so you don’t hold up other team members, and empathy is at a high level. As far as the project outcome: We finished the project ahead of schedule, on budget, without any post launch issues!

This high-performing team had trust, great communications, team empathy, and open and honest dialogue.

Who Is Responsible?

Team Leader

Team dynamics and culture start with the team leader. Do they have the people skills needed? Are they inclusive in discussions and are they supportive of team members? Team leaders should not hog the spotlight but give team members the recognition. Team leaders on effective teams should be almost invisible, working behind the scenes to help team members accomplish their tasks. In effect, they are getting the managerial and logistical hurdles out of the way ahead of time so team members can complete their assigned task(s). Team leaders need to do their homework and ensure there are no conflicts among team members. Do you have two team members assigned who dislike each other? Is there a dislike or competitive nature between departments that needs to be resolved up front?

Team Members

Are team members committed to the project? Do they have conflicts from their manager, who may have a different agenda that sets the project at a lower priority and instructs their associate to likewise de-prioritize their work on the project? This is a not-so-rare occurrence in large corporations and, often, at suppliers.

Management

Sometimes, teams have to report unforeseen issues back to management. In such cases, management must understand that these were unforeseen issues that the team needs to absorb and address in their schedule. These issues may cause a delay. In these cases, management has to trust the team leader to work with the team on a solution that will also adhere to the timeline as best as possible. Management needs to trust that the team leader understands the importance of the timeline and its impact on the company’s performance.

Conclusion

There is no magic solution to getting teams to perform well. Much like a sports team, there are many intangibles that separate a winning team from an underperforming team. But the common denominator is trust. Unfortunately, most companies foster internal competition between teams and/or departments. It can be difficult to turn off this competitiveness, and it can creep into a team’s dynamics, making it almost impossible to create a highly performing team.

What a good team leader can do is sit down with their management when forming a team. Do your homework. Identify what talent and expertise you need and which associates have the right attitude and aptitude to support your project, and actively advocate for them to be on your team. As a team leader, treat your team members as equally important and trust them to do the right thing. Have weekly informal meetings, like hallway conversations. I found having a few minutes of each day with team members to be valuable in picking up potential issues before they cause a problem.

Team members should be committed to the project. They need to know clearly what is expected of them and what they need to complete their task. They should not be afraid to bring up concerns, even if they are with aspects of the project for which they do not have responsibility; impacted team members should not view these concerns as an attack but as a supportive concern and that the team member is looking out for other team members.

If these elements are followed and addressed, your team should be successful.

Statistics Abuse In QA/QC: 3 Lessons Learned

The tools we use to develop new or improved products are essential in ensuring we deliver the product as soon as possible and as efficacious as technology, testing, and knowledge/experience permits. But the caution one must take in using tools is to be mindful that we use the tools correctly and effectively. The worst that can occur is to use a tool incorrectly and, as a result, make errors in conclusion that could lead to injury, costly litigation, or a tarnished reputation.

One of the best tools at our disposal in a quality assurance/quality control context (manufacturing, supplier quality, etc.) is statistics. Statistics helps to quantify uncertainty. This allows us to make conclusions with a degree of certainty regarding this uncertainty. Statistics also helps us extrapolate and interpolate information in the form of data to make informed decisions. The key word here is informed. Statistics is not a substitute for thinking. Remember, statistics is a tool. As a tool, it provides more clarity around uncertainty so you can make a more appropriate conclusion on the data that relates to your product’s performance. This is extremely important regardless of the project’s phase, whether it is feasibility, development, validation, or an aspect of process improvement. Statistics can be abused through purposely misapplying statistics or it can be abused by improper application or interpretation.

Lesson #1: Statistics Is Not A Substitute For Thinking

A form of statistics abuse can be demonstrated in the following example. A company where a manufacturing site was updating a testing machine to a more automated version applied statistics to test data that showed the P-Value of a 2-gram difference in test comparisons between the two testing machines is significant. The engineer determined that difference meant the machines were not the same. Significant debate ensued. The main concern was the 2-gram difference was not a measurable difference by the customer, yet statistics implied the 2-gram difference was significant. The test was a subjective destructive test measuring a constantly changing resistance force. Things were at an impasse until informal testing of prepared samples was conducted with customers. The customer feedback showed that differences of less than 10 grams were undetectable. In fact, for larger products, differences of less than 35 grams were undetectable. The conclusion was, despite statistics indicating this small difference to be significant, it did not impact the performance or the perception of performance by the customer. In other words, there was no practical difference between the two machines, even though statistics concluded there was a difference; the difference was not practical.

This scenario illustrates where a practical litmus test coupled with experience and additional testing can provide valuable information or clarity around statistical uncertainty. Always remember that statistics is a tool to help you make a decision — it is not a substitute for thinking.

Lesson #2: Set A Realistic Confidence Interval

I’ll share another example from my personal experiences: A manufacturing site was switching to another supplier and was under pressure to complete the conversion quickly. The quality engineers from the site presented their data statistically comparing the two manufacturers’ products, with the conclusion that all five materials being switched were the same. This, of course, was great news and would eliminate a significant amount of work by the site. However, this euphoric conclusion was dashed when the statistical analysis was reviewed. The site engineers used a confidence interval of 99% rather than 95%, which is typically used for analysis. This seemingly slight difference was far from slight, because the higher the confidence interval percentage, the greater the margin of error. For example, let’s say there are 10 horses in a race and you want to be sure to pick the winner with 99% confidence. The only way to do this is by stating that the winner is one of the 10 horses. If we used a 95% confidence interval, there is less certainty. We would have to make the statement that the winning horse will come from one of the nine horses you selected. This makes for more uncertainty as the 10th horse could be the winning horse. What the site engineer did in stating the two suppliers were the same at a confidence interval of 99% was in fact using the statistics to conclude they are the same. When they redid the statistics at a confidence interval of 95%, it showed that four out of the five products were actually quite different.

In this case, a knowledge of statistics was being used to avoid doing the proper testing and, conversely, knowledge of statistics helped avoid a potential error that could have been very troubling. Statistics is like a double-edged sword — it can work for you or against you depending upon how it is employed and the intentions behind its use. This is a good justification for having a statistician on a company’s payroll to ensure statistics are properly applied.

Lesson #3: Look Into The Causes Of Testing Anomalies

Statistics is a powerful and insightful tool. When used properly it is extremely helpful and timesaving, and it can help drive you to the right solution. Unfortunately, statistics is only as good as the data and how the data is collected. Further, it has to be applied correctly.

During another personal experience, a supplier was testing a material for release, but when the test was performed by the receiving company, the results indicated the material failed. A review of the testing suggested the problem lay with the testing technicians, with one in particular having very different results from the other technicians; obviously, this technician was one of the reasons for the difference in test findings. Using statistics over many weeks and many different test protocols, we discovered that the testing variations were due to the fact that each technician had to dissolve samples of the supplied material to make a solution. Variations in the amount of the solution dispensed by the different technicians was what was causing the testing anomalies. The fix was to purchase an automatic dispensing machine that removed the variation from the mixing step, and we bought one for the supplier and one for the receiving company. Over 44% of the variation was eliminated.  And that one rogue technician whose testing was significantly different from the other technicians? Turned out the technicians was actually the most accurate and consistent of all of the technicians.

Points To Remember In Using Statistics

These cases and the points made show why it is important for your company to ensure that your project teams have solid training and solid ongoing training in statistics. It is important that teams know how to collect data and how to preserve data integrity. Employ or consult with a statistician who can review project analyses and guide those using statistics to ensure they are using the right statistics and drawing the right conclusions. A statistician is also a valuable resource to verify that statistics are applied and interpreted correctly, to be available as a consultant to product teams, and to educate and improve project teams’ knowledge and use of statistics. After all, statistics are only as good as the inputted data and how they are collected, and the decisions made based upon statistics are only as good as the statistics. In the end, product safety, customer safety, product efficacy, and your company’s reputation and vitality are at stake.

Continuity Is the Key to Success for Your Medical Device Company

Continuity, by definition, is the state or quality of being continuous. To a company, continuity could be the ability to provide a product that consistently performs as expected with consistent quality. It could also refer to a company’s ability to consistently make a product available without supply chain disruption. Financially, continuity could refer to a company’s ability to continuously return an increasing profit.

Critical to continuity in these aforementioned objectives are a company’s short- and long -term plans that provide the approaches on how to fulfill the overall company strategy. It is easy to see that continuity in various areas is key to a company’s well-being. The challenge for medical device manufacturing and medtech companies is maintaining continuity in all of these areas simultaneously. This is not an easy task because it takes coordinated efforts throughout a company’s infrastructure that are tied back to the comprehensive company strategy. Continuity can be impacted by cost-containment initiatives or by cultural factors.

How Is Continuity Impacted By Cost-Containment Initiatives?

When a company focuses on “improving” its bottom line, this is generally done by reducing overhead costs. One common method is to reduce the size of the workforce through layoffs and retirements. Sometimes, a company replaces those employees with contracted services. Contracted services costs can be expensed, which effectively moves a bottom-line cost into the expense column. This move could also result in tax benefits.

Another cost-containment initiative that impacts a company’s continuity is when a company divests itself of direct manufacturing responsibility. Contracting out specific manufacturing processes not only eliminates the associated workforce as a cost burden but also removes direct production responsibilities. In essence, this strips down the company to the perceived minimum needed to maintain or improve current financial metrics.

Workforce reduction or conversion to contract or third-party services does improve the company’s bottom line in the short term, but this approach can be disruptive over the long term if the necessary planning is not put into place. What is concerning about these short-term solutions is their potential to dilute a company’s depth of experience. Outsourcing manufacturing, the increased reliance on contract services, retirements, buyouts, and layoffs all reduce a company’s experience levels. In some cases, a company will gradually return to the pre-cut conditions to compensate for issues and emerging directives.

How Is Continuity Impacted By Cultural Factors?

The dynamics of the work environment are evolving. Gone are the days when a person landed a job and stayed with the company until they retired. A company’s allegiance to its workforce is diminishing while a worker’s allegiance to their employer is likewise diminishing. As soon as an employee lands their current position, they are typically searching for their next job or promotion to improve their earnings or to land a higher-level position. This is quickly becoming the inherent cultural persona of the typical worker. It is not about “what you have done for me?” but more of “what are you doing for me now?”. Resting or relying upon past accomplishments is no longer de rigueur for companies or employees. This lack of mutual commitment translates into a revolving door of personnel, and it is not solely a workforce issue — it is seen in upper management as well. Upper management have similar career desires and shift into different roles within a company or move to different companies as opportunity presents itself. This creates a lot more disruption than at the workforce level because changes in upper management usually result in changes in the company strategy.

What Can A Company Do To Address Knowledge Drain?

The subtle knowledge drain caused by cost-cutting initiatives and cultural changes can affect a company in the long term through lost time, wasted expenses, delivery issues, and manufacturing and quality issues. Employees or management struggle to resolve problems that experienced or well-trained associates could have solved immediately. Without the proper training or experience, new employees or contractors may not have the intimate knowledge of the company’s product(s) or manufacturing processes necessary to avoid needless delays or unexpected costs. If new employees or contractors do not have access to comprehensive documentation, then the typical reaction to resolve a problem is to conduct trial-and-error solutions; these typically do not lead to a prompt solution and often generate additional problems to be resolved.

In one situation I observed, an overseas manufacturing site was struggling for months with a process step. The step was well-defined in our domestic operations but not at this overseas locale. When I visited the site with an associate about an unrelated issue, the problem was brought to our attention. We both had extensive experience in the process they were struggling with. In less than an hour, we had identified the root cause of their problem (there were several problems confounding the situation) and we were able to get them back on track and eliminate the manufacturing issues. In this example, the site had no visibility to the knowledge base of other manufacturing sites performing the same manufacturing steps, nor did they have adequate internal documentation to guide associates on how to resolve the problems they were facing. Management was fairly new as the site had significant turnover, so they were not able to help. If the team had access to a company database or a directory of company resources or had better overall documentation, they could have resolved their issues quickly rather than having months of frustration. We held impromptu manufacturing training and awareness sessions and showed where they could improve their manufacturing documentation. The problems are no longer an issue.

Manufacturing problems can potentially lead to quality issues that could negatively impact the consumer’s perception of a product’s efficacy or performance. Therefore, the two key denominators contributing to a company’s sustained continuity that are often overlooked or marginalized is knowledge retention and comprehensive training. Elements that should be integrated into the company’s short- and long-term plans accordingly. This is especially vital when a company operates globally with manufacturing sites having similar operations. In this instance, it is imperative that test methods, manufacturing processes, and accept/reject criteria be the same. I often saw different manufacturing sites that did not communicate with each other, reject product that another site would accept and vice versa. I like to refer to these scenarios as gems. They represent situations that can be easily resolved that immediately result in two forms of cost savings: reducing product waste and freeing up manufacturing capacity.

While it is true that product evolves by the application of emerging technology and techniques, there are basic elements that tend to be present with any project, and experience can help avoid delays when implementing these new technologies and techniques. Companies should utilize their experienced workers to develop or add to their product and process knowledge prior to leaving the company in the form of thoroughly documenting processes, development work, and troubleshoot techniques/solutions. This creates a solid knowledge base for a company that could also be tapped into during the development of new products and processes to avoiding an unknowing repeat of past negative efforts.

In another example from my experiences, my team was working on developing a new material for a current product line. The material was so unique that current methods did not work. We had to develop almost all new manufacturing techniques. However, we had a lot of experienced people at the time. By culling together all of the product and process experiences, we were able to identify the most promising approaches. These proved successful and saved the project team from very prohibitive delays.

Before enacting significant forms of cost-cutting techniques, a company should have a well-developed product and training/education program for new employees, contractors, and consultants. If a company is global with manufacturing sites around the world, it is imperative that a universal database be implemented for knowledge sharing. Sites performing the same processes should use the same documents. This way, as changes are made and improvements are identified, all sites benefit from the efforts of one site since they are using the same documents. This is especially true for test methods, acceptance criteria, and operating parameters.

In summary, cost-cutting initiatives and high levels of workforce and/or management turnover can be disruptive to a company’s continuity, competitiveness, and long-term vitality. Companies need to develop a flexibility to accommodate and adapt to management and workforce fluidness. It is okay for a company to be aggressive in cost cutting initiatives. However, in order to avoid paying the price down the road, a company must have comprehensive documentation and a thorough workforce training program in place, as they are ideal vehicles for a seamless transfer and retention of knowledge and experience from one “generation” of the workforce to the next. This basic approach could have far-reaching positive impact on companies and bridge the gap between short-term focus and long-term objectives.