Tag Archive for: risk management

Risk Medical

In this blog, we recap the “Understanding Integrated Risk Management for Medical Device” webinar.


Companies involved in developing medical devices understand the importance of risk management, but their approaches can vary significantly in terms of the time it takes to manage risk, the ability to connect risks to specific requirements and tests, and the capacity to pull together relevant documentation for an audit. To meet these challenges, medical device developers need a comprehensive approach to risk management.

In this presentation, industry and solution experts will explore how teams can integrate risk-based thinking into their product development lifecycle.

Attendees will learn more about:

  • Risk management in the medical device industry
  • Guidance and best practices to follow
  • How to manage risk analysis
  • The importance of risk traceability throughout project activities

Below is an abbreviated transcript and a recording of our webinar.


Understanding Integrated Risk Management for Medical Device

Mercedes Massana: So today we’re going to talk about risk management. First, we’ll start with the basics, the things we need to know to understand risk management, then we’ll talk about the elements of a risk management process, about some risk management tools that we can use, and then we’ll end with risk management and incorporating that into your traceability matrix.

So let’s start with the basics. So what is risk management? It’s the systematic application of management policies, procedures and practices to the task of analyzing, evaluating, controlling and monitoring risk. And in this case, we’re talking about product risk, not so much project risk, right? So all medical devices carry some level of risk, no matter how simple they are. There’s always some level of risk for the medical device, and we need to consider who can be hurt by the medical device. Who does this risk apply to? And that can be obviously the patient, but it can also be the operators or clinicians, right? The nurses. It could be bystanders, it could be service personnel working on the device. It could be even other equipment if we interfere with other medical equipment, and it could even be the environment.


Related: Requirements Debt: A Medical Product Program Risk


Mercedes Massana: It is the responsibility of the manufacturer to determine how much risk they’re willing to accept, or the market is willing to accept for the intended use of the device. So the regulatory agencies don’t tell you what is acceptable from a risk perspective, but it’s up to the manufacturer to determine that.

So why do we practice risk management? Well, first of all, it’s so that we can produce safe products and release only safe products, right? So we want to prevent safety-related problems in the field. Having to recall product is very bad for companies, right? There have been companies that have gone out of business because of safety issues in the field. Having a good, well-documented risk management file can substantiate due diligence if somebody tries to sue you, so you have the documents that can help support that you did the right things.

It can also encourage a defect-prevention mindset. So when you start practicing risk management early on in development, you start designing with defect prevention in mind. You want to prevent defects that can cause harm and risk. It helps you identify potential safety issues early while you can still influence the design, right? And then, from a regulatory perspective, documents from your risk management files are always needed for submissions, and in audits, most likely these documents would be presented in audits.

And then it also allows risk-based decisions to be made throughout the product life cycle. So we think of risk management just as the product and things we need in order to get regulatory approval or to have in an audit, but really, having a robust risk management file can help us make decisions and verification, validation in manufacturing, even for our suppliers and what controls we ask them to implement. So having a robust risk management file can really help us in every facet of product development.


Related: 3 Ways Requirements and Risk Management Continue After Market Launch 


Mercedes Massana: So compliance is a big part of risk management. ISO 14971 is the application of risk management to medical devices. It is an FDA-recognized standard. It’s actually even called out in a couple of guidance documents from FDA, and it is referenced by a number of IEC standards. So we need to be compliant with ISO 14971 in order to get through FDA, and in order to achieve the CE mark. ISO 13485 mentions risk management 15 times, and it says that we must consider risk in supplier controls, for verification, for validation, in testing and traceability, for CAPA, even for training of personnel.

So this tells you how important risk management is to having a medical device, developing a medical device, and maintaining a safe device in the field. So risk management should be practiced first as a system-level activity, so we should start risk management from the top down. That means that very early in development, when we start our design efforts, we analyze the risk that the system can perform, just by knowing the intended use. We don’t even need to have a design. Then we attempt to mitigate those hazards and we drive risk controls through requirements that then get implemented in our design, so only the system can actually cause a hazard. The system might have many components, but unless I have all of the system put together, I can’t cause a hazard.

To watch the full webinar, visit: Understanding Integrated Risk Management for Medical Device

RELATED


reduce risk product development

In this blog, we will recap a webinar on reducing risk in product development


Over the last 20 years, product development complexity has expanded exponentially, creating innovations in areas such as space tourism, autonomous vehicles, satellite communications, and more. In this webinar, Kemi Lewis, Senior Consultant at Jama Software, will demonstrate how Jama Connect© creates Live Traceability™ through siloed development, test, and risk activities to effectively reduce risk in the product development process.

