Make Products Not Problems: 4 Ways to Fix the Foundation

Fix the Foundation: Considerations to successfully affect change in a regulated medical device organization.

Executive Summary

Orthogonal is pleased to publish this guest blog by Rich De La Cruz, President of Silver Lake Group, Inc. (SLGI), a highly regarded expert in MedTech. Please see the end of this blog post to read more about Rich’s professional background.

In this blog, Rich introduces a framework to help product development organizations – including highly regulated medical device software development firms – address foundational issues facing their business. People, Processes, Tools and Infrastructure are woven together in a development ecosystem, and failure in one system leads to the downfall of the others. To properly “fix the foundation” of an organization, one must first understand all the underlying and interlinked aspects of the ecosystem.

Accompanying Rich’s blog are illustrations done by Izzy Hall. 

Introduction

As we’ve seen from the 2008 financial crisis, companies, systems, and institutions that on the surface, do not appear to be linked are actually part of an invisible ecosystem.

An example I like to use is a fish tank. A fish tank seems simple on the surface: it has a container that holds water, fish and something that generates bubbles. In actuality, it’s a complex ecosystem, where every component has to be in balance, and where a failure of one part of the ecosystem can cause a domino effect precipitating a cascading series of failures resulting in sick or dead fish. 

The Medical Device development ecosystem is comprised of interlinked parts that include People, Processes, Tools and Infrastructure. The interrelationships between those parts are not always visible. Regardless of visibility, changes to any of the parts of the ecosystem without fully understanding the impact of those changes between those parts may have unanticipated and unwanted results. Even though the interrelationships of the ecosystem are invisible, when they get out of balance the result can be catastrophic.

Typically, when Medical Device development doesn’t go as planned, organizations look for a single root cause for failure. They find it where they are looking: a software bug, a use case not envisioned, a requirement not tested, a tool that fails or conformance issues. 

Singling out a root cause may be expedient, but it rarely fixes the underlying issues. The reality is that problems occur in the Medical Device development ecosystem due to the failure of related systems. A single root cause is seldom the true source of the problem. 

To meet development objectives and goals, Medical Device development companies need a well-defined and dynamic structure where all components of the development ecosystem work in balance. When not in balance, performance, repeatability, quality and output can be affected. 

There is no defined standard for what should be in place to succeed at Medical Device product development (the what you must do is mostly defined, but not the how). The mix of People, Process, Tools and Infrastructure are as varied as there are Medical Device development organizations.

People

People are an integral part of the Medical Device product development ecosystem. Understanding the capabilities of your people and the ecosystem they operate within is critical to fix the foundation.

Prior to evaluating your people, you need a crystal-clear idea of what you want that organization to accomplish, today, tomorrow and in the future. The first step is developing a comprehensive Strategic Plan. Implementing improvements without a Strategic Plan is like changing the Ph level in your fish tank without knowing what the fish can tolerate: You might not get the results you want.

Strategic Plans should have short-, mid-, and long-term vision and goals. When a Strategic Plan is completed, we can look at the people and the structure of the organization. Hard decisions may have to be made to build the type of organization that has the highest likelihood of being able to meet or exceed the Strategic Plan. 

Organizational transformation requires an in-depth understanding of your Strategic Plan, your product portfolio and the capabilities of the people in your current organization. With that understanding you can start building an organizational structure that provides the right environment for your people to succeed, part of a process I call “Structuring for Success”. Too frequently when evaluating organizations, you can see that they are structured to fail.

Fixing the People parts of your ecosystem won’t solve all the problems on its own. There’s a difference between investing in the right people and developing and maintaining an ecosystem that will support them. 

A poorly designed ecosystem won’t succeed even with the right people for the job; likewise, a great organization cannot succeed when staffed with the wrong people. It’s very important to design an organization that fits seamlessly into the overall product development ecosystem and provides an environment that encourages and enhances the performance and growth of the people that operate within. 

Process

Process provides guidance on what needs to be done, and is an important part of how the ecosystem operates. Unfortunately, in most organizations, the conglomeration of processes that comprise the Quality systems and product development procedures resembles less a purposeful structure and looks more like a game of pick-up-sticks.

Over time, as products grow in complexity, many organizations continue to use the same processes and tools that initially served their needs but fail to be effective as needs, guidance and standards evolve. The “pick-up-sticks” equivalent of a Quality system and Standard Operating Procedures (SOPs) (dubbed “PUSQS”) is an interweaving of new and old, of different scopes, look and feel, purposes, appropriateness that result in a complex, convoluted and difficult to use process. Ad hoc efforts to update or add functionality can result in process documentation that is convoluted, difficult to follow and obtuse as different hands just make it worse. Exacerbating the issue is different groups within the company being responsible for different components of the process: R&D, Manufacturing, Quality and Regulatory. 

Regardless of what processes are called, when combined, they are the framework that defines how things work within the ecosystem. There are many models on how processes are managed, with no one method being better or worse than the others. 

Processes should be clear, concise, unambiguous, and verifiable. A simple way to determine if your processes meet those criteria is to have an independent audit of the objective evidence of compliance to those processes. The wider the variance in the objective evidence produced, and the number of findings, the more likely you need to improve your processes. Ultimately, if you have a PUSQS, it will cost the company time, money and perhaps even the success of the company. 

Tools

In the ecosystem, Tools are both software and hardware, are dynamic, applicable to a specific task and integral to the development of your products.

In many companies, engineers or scientists use different tools to perform the same task. An unmanaged tool inventory can create a proliferation of different tools to perform the same task, and result in significant overhead and cost to support. Indirect and hidden costs of tools are seldom calculated into the cost of ownership. 