In addition to a walkthrough of the platform and our Live Traceability dashboard, we’ll cover:

  • The critical challenges to reducing risk in product development
  • Why deeming requirements “good enough” to allow teams to proceed with an acceptable level of risk culminates in static requirements, unplanned rework, and compounded product risk
  • How “Project management” activity is a fallacy — it is the management of requirements, people, risks, change, opportunities, expectations, resources, commitment, and suppliers

Below is an abbreviated transcript and a recording of our webinar.


Reducing Risk in Product Development

Kemi Lewis: Today’s agenda covers a deep dive into the critical challenges to reduce the risk in product development, what are the viable solutions to this problem, key takeaways, and wrapping up with a question and answer session at the end of the webinar

Let’s get right into it. What are the main critical challenges that product development teams are facing? In my experience, the main factors that lead to adverse product outcomes and risk are, number one, no upfront and iterative collaboration during requirements and design creation and review stages due to limited customer and cross-functional team involvement in the review and approval of requirements. This lack of cooperation results in missed and misunderstood requirements driving the product design into severely costly errors later on.

Second factor, no digital thread connecting the product and team to the end to end product life cycle process. What do I mean by the digital thread? A digital thread is a data driven architecture that links together information generated from across the product life cycle and is envisioned to be the primary and authoritative data and communication platform for a company’s product at any instance in time. Without this digital thread, there’s no ability to track the life of a requirement through development, test and release.


Related Reading: What Is the Definition of a Digital Thread


Kemi Lewis: This missing digital thread results in static requirement documents rarely viewed by critical stakeholders maintained in Word, Excel or standalone tool used only by a few as a repository. I’ve personally experienced this at companies where only the systems engineers were accessing the repository and the rest of the product development team from product managers down to testing and integration engineers never accessed it.

You can only imagine how this turned out. Countless rework during testing and integration in addition to postlaunch rework this early, which was severely costly to the customer and left them very unhappy. So lacking this digital thread leads to no management visibility into crucial metrics for the end to end process and no identification of process risk patterns, such as delays in development, multiple test failures, rework cycles, etc.

Third main factor is having a low level of requirements management maturity. Let’s discuss this in more detail. Level zero: There are no formal requirements. So no documentation exists for user or system requirements. Instead, development operates off of user stories with no clear distinction between the functionality of the system being built and expected user experience. Level one: Document based requirements. Static requirement documents are created and most often maintained by each author on their desktop with various emails, slack comments containing more information. This especially gets fun when you have to merge 10 different versions of the same document from 10 different people from 10 different timeframes, none of which have visibility to each other’s feedback in real time. I’ve seen this at several companies where they lose technical product proposals due to this inefficiency of being able to get a proposal out in time representing the right design specifications of their product.


Related Reading: Bridge Engineering Silos with Living Requirements Management in Jama Connect


Kemi Lewis: Level two: Siloed requirements tool. A standalone tool in place to draft review, track comments, version and store static requirements documents, compliance steps, limited reuse, defects and recalls. Level three: System based compliance. Compliance is the forcing function to shift from static to live traceability to meet standards for requirement validation, verification and traceability into a single end to end system. Level four: Product risk reduction. A process centric focus to reduce the likelihood of all forms of product risk via a system enabled live traceability. This requires detection and alerts for specification and functional changes, process exceptions and test failures with resulting impact analysis. The risks mitigated include failure to meet the needs of the customer, failure to perform specific functions, delays, cost overruns, defects, compliance and regulatory gaps, delays and fines in addition to recalls.

And the last level of maturity, level five: Development process improvement. Moving past compliance and risk into the spirit of standard based on quality management and process control. These stages place focus on measuring, managing and improving the product development process. The unintended result of this fragmented process is that critical function such of requirement, traceability, verification, validation, risk mitigation, product integration and compliance are often fraught with information gaps, defects, delays, reworks, recalls, missed requirements and significant manual effort. This includes all areas of the complex product system and software delivery life cycle that can experience negative outcomes and should be actively managed to reduce the likelihood of appearance, such as performance.

Watch the full webinar to learn more about Lessons Learned for Reducing Risk in Product Development


One of the early steps I advise my clients to take when developing their medical device is to determine the class and classifications of their medical device. In conjunction with the complexity of the device, understanding the class and classification sets the foundation for your product development timeline and effort. 

This post gives a basic introduction to FDA medical device classes and classifications and the implications for your product development schedule and requirements management. 

What are FDA medical device class and classifications? 

The FDA established three regulatory classes based on the level of control necessary to assure the safety and effectiveness of the device. Classification is based on the intended use of the device and indications for use, as well as the risk the device poses to patients and users.   

There are three classes: Class I, Class II, and Class III. Class I devices are those with the lowest risk, Class II devices have a greater risk, and Class III includes devices with the greatest risk.   

The FDA also established classifications for over 1,700 generic types of medical devices and grouped them into 16 panels, or medical specialties. Example panels include Cardiovascular Devices and Radiology Devices. Each of the generic types is assigned as Class I, Class II, or Class III. 


RELATED POST: Complying with FDA Design Control Requirements Using Requirements Management


Impact of the device class and classifications 

The class and classification of the device impacts what FDA premarket submission or application is required for clearance to market. The common premarketing submission or application for each class are:  

Note: These are the common regulatory submission and applications for each class of device. There are exemptions, limitations on those exemptions, special controls that may apply, and exceptions, so be aware whether any of these applies to your device. For example, about a quarter of Class I devices are not exempt, and a 510k premarket submission is required. 

As the process for the 510k submission is 30-90 days, and the process for the more in-depth PMA submission is 180 days to accept or reject, this time should be understood and planned into your product development schedule.   


RELATED POST: Customer Story: Medical Device Startup, Proprio, Chooses Jama Connect® to Drive Innovation


Similarly, expect elements from the required design control process and design history file to be included as part of a 510k and PMA. Also keep in mind that when design controls are required for your device classification, the full design history file can be scrutinized as part of an FDA inspection of your organization. Since the FDA evaluates whether a device is effective and ensures the risk to the patients and users is appropriately addressed, good requirements and risk management is key. It’s important to have an organized manner in which to demonstrate and document that risk management and user needs are successfully traced through design inputs, design verification, and design validation. A requirements management tool like Jama Connect™ allows for this traceability in an efficient, collaborative, and regulatory-compliant manner. 

Understanding your device class and classification is a key step to understanding the path for FDA regulatory clearance and subsequent design control requirements for your medical device development. Knowing those expectations up front will make for a smoother medical device development journey.  

Learn more about developing medical devices with Jama Connect!



Risk Management


Medical Device Risk Management

Medical device developers must ensure risk is addressed as a core activity. The ISO 14971 standard, which has been revised three times, provides a proven and flexible framework around which developers can effectively manage the risk of devices for patients and stakeholders. Knowing the standard and applying some aspects, in a reactive way, is not sufficient to create a safe product. Implementing an effectively proactive process and achieving live traceability throughout development, while adhering to the standard will result in a higher quality and safer product fit for market use.

In this blog, I will share how proactive risk management along with Live Traceability™ are two key areas that every medical device developer should focus on when it comes to risk management.

Reactive vs. Proactive

A lot of medical device developers do not prioritize risk evaluation throughout the different design stages, but instead, consider risk a checkbox activity at the end of development. With important prototype deadlines, limited funding, and resource constraints, it’s very easy to make excuses for not running risk evaluations of initial user needs but waiting until entire subsystems have been designed. This may seem like a minor hiccup, but the lack of ongoing risk assessment from an early stage can be very risky for FDA approval, future patients as well as your business’s bottom line and reputation. The later that risk is addressed, the more expensive changes are to incorporate. Delays become the norm as well as budget overruns.


Jama Connect Enables Live Traceability™ Across Your Development Process: Learn more!


Live Traceability

The number one cause of inspectional observations, product recalls & delays, increased CAPAs, and cost overruns is the lack of live traceability throughout different development stages. With complex medical devices, there can be thousands of user needs, product requirements, risks, mitigating requirements, tests being executed, and defects logged. At Jama Software, we’ve noticed that a lot of medical device developers are using different technologies and applications to store this information including Excel, Jira, Word, and others. The below image depicts that and shows the siloed world a lot of engineering teams are living in:

 

 

Unless you have a real-time system that can interface with spreadsheets, tools like Jira and other applications, it’s impossible to get a holistic view of development. This can cause several issues, some of the most critical being:

  • Late identification of defects/coverage gaps due to lack of visibility throughout the development process​
  • Lack of requirement coordination and change management between hardware/software​
  • Lack of ongoing risk assessment and change management​
  • Cumbersome and risky effort to produce trace reports and other DHF artifacts

RELATED POST: Avoid the Most Common Challenges of the Design History File


Without Live Traceability, risk teams can’t be effective in mitigating potential failures or hazards. Outdated and manually updated trace reports and spreadsheets can’t be relied upon. What if there was a way to get a real-time view of traceability throughout development?