There’s often a disconnect between the company’s validated tool library and the tools that engineers and scientists actually use. The inability to keep the tool library up to date is exacerbated by the ability to easily download tools via the Internet. It is important to note that the use of purchased tools may not align with the guidance and standards for software validation.

Often, the tool selection criteria is defined by the group that is evaluating the tool. In this case, the reason for evaluation is usually based solely on the tool’s ability to meet that group’s needs. An option to mitigate this issue is to have a company-wide standardized process for evaluating new tools, acceptance of the tools, and placing the approved tools into a library.

Having a process for purchasing new tools can clash with the desire of R&D to move quickly. Balance is key. The process developed should accommodate the need to move quickly while laying our reasonable requirements. One method would be to establish a team whose responsibility is to find, evaluate, validate and deploy new tools within the development environment before they are needed. 

Decisions around tool selection should be based upon a comprehensive and unbiased evaluation of the tool’s merits and its impact, beyond the suitability of the product, to perform a single given task. I was once involved in an interesting meeting with a software development team. The team was enamored with a particular tool they really wanted to purchase. Thus, when they evaluated the tool, their assessment did not include the impact to the project schedule or the cost. 

I suggested they should factor in the total impact of the tool to the overall schedule of purchasing and deploying the product. After assessing the impact to the project schedule to use the tool, which included training, impact to documentation and SOPs, deployment and validation, they decided to continue using the old tool.

The tool selection process, if unmanaged, can add significant, hidden costs to the company, waste time and budget and have an impact on resources. When tools are managed well, you can realize a significant cost-saving year after year as well as keep projects and processes on time and on budget.

Infrastructure

Infrastructure provides the framework that links and supports the entire development ecosystem. While tools are dynamic and applicable to a specific task, infrastructure is static, often slow to change and spans the entirety of the ecosystem. Examples include internal LAN or WANS, network email, finance, and human resource systems. If the infrastructure is well integrated with the People, Process and Tools it supports, product development teams excel. When not integrated, it makes development difficult. 

I.T. is a core infrastructure to most product development ecosystems and supports the organization’s information highway. All the information that the organization manages resides at points along this highway. 

For an interesting test, ask the group responsible for the I.T. infrastructure to supply a Data and Program map. This map should show how information is managed for each user, how Programs or Tools are used and how the data produced is managed. To efficiently manage the data, you must understand how the data morphs from one system to another, as well as how information is managed throughout the lifecycle of the product.

Infrastructure tends to be physical, and its limits are exposed when engaging remote teams. A growing number of product development organizations have expanded the development paradigm to include geographically mixed development teams. Issues arise when there is a lack of a definition on how infrastructure supports remote, multi-country product development. Problems with management of data and configuration are significantly exacerbated by increases in distance and the proliferation of time zones.

To test how well your infrastructure is organized, define all the touch points expected to be in place for your local organization and ask how they are handled for your remote organizations. If a problem is revealed, try to identify what needs to change in the infrastructure part of the ecosystem so that the remote user has the same experience as the local user. Processes and tools that have always worked in the office may not transition well to remote teams.

For product development to operate effortlessly, all touch points between product development and the infrastructure should be clearly defined. I.T. understands systems, R&D understands development, but they do not necessarily understand each other, or each other’s needs. In many cases, I.T. and R&D are fully opposed in their goals. I.T. has a requirement to keep the infrastructure working at a defined level, while R&D wants to move quickly and frequently throws things at the infrastructure that slows it down.

Conclusion

The concepts of People, Process, Tools and Infrastructure must be in balance to ensure a solid foundation for the ecosystem. When they aren’t in balance, the organization does not produce products: they produce artifacts of the area out of balance.

The error made by many organizations is trying to solve a problem without a complete understanding of the Medical Device product development ecosystem. People, Processes, Tools and Infrastructure are intertwined and contribute to success or failure of the ecosystem. Changes must be evaluated with a clear understanding of how they fit into and affect the ecosystem.

Developing a clear and unbiased understanding of your ecosystem is a critical step to improving your ability to produce products and demonstrate conformance. If you do not know what is broken, how can you fix it? “Fix the Foundation” starts with understanding all aspects of your ecosystem, determining what is out of alignment and developing a clear strategy for improvements.

About the Author

Rich De La Cruz is President of Silver Lake Group, Inc. (SLGI). De la Cruz brings a unique set of skills to writing this blog, having been both a Senior Director of Quality and a Senior Director of Software Development at Fortune 500 Medical Device companies. Rich has been in the regulated medical industry for over 35 years and has helped develop and manage 25+ medical devices including infusion pumps, pain pumps, hemo and peritoneal dialysis instruments, Class I & II clinical software and systems, pharmacy systems and Electronic Medical Records systems. He also has significant experience performing due diligence on medical device companies, as well as Quality System and Design Control Improvements strategy

Rich plays an active role in MedTech standard including:

• ISO/IEC 62304 Software Lifecycle working group 2015-2021 (co-chair)
• AAMI SM-WG01 – Software WG (member)
• AAMI SM-WG01-TG01 – Health Software Quality Management TG (member)
• AAMI SM-WG02 – Information Technology Networks WG (member)
• Joint ISO/TC 215 – IEC/SC 62A WG (member of international working group)
• AAMI TIR45 (member)

Finally, Rich is a “fellow traveler” who shares our belief that the MedTech industry can rapidly improve patient outcomes by adopting fast feedback loop techniques to the development and enhancement of Software as a Medical Device (SaMD), DTx and connected medical device systems.

You can reach him at [email protected]

Izzy Hall

Izzy Hall is a Content Writer and Strategist at Orthogonal. They are also a cartoonist. Izzy has contributed writing, editing and graphics to Orthogonal’s new website and Insight blogs.