At Jama Software, we’ve created the capability for our product development platform to integrate seamlessly with tools like Excel, Jira, and others straight out of the box, and we are proud to be the only vendor on the market that can help engineering teams realize Live Traceability. Risk should be a priority, not a checkbox item!

Get in touch with us to see how we can help you.




This is Part 2 of a series examining the role legacy requirements management solutions, such as IBM® DOORS®, play in introducing project risk to the product development process. To read Part 1,  visit Why Migrate, Why Now?: Part 1

5 Common Migration Myths Debunked

Transitioning to a new solution doesn’t have to be challenging; however, there are some assumptions that mislead us into thinking that difficulty is inevitable. Consider the following myths:

MYTH 1: Migrating away from IBM solutions will be more expensive. The amount of work that goes into upgrading to IBM DOORS Next or transitioning to a new RM solution is the same, differentiated only by the quality of the tool and services available to help with migration. An option other than the DOORS family is most often a better fit for your organization.

MYTH 2: Customization will carry over to DOORS Next. You spent a lot of time customizing IBM DOORS and may believe those customizations will transition seamlessly to DOORS Next. However, this isn’t the case and is the reason selecting a different solution doesn’t involve more work.

MYTH 3: DOORS is already deployed and cheap to maintain. Continuing the current path with IBM DOORS is an expensive option in the long term, and often requires dedicated personnel. Switching to an alternative RM solution can improve efficiency while saving money.

MYTH 4: Business disruption is too difficult. The right RM tool will empower teams to effectively hit deadlines, collaborate, and improve business outcomes.

MYTH 5: The user experience will suffer. Many people refuse to use DOORS due to a challenging user experience. DOORS Next is a completely new tool with a new user experience. Adopting a user-friendly solution allows teams to collaborate far more effectively as team members can accelerate concepts, designs, and validations for faster times to market.

requirements-management-hub

The fact is, IBM® DOORS® is extremely outdated, and at some point, updates and support will inevitably end.

If you’re currently using DOORS, you likely know that moving to a different solution is necessary, and you might be considering DOORS Next. However, fast-shifting market dynamics require a new approach to accelerate innovation. As a modern alternative to traditional legacy platforms, Jama Connect® enables digital transformation with a more efficient and user-friendly approach to managing risk and compliance.

Customers agree, naming Jama Connect the overall leader (#1) in requirements management software on G2, outranking IBM DOORS Next for implementation time, adoption, ROI, and market presence.

Jama Connect is a proven IBM DOORS alternative with flexible and reliable solutions, including:

  • Operation in an IBM DOORS supply chain.“Innovative companies leverage Jama Connect to get up and running fast with a modern requirements management process that tightly aligns with industry standards and practices that support regulatory compliance. Organizations can connect to customers and suppliers that use IBM DOORS through Data Exchange for Jama Connect.”
  • Integration services. Jama Connect provides integration with key product development lifecycle tools.
  • Coexists with IBM DOORS. IBM DOORS is embedded in many organizations and may take some time to migrate completely. Progressive teams and divisions can get started on Jama Connect quickly while the larger organization works toward replacing existing programs over time. This approach is supported through a mix of integration, migration, and exchange services.

“Jama Connect lowers the complexity and burden of having to manually keep requirements, architecture and specifications all in sync and traced to each other. It’s a formidable problem that is virtually eliminated courtesy of Jama without the hassle of having to learn a clunky UI (IBM DOORS).” Alan M., Chief Product Officer

Jama Connect® created Live Traceability™ management which reduces project development risk by forming a digital thread through siloed development, test, and risk activities. The flexible platform is designed to support the end-to-end product development process with:

  • A simple, single repository so it’s easy for remote teams to gather, review and execute on requirements.
  • Structured reviews and collaboration — teams can elicit feedback, review product features in real-time with stakeholders and track critical decisions across teams and locations.
  • Change management throughout product development — end-to-end traceability and real-time collaboration improve visibility and make it easier to adapt to changes and track their impact.
  • Integrations across the ALM-PLM ecosystem.

Moving from IBM® DOORS® Next to Jama Connect® for Requirements Management

To adapt to shifting and ever-increasing challenges and complexities and keep pace with the competition, innovative organizations are now requiring best-in-class software to scale development, reduce risk, save time, and ensure compliance to quality and safety regulations.

Download this paper to learn how Jama Connect stands out above DOORS Next in the G2 Summer 2021 report for requirements management in the following areas:

  • Overall satisfaction
  • Implementation
  • User adoption
  • ROI

Go live with Jama Connect 2.7x faster than IBM® DOORS Next®


In Conclusion

Products, systems, and software development are only getting more complex and not modernizing your requirements management process will increase the probability of negative outcomes in your product development process.

As your team requires the ability to adapt, innovate, and grow, continuing to use IBM DOORS will become more difficult and will introduce significantly more risk in your product development process. Think about DOORS as a landline rotary phone that stopped being on the receiving end of upgrades after the industry switched to marketing push-button touchtone phones. (And now there are smartphones available, which are mobile and make you even more connected and productive.)

Transitioning to new technology provides your teams with the tools required to innovate, meet deadlines, and succeed. A modern requirements solution can help you to define, manage, and validate complex systems requirements while eliminating the risks and inefficiencies associated with documents and legacy systems.

Hear about the experiences of the more than 50 companies that have made the switch from IBM DOORS to Jama Connect.

Connect with us today to learn how you can enable end-to-end compliance, risk mitigation, and process improvement with our intuitive, award-winning requirements management platform.

To read this series in its entirety, visit this whitepaper: Why Move Away from IBM Doors Legacy and Why Now

 



Requirements and Risk Management


Congratulations!  Your organization has gained regulatory approval and launched its medical device product.  The ‘History’ in Design History File may elicit impressions that all those design and development requirements are now done and considered part of the past.  However, several components of the DHF continue as a reference and evolve, including requirements and risk management.  Here are 3 ways active management of requirements and risk continues after commercialization:

1: Post-market surveillance

Once your medical device is on the market, post-market surveillance programs, including complaint management processes, must now be exercised.  That includes evaluating feedback, determining if it is a complaint, investigating complaints, and determining whether to initiate corrections or corrective actions.  As part of this process, requirements and risk management are being used in 2 ways, 1) as a resource to evaluate complaints and 2) a living document to be updated with the experience gained.

As a resource, it is important to reference risk management files to determine if the frequency of occurrence and types of failure modes documented during design and development matches the infield data being gathered.  A more frequently occurring failure or new failure mode indicates an investigation is warranted and re-evaluation of the risk.  Depending on the outcome, corrective action may be needed.

For example, during design and development, it was determined that a sensor failure leading to customer annoyance occurred rarely, leading to a low risk rating at the time of market launch.  The first year on the market, reports of this failure occurred rarely, matching the occurrence rates in the risk management file.  Given the low risk and lack of trend, further failure investigation and corrective action were not taken.  However, one year later, a change in supplier coincides with a change in occurrence from rarely to frequent, leading to a medium risk.  This increase in risk prompts an investigation to determine why the sensor failure rate is higher and to determine corrective actions and controls with the new supplier.

As a living document, the risk management files are to be updated with the observed occurrence rates, new cause(s) of the failure mode of the sensor, mitigations and controls put in place, resulting verifications, and revised risk rating.

2: New Products

Another reason requirements and risk management continue once a product is commercialized is to aid in the development of new products, including line extensions, new models, and next generation platforms and portfolios.

The existing product’s requirements and risk management, supplemented with what is learned from post-market surveillance and other feedback from the field, provide the foundation for new products.  A requirements and risk management tool like JAMA Connects® can simplify the management of requirements and risks shared between products to keep teams aligned and prevent requirements or risks being missed during the transfer from one product’s design history file to another.  Likewise, line extensions can be more easily incorporated into an existing design history file if requirements and risk management have been properly updated as needed and are accessible.

3: Change Control Evaluation

Change control evaluations is another way management of requirements and risks continue after commercialization.  Changes to a product and how it is manufactured occur for many reasons, including replacement of a component that has reached its end of life from a supplier, software upgrades to address bugs, duplication of a manufacturing line, and changes that address complaints.

Changes must be evaluated as to their impact on the form, fit and function of the product, and can have varying degrees of potential impact.  Well managed and active requirements and risk management, with traceability to design outputs and verification, become a strong tool for organizations to evaluate the potential impact more quickly.

For example, say a temperature sensor was added as mitigation to prevent overheating of a medical device; overheating that could result in burns to the patient.  The sensor, including the necessary accuracy, is listed as a control for the risk of overheating and burns.  There’s also a corresponding design requirement, and the sensor and its specification are linked as design outputs.  The supplier of the sensor has recently informed the medical device manufacturer that the sensor is reaching its end of life and will no longer be available in 6 months’ time.  A change owner is assigned to identify and evaluate a new sensor.  This person is most likely not the same engineer who originally designed and selected the first sensor.  And that the original engineer may or may not still be with the organization, and may not remember why that sensor was selected.  This is where having accessible and well managed requirements and risk management becomes important.  The change owner can reference and look up the sensor, see the design inputs and risk with which it’s associated, and understand more quickly the criticality of the sensor and ensure the proper selection and testing are performed on a new sensor.

While change post-commercialization is inevitable, difficult change control management is not.


RELATED POST: Product Development Process: How Confident Are You That You Are Not at Risk?


Beyond Commercialization

Management of requirements and risk extends through the entire life cycle of a medical device, including after a device has gained the necessary regulatory approvals and reached the market.  Thus, take care in selecting the tools and developing the processes your organization uses for requirements and risk management.

 



Requirements and Risk Management

In this post, we will discuss why start-up medical device companies should prioritize requirements and risk management before a quality management system.

As a medical device product development consultant, I often see start-up companies having trouble deciding what to prioritize – design controls and risk management or the quality management system (QMS).  And what they mean specifically is, which software systems should the company invest in first – the requirements and risk management solution that will aid in building a regulatory compliant design history file, or the electronic-QMS system to establish the FDA required and ISO 13485-compliant QMS?

From my experience over the past 15 years, here are the 3 reasons why I advise start-ups to prioritize requirements and risk management over an eQMS system.

1. Design controls and risk management processes start earlier

For best product, schedule, and compliance success, incorporating design controls should be done proactively instead of reactively.  Companies are typically developing their medical device from day 1.  This is compared to other QMS processes that may not be used until years later when the product is being transferred to manufacturing and being commercially distributed.  A few of these other processes include non‑conforming materials, device master record, product change control, and complaint management.

Thus, purchasing a full eQMS system earlier than necessary results in paying for functionality that may not be used for years.  That is of low value to the start-up closely watching its funds.

In contrast, as the medical device is being developed from the onset of the company, the benefits of requirements and risk management solutions can be realized very quickly and much sooner than a full eQMS system.

2. Requirements and risk management is often unwieldy

Unless your device is ‘simple,’ for example no software, no electro-mechanical parts, low-risk Class 1 devices; thoughtful consideration should be given to the processes and solutions that will manage the various requirements and risk management for your medical device development.  Organizing all the user needs, design inputs, regulatory requirements, requirements from industry standards, system requirements, sub-requirements, and risk management can quickly become unwieldy without proper management.

In my experience, even a Class II electro-mechanical device can easily approach a thousand line items to manage and connect.  Add on embedded software or a digital interface, and that number can easily jump to multiple thousands of line items or more, depending on the complexity of the medical device.  A solution like Jama Connect® has immediate value to ensure all items are linked, traced, verified, and validated for a regulatory complaint design history file and medical device file.

3. In the early years, a company can create and manage a regulatory compliant QMS without an all-electronic system

Does forgoing the eQMS mean settling with a non-compliant QMS?  No.  A company can implement a regulatory compliant QMS without an eQMS system.  SOPs can be implemented in stages, prioritized on the stage of the company.  These SOPs, along with a cloud-based document sharing repository, is often sufficient in those early product development years.  As the company approaches transfer to manufacturing and commercial distribution, then is the time to evaluate whether it’s time to transition to an eQMS system.

Summary

In summary, these are the three reasons I advise start-ups to prioritize requirements and risk management first before an eQMS system.  This path allows for the development of a successful product and complaint design history file, as well as establishing the rest of the quality management system, all in a practical manner that maximizes value and meets regulatory expectations.

 


Risk Management

In this post, we look at how Teledyne e2v leverages Jama Connect for improved communication and better risk management. 


Teledyne e2v is a global leader in specialized components and subsystems for innovative solutions in medical, science, aerospace, defense, and industrial applications.

  • Over 1600 employees in countries across Europe, America, and Asia.
  • As a result of their track record of innovation and technological breakthroughs, Teledyne e2v continues to be involved in many high-profile ground-breaking programs

Teledyne e2v’s success is built on long-established relationships with industry partners. The combination of their strong, in-house technical capability and links with technical authorities and universities, ensures that they can bring together the right level of expertise for a diverse range of technical challenges.

They offer:

  • RF Power solutions for defense, medical, marine, industrial, and security applications
  • Imaging solutions including CCD and CMOS sensors and cameras, for space and earth observation, life science, machine vision, and medical applications
  • Semiconductor solutions for aerospace and defense hi-rel microprocessors, high speed data converters, and high reliability ICs

A Single Source of Truth Increases Product Development Efficiencies and Improves the Flow of Information for Teledyne e2v

To meet the challenge of producing components and systems with increasing complexity, Teledyne e2v turned to the easy-to-use Jama Connect platform to provide a single source of information and end-to-end traceability for some of their product development teams.

OBJECTIVES

  • Optimize information flow
  • Improve formal review process
  • Find a product development tool that would garner broad adoption

After selecting Jama Connect, Teledyne e2v saw these results

Time-Saving Efficiencies in Meeting and Decision Making

With the single source of truth and real-time structured collaboration that Jama Connect provides, the Teledyne e2v team has streamlined the development process resulting in increased cross-team efficiencies and expedited decision making.

Streamlining and Simplification of Tools

After determining that Jama Connect was a sensible, easy-to-use, and easy to adopt tool that would increase efficiencies, having a customer saying they were going to use Jama simply sealed the deal and is helping Teledyne e2v achieve their goal of streamlining and simplifying their tools and processes.

Jama Connect has enabled a focused model of engineering leadership, with identified owners of top-level vision, and a streamlined, single source of truth. This has shown strong potential to leave developers with greater freedom to manage the detailed development and implementation in-line with the vision that is clearly communicated and controlled within Jama Connect. Leveraging this further across all projects and product developments is a key ambition for the team.

Driving Systems Thinking Across the Organization

Teledyne e2v’s leadership knows that tackling complex engineering problems and projects requires a structured and systematic approach. They needed a tool that would support their engineers and technical specialists to work in a structured way—without the tool getting in the way. Jama Connect enables this and is helping to drive systems engineering discipline further into the team, not only standardizing the way people work, but making it a positive experience.

To see how the team is now leveraging Jama Connect and how their risk management process has already improved, read the full customer story here.



autonomous vehicles

Editor’s Note: This post about how autonomous vehicles was originally published here on EngineerLive.com on October 6th, 2020, and was written by Jeremy Johnson, Jama Software’s Vice President of Product Management.  

Never before have so many automotive engineers been tasked with bringing increasingly complex machines to market as they have with autonomous vehicles (AVs). Not to mention, it’s not simply a game of speed – elevating only the companies which manufacture products quickly – but a matter of those organizations taking these steps, while pushing the envelope on innovation and prioritizing consumer safety.

While important advancements are being made daily to bring fully autonomous vehicles into commercial availability, we are still a ways off from seeing the Level 5 autonomy we hope for. We’ve witnessed this in the significant challenges and shortcomings reported in the news in recent years, even amongst some of the biggest names in autonomous vehicle production. There are, however, a few actions engineers can take to stay nimble, innovative, and reduce the number of safety-critical mistakes throughout the development process.

Focus on your core business: advancing technology

This is particularly important for start-ups or companies looking to apply their technology to the automotive space for the first time. If you’ve heard the saying “don’t reinvent the wheel,” it comes into play when considering what processes and procedures for meeting industry best practices must be in place. Seek a consulting or technology partner that can enable your business to continuously practice requirements, risk, and test management in alignment with market standards such as ISO 26262 and ISO/PAS 21448. By starting with a proven framework that can be applied and moulded to a particular business, engineers can focus their innovation and organizational energy on delivering new technology to customers.

This focus is noticed in how Tesla drives its business, where the organization leans more heavily into internal development to drive technology advancement and differentiation in the marketplace. Audi, which attempted to meet Level 3 autonomy with its 2019 A8, sought outside suppliers such as Aptiv, Intel, Infineon and NVIDIA– a different approach to Tesla. Although Audi ultimately pulled back stating the car was too far into the lifecycle, it was realized through properly executed business and safety procedures.

Support collaboration internally and externally

Rapid innovation requires tight collaboration, often occurring across various hardware and software teams, and increasingly with partners or traditional competitors. Whether a formal joint venture or targeted collaboration around specific technology development, this “co-competition” has become more common as companies look to drive innovation in AVs forward.

Ensuring the tools and processes to enable this collaboration are in place, and capturing the critical output that comes with it, will guarantee that R&D efforts move quickly while maintaining strong focus on verification and validation. It’s especially important engineering teams get out of their silos and work with adversaries on this front, because in the U.S. in particular, there’s no mandatory compliance enforced by the government to follow standards such as ISO 26262 or SOTIF.

There have been promising signs of collaboration by some automotive companies to exchange learned information during AV development. One example is the collaboration among Aptiv, Audi, Baidu, BMW, Continental, Daimler, Fiat Chrysler Automobiles, Here, Infineon, Intel, and Volkswagen to develop a whitepaper, “Safety First for Automated Driving,” describing a potential framework for the development, testing, and validation of safe AVs.


RELATED: Watch a demonstration of the Jama Connect for Automotive Solution


Maintain traceability of requirements, tests, and risks

Developing complex, safety-critical systems that marry software and hardware requires a great deal of rigor and planning. Keeping track of each step of the development process with cumbersome documents and spreadsheets greatly hinders engineers’ ability to remain agile. By ensuring all of these steps are tightly managed, integrated into other product lifecycle phases and available for flexible reporting will enable organizations to innovate quickly. This also allows for prioritization of safety and compliance and the ability to rapidly adapt as the regulatory landscape continues to evolve..

Most countries do not yet have specific regulations that govern autonomous vehicles, leading to uncertainty around requirements, reporting, and future regulatory compliance.  As previously mentioned, in the U.S. there is also an absence of tightly defined regulations which means states could implement differing standards that require specific nuances in technology and regulatory compliance. There’s also basic differences in infrastructure that makes development and safety a challenge – such as variability in road surfaces, lane markings, and signage.

The key for teams in this fluid environment is to remain close to standard development and regulatory agencies, as well as supply chain partners, to define and influence these regulations. And they must be prepared to show traceability of requirements, risk, and testing information in multiple formats to support the various potential points of oversight – be it downstream customers or regulatory auditors.

Ultimately, we’re likely a decade or more away from commercial availability of a Level 5 autonomous vehicle. As we inch closer, it’s vital engineering teams take advantage of the modern systems management tools at their disposal in order to get it right now – before it’s too late.


To see more information related to the automotive development industry, we’ve compiled a handy list of valuable resources for you!

SEE MORE RESOURCES

 

Today we are excited to announce the availability of Jama Connect for Airborne Systems, a solution designed to help systems engineering teams reduce barriers to the compliance process for their aircraft and aviation systems development process.  

Jama Connect for Airborne Systems lets customers seamlessly manage requirements, risks, and tests in one powerful platform while supporting mission and safety-critical standards.  The solution is built with the digital engineering ecosystem in mind, empowering engineering teams to better manage requirements, while simplifying regulatory alignment for civil aircraft system development, including ARP4754/ED-79.  


RELATED: Learn More About the Jama Connect for Airborne Systems – Getting Started Edition


The aerospace and aviation industry is experiencing innovative changes not seen for decades, where rapidly evolving technology has driven companies to develop disruptive products. The first commercial greater than 50-seat hybrid-electric aircraft is expected to make a fare-paying flight by 20321 and the FAA estimates over 545,000 commercial drones to be in use by 2021.2 Innovation brings increased complexity in the design process, including the connected networks that handle autonomous flight systems and unmanned, autonomous aircraft. The industry currently relies heavily on paper documents to track requirements— which simply can’t be depended upon in a digitized world with predominantly autonomous aircraft.   

The Chosen Solution for Leading Aircraft Companies

As the chosen requirements management platform for five of the leading global electric aircraft companies driving innovation, Jama Software recognizes and answers these challenges. The company has worked closely with its partners to provide an all-in-one solution to address and overcome these challenges with ease. Jama Connect for Airborne Systems helps engineering teams get set up quickly, allowing them to focus on product design and innovation, while reducing the costs and effort required to align their development processes to meet mission and safety-critical standards. 

Aerospace systems engineering teams have a tough job: they are tasked with developing innovative, mission-critical systems at an accelerated pace and with unwavering quality standards,” said Keith Johnson, Chief Solution Officer at Jama Software. “Our new solution, designed specifically for these teams, will help facilitate the development process from start to finish. Jama Connect allows developers to hit the ground running with a purpose-built, out-of-the-box framework and bestpractices guides that save critical time in the engineering process.” 

Key features of Jama Connect for Airborne Systems

  • Frameworks aligned with key industry standards and regulations: ARP4754/ED-79, DO-178C/ED-12C, and DO-254/ED-80 and SEBoK 
  • Best practices, including procedure and configuration guides for aircraft and aviation systems development 
  • Export templates and reports, including requirements specifications  
  • Supply chain collaboration to enable an ongoing exchange of requirements between customers and suppliers 
  • Training and documentation aligned to aircraft and aviation systems regulations, which provides accelerated onboarding to set systems engineers up quickly 

To learn more about how Jama Connect for Airborne Systems helps teams to improve their ability to communicate, track, and test requirements for teams in the aerospace industry, download our solution overview. 
 DOWNLOAD NOW