This blog recaps our recent Whitepaper, to download the entire thing, visit “Bridging ALM and MBSE for Modernized Systems Engineering Practices.”

Bridging ALM and MBSE for Modernized Systems Engineering Practices

1: Introduction

In an era marked by rapid advancements in technology, the aerospace and defense industries face increasing complexity in systems engineering. Addressing these challenges requires a paradigm shift towards more integrated and collaborative workflows. This whitepaper explores the essential relationship between Application Lifecycle Management (ALM) and Model-Based Systems Engineering (MBSE), highlighting how bridging these disciplines can modernize systems engineering practices.

2: The Growing Complexity of Systems Engineering

The complexity of systems engineering has grown exponentially in recent years, driven by advancements in technology, globalization, and the increasing interconnectivity of systems. Modern systems often integrate a wide array of specialized components, from hardware to software, all of which must seamlessly function as a whole. This challenge is further compounded by the need for performance optimization, cybersecurity considerations, and adherence to regulatory and safety standards, which vary across industries and regions.

For example, in the aerospace sector, the development of next-generation aircraft requires the integration of advanced avionics, autonomous systems, and material innovations. These aircraft must not only meet stringent performance criteria but also comply with international safety regulations and environmental standards. Similarly, in the defense industry, modern weapon systems rely heavily on interoperability between software-driven subsystems, such as sensors, communication networks, and artificial intelligence algorithms, all of which must operate flawlessly in highly dynamic environments.

To manage this complexity effectively, systems engineers must adopt integrated methodologies that bridge gaps between disciplines and stakeholders. Traditional linear workflows and siloed engineering practices can no longer keep pace with the demands of today’s systems. The introduction of tools and frameworks like MBSE enables teams to visualize and validate system designs in a digital environment, ensuring all components meet specifications before physical prototypes are developed. Combined with ALM, MBSE enhances traceability and communication, fostering collaboration across various teams and ensuring that every aspect of the system remains aligned with the overall mission objectives.

By leveraging integrated approaches and modern engineering tools, organizations can address the escalating challenges of systems complexity, enabling them to deliver innovative solutions while minimizing risk and maintaining efficiency.

The demand for innovative, safe, and efficient systems in aerospace and defense has led to unprecedented levels of complexity. Systems engineering processes need to manage a significant volume of requirements, design models, stakeholder expectations, and compliance standards. Traditional engineering approaches fall short of addressing these demands effectively, creating the need for solutions that promote end-to-end traceability and model-driven development.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution

3: ALM and MBSE Defined

3.1 What is ALM?

Application Lifecycle Management (ALM) is the framework that encompasses the entire lifecycle of a system, from concept and design to implementation, testing, and maintenance. ALM ensures alignment between business needs, development efforts, and operational goals.

3.2 What is MBSE?

Model-Based Systems Engineering (MBSE) represents a paradigm shift by focusing on the use of models as the primary means to design, analyze, and validate system behavior. MBSE emphasizes simulation, system-wide visualization, and clear documentation to foster collaboration and problem-solving.

4. The Value of Integration

Integrating ALM and MBSE enhances engineering by enabling a seamless flow of information and fostering cross-disciplinary collaboration. This integration is fundamental to achieving traceability between requirements, design, and verification, ensuring that projects meet critical objectives efficiently.

4.1 Improved Traceability

By linking tools like Jama Connect with system modeling tools, teams can create a direct trace from system requirements, design decisions, test cases, and compliance reports to the system model analyses, parameters, and behaviors. This level of traceability minimizes risks and helps ensure that the final product aligns with initial specifications.

4.2 Enhanced Collaboration

Bridging ALM and MBSE facilitates better communication among stakeholders by providing shared insights and clear documentation of system behaviors. This reduces misunderstandings and promotes alignment across all project phases.

4.3 Accelerated Development Cycles

Integrated workflows reduce redundancies, streamline handoffs, and eliminate rework, allowing engineering teams to accelerate system development while maintaining high quality and compliance standards.

RELATED: Compliant Engineering: Leveraging Live Traceability for Regulatory and Product Compliance Success

5. Tools to Enable ALM and MBSE Integration

Jama Connect for MBSE

Jama Connect is a powerful tool that brings cohesiveness to Model-Based Systems Engineering by enabling efficient requirements management, traceability, and collaboration throughout the system lifecycle. By integrating with MBSE processes, Jama Connect provides a centralized platform where teams can define, manage, and validate requirements while ensuring alignment with system models. Through its robust traceability features, Jama Connect ensures that every requirement is linked to design elements, testing artifacts, and verification processes, creating a comprehensive digital thread.

One of the key strengths of Jama Connect is its ability to foster collaboration among diverse stakeholders. The platform offers an intuitive interface for real-time communication, enabling engineers, project managers, and business teams to work together seamlessly, ensuring clarity and reducing the risk of misunderstandings. Additionally, Jama Connect’s alignment with compliance standards streamlines audits and regulatory reviews, essential for industries with rigorous certification requirements.

When linking Jama Connect with system modeling tools, such as SysML modeling solutions, Jama Connect facilitates continuous synchronization between system requirements and system architecture models. This reduces errors, eliminates redundancies, and supports iterative development, helping teams adapt to changes quickly. Ultimately, Jama Connect empowers organizations to align engineering objectives with business goals, ensuring that the end product meets customer needs and system specifications efficiently.

LemonTree.Connect™ for Enterprise Architecture

LemonTree.Connect™ acts as a bridge between ALM and MBSE tools, offering advanced capabilities for merging and synchronizing data to maintain consistency across systems models and requirements.

When used together, Jama Connect and LemonTree.Connect™ create a unified environment for modern engineering practices.

TO READ PARTS 6 – 10, VISIT:
Bridging ALM and MBSE for Modernized Systems Engineering Practices

Expert Perspectives: The Shift Towards Systems Engineering in the Architecture, Engineering, and Construction (AEC) Industry

Welcome to our Expert Perspectives Series, where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields.

In this episode, Jama Software’s Joe Gould sits down with Burzin Tampal, an experienced senior systems engineer, as they discuss the construction industry’s shift towards systems engineering.

Watch the full interview to learn more about:

• Robust requirements management in the construction industry, enabling teams to better meet client needs, comply with regulatory standards, and deliver projects efficiently
• The adoption of systems engineering in construction projects
• The challenges faced in implementing these methodologies, and how major companies are adapting to this change

Kenzie Ingram: Welcome to our Expert Perspectives series where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future in their fields. I’m Kenzie, your host, and today I’m excited to welcome Burzin Tampal, a well-respected Senior Requirements Manager from Toronto, Canada with more than 10 years of experience in systems engineering.

Burzin has worked on major projects within infrastructure, energy, and mining markets across all phases of the project lifecycle. He specializes in developing and implementing processes for requirements management, verification and validation, and interface management on complex projects. Joining Burzin is Jama Software’s own Joe Gould, a seasoned Senior Account Executive with extensive experience in sales within the architecture, engineering, and construction industry. Today, Burzin and Joe will be speaking with us about the shift towards systems engineering in the architecture, engineering, and construction (AEC) industry. Without further ado, I’d like to welcome Burzin Tampal and Joe Gould.

Joe Gould: Hello, everyone. I’m Joe Gould, Senior Account Executive with Jama Software, and welcome to today’s interview with an expert. I’m thrilled to have Burzin Tampal with us, a seasoned expert in systems engineering. Today, Burzin will be sharing insights into the challenges and benefits of adopting a systems-focused approach in the AEC industry. Burzin, thank you for joining us. It’s a pleasure to have you here.

Burzin Tampal: Thank you, Joe. I’m honored to be here.

Gould: Great. Well, Burzin, let’s jump right in. Can you describe your journey and what prompted the shift towards adopting systems engineering in construction projects?

Tampal: Certainly. So I’ve had the opportunity to work in the medical, financial, and software development sectors prior to working on major projects in the AEC where I initially started off in the rail and transit division. Unfortunately, not all projects were successful by project management standards and most ended either over budget, over schedule, or had quality issues. These projects would sometimes lead to lawsuits, and I had heard that this was somewhat typical for these projects.

I was quite concerned that this was status quo for a 200 plus year old industry, so I started doing some independent research and went down a path which led me to learning more about systems engineering. I came across a popular study. You might know or heard of it. It’s the 2015 Chaos Report by The Standish Group. And although it was not specific to the rail and transit industry, I felt it was very applicable.

If my memory serves me correctly, the outcome stated that something like the top three, the top five reasons, rather, for failed projects was related to poor requirements management practices. I guess I really tried to right the ship after that. I could start to see where the current practices on these major engineering and construction projects were failing to meet the needs of the complex project.

And after gaining some modest successes, I was determined to rethink how we implement systems engineering best practices efficiently across all engineering and construction projects. I developed my own strategy for deploying a lean systems engineering solution on projects, and I’ve been using systems engineering principles on all construction projects ever since.

RELATED: Jama Connect^® Features in Five: Architecture, Engineering, and Construction (AEC) Solution

Gould: That’s great. It’s fascinating to hear how your organization’s moved towards systems engineering. I know that shift can often come with its own set of challenges, but I’d love to see this thought leadership in our industry, Burzin. Next question, can you explain how requirements management plays a role in your construction projects?

Tampal: Absolutely. So requirements management, as most people think about it, has typically been used on systems projects, which inherently have a lot of complexity. If we take a step back, however, without getting into details about a rigorous process or beneficial tools, requirements management at its core is simply meant to track and trace stakeholder needs and project requirements throughout the project lifecycle with the end goal of ensuring compliance and satisfying the stakeholder needs.

Now, I can’t think of a project, systems or not, which wouldn’t benefit from the practice with that definition. One that is meant to ensure that the handed over project meets the needs of the client as formally agreed to. So with that in mind, requirements management really forms the backbone of systems engineering and even project management to a certain degree on engineering and construction projects that I’ve been working on.

Gould: Yeah, it sounds like requirements management really sounds like a crucial aspect here, Burzin. I imagine keeping track of requirements in a way that aligns all stakeholders can make an absolute huge difference.

Tampal: Absolutely. 100%. That’s fundamental.

Gould: So tell me what benefits you’ve experienced moving to a more systems engineering focused approach.

Tampal: Well, where do I start? There are many obvious benefits of using systems engineering that you could read about in a lot of systems engineering materials. The INCOSE Handbook is a great resource. But I think I’ll expand on some of the benefits that are not typically highlighted. So the first benefit I would mention is consistency. Leveraging a standard systems engineering process enabled consistent outputs and deliverables.

While this may sound underwhelming, it was actually the foundation for many of the other benefits we were able to attain. Some other more common benefits include a reduction in error quality issues, which meant reduced corrective effort, improved communication, which resulted in reduced duplication of effort. And once the processes were standardized and we were getting consistent outcomes, we could then implement process efficiencies which resulted in reduced resources or effort required to perform the work.

Gould: Wow, that’s excellent. It’s great to hear that you’ve realized those tangible benefits. Sometimes there are those moments where new processes open up even more possibilities.

Tampal: Correct.

RELATED: Tighten Control Over Project Costs, Compliance and Completion with Jama Connect for Architecture, Engineering, Construction, and Operations (AECO)

Gould: So what are some of the unique challenges construction projects face compared to say traditional industries like automotive or aerospace when it comes to implementing systems engineering, Burzin?

Tampal: That’s a great question. There are a lot of unique challenges. So conceptually, systems engineering best practices involve the requirements development process to be performed collaboratively with all stakeholders participating in the creation, review, and approval of the project requirements set. Traditional industries specializing in manufacturing and product development such as the automotive industry benefit from the ability to own their requirements management process from inception.

Most major architecture, engineering, and construction or AEC projects, however, are managed based on project requirement input documents and schematics in PDF, especially in the public sector. While it might not seem like much of a challenge at first, the fact that the initial baseline of project requirements is provided in a PDF document requires a great deal of upfront effort to review, extract, and manage project requirements.

Additional challenges include the fact that request for proposal (RFP) and contract documents are typically created by multiple people or teams in silos from each other over a long period of time. This practice tends to lead to incomplete requirements causing scope gaps, duplicate requirements causing duplicate effort, and even conflicting requirements causing quality issues across the project requirements set.

A final legal review of those requirements and edit of those documents typically compounds the challenges by adding a layer of ambiguity to the requirements set. Furthermore, different contract models and strategies come with their own unique set of challenges, almost always impacting efficiency of requirements change management.

Gould: I think I’ve been through some of those PDF reviews before, Burzin, so that makes a lot of sense. Construction does seem to have a unique constraints compared to industries like automotive or aerospace. Can you talk a little bit about the challenges of keeping everyone in sync and aligned on a complex project?

Tampal: Absolutely. It’s commonly known that communication is key. This is even more so true when it comes to large projects where there’s a complex stakeholder relationship structure involving a mix of clients, contractors, suppliers, sub-consultants, vendors, and third parties. Ensuring that you are providing the most up-to-date information to the correct stakeholders is certainly a challenge.

Since construction projects can range in duration from weeks to years and even decades, key things to consider include the frequency, mode, and the level of detail in communications. Ensuring everyone is aligned and contributing towards the next major milestone involves meticulous planning and consistent monitoring and execution.

Gould: So Burzin, staying aligned on a complex project has to be a major priority for everyone, especially with so many moving parts in construction projects.

Tampal: Absolutely. At times there can be up to a hundred or more stakeholders that you have to manage and keep informed.

Gould: That’s a lot of alignment. Definitely a lot of alignment. So Burzin, how do you handle the integration of evolving project requirements throughout the construction process? I mean, what best practices do you follow to manage changes without disrupting progress?

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Tampal: Well, this is certainly a challenge on all projects and more so on large complex AEC projects. We all know the inverse relation graphic of cost of changes over time on a project and the opportunity to influence or make a change on a project where there is more opportunity and lower cost to implement a change early on in the project life cycle and much less opportunity and higher cost to implement a change later in the project life cycle.

Without an industry-recognized requirement software tool like Jama Connect^®, it would nearly be impossible to identify the changes, perform an impact assessment, review the changes with the change control board for approval, and then implement all the approved changes, ensuring all impacted requirements and other items are resolved as required. Because changes during construction are typically more costly, we want to ensure that the project is adhering to a well-defined configuration management and change control process.

Some of the best practices that we implement include using a functional tool to track the proposed changes, trace the changes to all impacted items, this could be evidences or other requirements, include all relevant stakeholders in the CCB or Change Control Board when reviewing and deciding to approve a change, and adequately communicating the approved change to teams for all impacted items. Although this will not eliminate disruption, this will greatly reduce the potential of negatively impacting the project’s quality, schedule, or budget.

Gould: Wow. It sounds like balancing evolving requirements with project stability is no small feat, especially in a field as dynamic as construction. I’m sure your approach to managing this balance is a key factor in keeping your projects on track despite the inevitable changes.

Tampal: Absolutely.

Gould: So Burzin, what role does technology such as software tools for requirements management play in the shift towards systems engineering, do you think?

Tampal: Well, throughout this interview, I’ve mentioned many challenges which come with the territory when participating in construction projects, particularly large and complex AEC projects. Technology such as software tools for requirements management play an integral role in the shift towards deploying a standards-based systems engineering solution in line with industry best practices.

The technology shift has contributed to both increasing the complexity on projects as well as providing software tools that can better calculate, simulate, and manage the solution. Projects have already shifted to digital delivery, and leveraging the best tool fit for purpose is detrimental to project success.

When used correctly, requirements management tools such as Jama Connect, design management software such as AutoCAD, MBSE tools for modeling, and construction management software such as Autodesk Construction Cloud or ACC can significantly reduce the effort required to produce a deliverable while improving the quality at the same time. However, with the available software tools in the market, it is becoming increasingly more important to ensure the tools can integrate with each other and establish a digital threat,d and streamline the overall process.

Over the past two years, there have been a boom in artificial intelligence and machine learning. We are now in a time where data is the most valuable currency, and therefore, understanding how to get the most out of the technology and software solution deployed on a project is detrimental to long-term success.

RELATED: Utilize Artificial Intelligence and Natural Language Processing to Produce High-Quality Requirements with Jama Connect Advisor™

Gould: I couldn’t agree more. It sounds like technology really supports teams in navigating the complexities of systems engineering. I can imagine that certain features in requirements management tools make a significant impact on how effectively you implement this approach.

Tampal: Absolutely.

Gould: Well, Burzin, I think we’re out of time. I want to thank you so much for sharing your insights and your experiences with us today. It’s been for me incredibly valuable to hear about your journey in integrating systems engineering. We appreciate your time and openness and look forward to seeing the continued success of your projects. Burzin, thank you again.

Tampal: Thank you for having me, Joe. Appreciate it.

Ingram: Thank you for joining us in this episode of our Expert Perspectives series. We hope you’ve enjoyed this conversation between Burzin Tampal and Joe Gould on systems engineering and architecture engineering in construction industries. If you’re an existing customer and want to learn more about Jama Software, please reach out to your customer success manager or consultant.

If you’re not yet a client, please visit our website at JamaSoftware.com to learn more about us and how we can help optimize your development processes. Thank you and stay tuned for our upcoming episodes of Expert Perspectives. Please note that the views expressed in the interviews and commentary are solely those of the individuals providing them and do not reflect the opinions of Jama Software.

THIS HAS BEEN A PREVIEW OF OUR VIDEO AND TRANSCRIPT –
CLICK HERE TO WATCH THIS INTERVIEW IN ITS ENTIRETY:

Expert Perspectives: The Shift Towards Systems Engineering in the Architecture, Engineering, and Construction (AEC) Industry

In this blog, we recap our recent webinar, “Systems Engineering MedTech Challenges”

Systems Engineering MedTech Challenges

Implementing systems engineering (SE) practices in MedTech presents unique challenges. From aligning with regulatory standards like ISO 13485 to managing time-to-market pressures and technical complexity, MedTech professionals must navigate a highly regulated and rapidly evolving environment.

In this webinar, industry experts Mike Johnson, Trainer & Co-Founder of SE-Training GmbH and Vincent Balgos, Director of Medical Device Solutions at Jama Software share actionable strategies to overcome these obstacles and explore how MedTech can lead the way in adopting SE methodologies.

Key Takeaways:

• Overview of Systems Engineering practices in the Medical Device industry
• Common early-career challenges and practical tips to overcome them in MedTech
• Aligning SE practices with regulatory standards like ISO 13485 and addressing gaps in conceptualization, system analysis, and risk management
• Opportunities for adopting SE methodologies, including Model-based Systems Engineering (MBSE)
• Don’t miss this opportunity to learn from industry leaders and gain strategies for addressing MedTech’s common SE challenges.

The video above is a preview of this webinar – Click HERE to watch it in its entirety!

VIDEO TRANSCRIPT

Mike Johnson: Thank you very much to all the people of Jama Software for supporting this webinar this evening. The topic is Systems Engineering MedTech Challenges. I’m Mike Johnson and I’m working for a company called SE-Training GmbH. To give you a little introduction on tonight’s topics, so firstly, I have a short introduction about SE-Training, the company I co-founded. Then I want to dive into practical perspectives, aligning systems engineering, challenges, systems engineering opportunities, tips and tricks for overcoming common obstacles, and we have some time then at the end for a wrap-up summary and questions.

Short introduction about the company SE-Training. We are a group of systems engineering experts working on the development and support of technically complex systems. So, the technical complexity is the thing that unites us all and is very much what unites the systems engineering approach. The problems caused by complexity are often very multifaceted, often have a lot of non-linearities, many dependencies, et cetera, and it’s not easy to overcome them. We are an endorsed training provider by the INCOSE UK group. So INCOSE stands for the International Council on Systems Engineering. We are accredited here in Switzerland by the EduQua training accreditation and many people come to us because they would like to achieve one of the accreditations in INCOSE.

That’s the ASEP, the CSEP, or the ESEP. ASEP is the Associated Systems Engineering Professional. CSEP is the Chartered Systems Engineering Professional. ESEP is very experienced. And of course, with both the ASEP and the CSEP, you need to take an exam and it’s not an easy exam. You have to revise quite a lot for it, and so we have a dedicated training course to prepare you for it. Also, for anyone in Switzerland, which may be quite a few people in this webinar, anyone working in Switzerland, if you’re working as a temporary worker, then you can find us on tempservice.ch.

So the challenges for this webinar that we’re trying to overcome, firstly I want to talk about the practical perspectives on the context and constraints. I want to talk about aligning systems engineering implementation initiatives with the applicable standards, ongoing challenges in the MedTech industry, opportunities, and tips and tricks for overcoming the common obstacles in highly regulated industries. Short introduction about myself, I’m British, which means sometimes I make silly jokes. That is of course what the British do. And growing up I attended the University of Exeter firstly to study physics. Following my undergraduate in physics, I went to the University of St. Andrews to gain my master’s in optics and optoelectronics there. My first job was at Thales Optronics in the UK and already from a young age, I was a systems engineer. I was always a systems engineer in my early career, firstly working as an optical systems engineer, especially working with the military.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences

Johnson: And many of you may know the company Thales. Thales is very big on systems engineering. It’s a core competence there and there I was able to already at a young age, deliver a very big category, a project for the infantry on some very complex systems. I then moved to Switzerland and in Switzerland, I moved to a space company called RUAG Space, which is now called Thales Alenia Space, Switzerland, and there as well as leading the systems engineering group. In addition, I was also a systems engineer, and probably my best application of systems engineering at that time was on the very, very quick development of a space telescope called CaSSIS. The CaSSIS is on the ExoMars Trace Gas Orbiter. Been in orbit since 2017 and we had to do end-to-end development and verification activities, et cetera, and deliver in under two years, which really, really was challenging. I must say though that it is also a very good application of systems engineering, especially from a value-oriented perspective.

There after five years at RUAG Space, I moved to Roche Diagnostics. I moved to the MedTech industry. There, I was head of systems engineering in the molecular division, especially all the systems there using PCR or the polymerase chain reaction, I was there for seven years with a group of about 30 people, business analysts, systems engineers, requirements engineers, et cetera, really specializing on a lot of the upfront product definition activities on these, again, very complex systems. Whether they’re pre-analytics or analytics or analytics systems, both are equally very complex, with many aspects that you need to consider. You can’t just go in and start writing software or start cutting metal as such. Also introduce many organizational initiatives across the whole of Roche Diagnostics, not just in our site in Switzerland. And then for the last two years, I’ve been full-time with my company SE-Training as a consultant and trainer.

So for this webinar, first topic I want to talk about is practical perspectives. The importance here of considering firstly many aspects of MedTech context and constraints. And I say this of course based a lot on my history and my history is that I’ve come from a strong systems engineering background in aerospace, defense, and then come into MedTech. So of course my views and my reflections are based very much on my experience here may not be the same for everybody. How do I see things? Well, number one, it’s a very high compliance-driven development process, so it’s very important in MedTech that you show evidence for what you’ve done or what you said you were going to do. That’s really important in the development processes. Now of course, if I’m just making a very simple product, just a few requirements, a few verification activities, well, that’s not so difficult, is it?

But of course,e if I’m making very complex systems, I have many different subcontractors supporting them as well, many aspects possibly changing, then actually having that evidence to show compliance is really important, especially since I’ve got a high level of confidence that everything is available and is consistent. Otherwise, I’m open very much to a lot of liability. So you’re going to expect that in this industry. In particular, in MedTech, the development process is very centered around usability and safety. Now of course, safety is called product risk, but it’s a term that I must say I’m not a particular fan of. I’d rather we call things safety, but these are core to the development processes. So right from the beginning of the development you circle around usability and safety is absolutely critical. And of course, we know why or any of us working in the MedTech industry know why, because we’ve seen how both usability and safety can lead to, of course, in many cases, deaths. Unfortunately, from the misuse of medical devices or from liability issues, et cetera.

I mean, it’s medical devices you could be connected to, which if they failed you could be dead within two or three minutes or seriously injured within two or three minutes. So of course these two quality attributes or -ilities or emerging or engineering specialties or emergent properties, whatever you want to call them, these two in particular are very, very critical and of course, we know that as we go through the development processes, we need to circle around them. In both these cases, we should already be thinking we want to be supported in implementing and executing these processes. Just so that I say something that’s obvious, there’s high pressure on time to market, no one’s in denial about that.

That’s probably one of the critical constraints on any project you work on in MedTech is the pressure to get to market first is absolutely as high as you can imagine from any other industry. Often, of course, projects have dropped because they’re not achieving their timelines or simply a competitor has moved in. An unexpected competitor has got their product to market before you, really, really critical time to market. And that’s where actually from my time in the space industry, I can relate to that as well with our developing telescopes. If we were late, we simply wouldn’t get onto the rocket. We simply wouldn’t have gone to Mars.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Johnson: So actually that’s quite similar and I used to say to people actually in the MedTech industry, I used to say to my colleagues often, imagine it’s a space rocket that you’re trying to get your product onto because the space rocket doesn’t work, doesn’t wait for you. I say this as well after working across all three industries. What I saw in MedTech, is often technically the most complex systems, especially when you start analyzing the complexity of the system of systems that they’re operating within. And interestingly here, it’s not just that it’s a very high level of complexity, but also what I often saw in MedTech was that the complexity was underestimated.

People weren’t realizing just how complex these systems were, whether they were taking over jobs that people could do, so automating activities, or doing some very high-level chemistry for the samples. But whatever they were doing, often the people themselves didn’t realize just how technically complex these things were, which I would say is actually quite different to the aerospace and defense industry. Often there actually I found that you didn’t so much underestimate the complexity. You were more aware of the complexity. Often actually I think you could do overkill, you could do too much, or get to try and navigate your way around the complexity. Whereas in MedTech, I often found it was quite underestimated and yet these were really, really complex systems.

So after the contextualization and constraints, look at alignment with standards. Now of course, the one big standard we should all know is the ISO 13485. Very interesting. If you do a control F, so you look at what’s in the ISO 13485 standard. Of course, you won’t find the word systems engineering. So having failed on your first control F, you start to look for other words, don’t you? You say, well, what is that is systems engineering? What do we find in there? It’s clear they want to see a high level of traceability throughout the design and development process. Now, you think typically that products can be developed, like mid-complex products may be developed in three to five years, scales, things like this, three to five years. And well, in those three to five years what can happen? A whole load of things can change, your scope can change, your design can change, your verification can change, da, da, da. A whole load of things can change.

Project team members can change, and subcontractor suppliers can change. All these things, of course, can change. And if at the end of it you say, the regulator comes to you and says, “Well, where’s the evidence that you did what you said you were going to do five years ago?” And you look back at them with a bit of surprise and you’ve got no way of showing that evidence through the traceability of the process and of course,e you’re in trouble. Which again is often why we will have infrastructure supporting us through that process.

THIS IS A PREVIEW OF OUR WEBINAR, WATCH IT IN ITS ENTIRETY:
Systems Engineering MedTech Challenges

In this blog, we recap our webinar, “Key Systems Engineering Skills: Critical Thinking and Problem Framing” – Click HERE to watch it in its entirety.

Key Systems Engineering Skills: Critical Thinking and Problem Framing

Elevate your team’s success by exploring the role of critical thinking in a system engineering competency model.

In this insightful session, Chris Unger, Retired GE Healthcare Chief Systems Engineering Officer and Principal at PracticalSE LLC, and Vincent Balgos, Director of Medical Device Solutions at Jama Software^®, discuss how critical thinking and decision-making skills are integral to systems engineering.

In this insightful session, you will learn:

• Explore the vital role of critical thinking and decision-making in systems engineering.
• Learn practical techniques for decision framing and closure.
• Gain insight on how systems engineers should manage design decisions on a project.
• See a simple model of how and when to engage with stakeholders in design decisions.

Below is an abbreviated transcript of our webinar.

Chris Unger: We’re going to talk today about a follow-up to the last webinar, where I’m going to talk about some of the most important systems engineering skills, critical thinking, and problem framing. So, how do skills in general, and soft skills, fit into improving systems engineering? So, in prior talks, I’ve suggested you keep your processes very simple but make them effective, and that’s easy to say but hard to do. That means you have to understand the system of the SE processes, how they connect, and where the diminishing value of the processes, the source process heading off, happens. As an example, a topic could be a technical risk, or it could be a trade-off between different possible solutions. So, we want to understand how those to the risk management and the decision process interact.

In order to do that, the best systems engineers have to have really good judgment. In addition, we have to influence people. Being simplistic, hardware and software engineers design things, things do what they’re told. I know it’s oversimplified, but our deliverables are instructions on how the software and hardware engineers do things. So, the best systems engineers here have an area of depth that they’re experts in, so they bring some technical credibility. They have systems of breadth, they understand all the systems processes and how they interact, and they have great interpersonal skills. Today I’m going to focus on how you achieve a balanced and optimized design, how you focus on your cost versus risk, and doing that through basically decision making.

So, first I want to talk about the Helix Model. So, the Helix Project was a project funded by the government and, the US government, and their concern was for big aerospace and NASA projects you tend to produce a major, billion-dollar development every 10 years, and then you do 10 years of support. So, people often move on. They were worried about how you create the truly brilliant leader systems engineers from a team that may be a little bit sparse. They developed this model up here in the front and simplistically, you start with things you learn in school, how to do good mechanical engineering, electrical engineering, and software engineering techniques. You then go into an organization, and so you spend the first five years learning about your company. Things like, well, if you’re going to be doing a say glucose monitor, what does blood chemistry look like? What does a sensor look like? What’s a workflow? So, you become a good organization-specific mechanical engineer.

Then you learn about lifecycle. How do you go from womb to tomb, from customer needs to disposal and disposition with all the regulations across the world in terms of chemical safety? So, after five, maybe 10 years, you understand your domain, you understand the lifecycle and you understand your technology. What differentiates after that? What they found was the skills on the bottom half of this page, the Systems Mindset, so big picture thinking, and paradoxical mindset. You’ve all heard that joke about fast, good and cheap, pick two of the three. Well, that’s the world in which systems engineers live. We make trade-offs between things that are inherently conflicting. The other thing is, we’ve got to make decisions quickly, so you’ve got to have a flexible comfort zone. You’ve got to be willing to wait till you have the critical information but make a decision without all the information you want.

RELATED: A Path to Model-Based Systems Engineering (MBSE) with Jama Connect^®

Unger: In terms of the middle column, Interpersonal Skills, just the obvious stuff as I mentioned. You’ve got to influence the other engineers to make a good decision. Then finally here in Technical Leadership, balanced decision-making, and risk-taking. So, I had a general manager one time say, “We’re in the business of managing risks, not avoiding risks.” The least-risk program is also a boring one, but you also don’t want to take moonshots and everything. So, you really want to balance. It’s another case of a paradoxical mindset. Balance risk-taking with hitting a schedule predictably. So, these are the kinds of skills that really differentiate as systems engineering leaders, 10 to 15 years into your career. I’m going to talk more about these, decision-making, stakeholder management, and barrier-breaking.

So, I put together a very simple Systems Engineering Competency Model. I started with the NASA handbook and the NASA lifecycle. I simplified it, into that they had scope and requirements management separated, and I actually agree with those being different. But in reality, on the size of programs that we typically implemented, the people who did one typically did the other. Same thing, the architecture and the design, those were typically the same people. So, you have the upfront design, you have implementation. So, managing the subsystems actually do the implementation of what the design asks them to do, and you integrate it, such that you find your defects early. Then you manage all the lifecycle, the serviceability, manufacturability, disposability, and all the “ilities.”

Then leadership, obviously, there the interpersonal skills. This was developed for GE Healthcare, so I just picked it from our existing leadership skillset and I simplified it. What you’ll notice here is I put down at the bottom, critical thinking, as a technical skill. For many executives, and for other functional engineers, critical thinking is important, but as I mentioned, since we deliver instructions and designs to other engineers, framing decisions, taking vague things from product management and marketing, and turning them into clearer problems or functions to solve, I consider that a core technical excellence of systems engineering. But that’s vague. How do I actually measure that? So, I came up with this fairly simple set of observable behaviors. So, first of all, framing problems takes an ambiguous problem identifies the critical stakeholders, and turns them into a clear problem a more junior engineer can solve.

So, first, let’s talk about framing the problem. Even an entry-level person has to be able to understand a problem that’s been framed for them. But as you get to more senior people, the 10 to 15-year level, you have to be able to frame a complex problem, see around corners, use foresight to sort out essentials from the detail, and identify risks and emergent behavior that need to be incorporated in the decision, that other engineers might not see. Even at the strategist level, you can take a complex and ambiguous problem clarify the ambiguity, and turn it into simply just a complex and interconnected problem.

So, if we’re talking about maybe the 10 to 15-year-old person, not the most senior executives, you’ll be able to take a complex problem, identify ahead of time problems other people don’t see, and capture that. Balance cost, schedule, technical risk, and team capabilities, and make a trade-off based on sound evidence and data. Balance your intuition, when you don’t have all the data with waiting and gathering data where you need it. Then finally, making the decision is maybe the easy part. You have to make sure the team follows your leadership. Take accountability for making the right decisions, delegate where you can, and then ensure that the entire team buys into the decisions that the team or you have made. So, that’s the theory.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences

Unger: Let’s talk about how we manage design decisions. First of all, why? Why is this a critical skill? By identifying the critical design decisions, it allows the team to focus on the most important thing, and separate out the core from the distractions. It helps teams identify work items. So, for example, one time when I was working with the ultrasound team in Japan, we had a bunch of really experienced engineers and they were working on a new ultrasound probe. It had moved an active component into the probe and there was a thermal issue. They were talking in Japanese for about five, 10 minutes when I was asked to frame the problem and I said, “Yeah, you’re talking too fast and too much. This is not that easy. Come back to me and tell me what you’re actually doing.”

They were figuring out how to measure the thermal properties in the lab. I said, “Well, imagine you had a probe that was safe, with maybe 39°C, but that was uncomfortable to handle. Have you worked with the application people on how much value? If you spent $50 more and took the temperature down by 1°C, would that be worth a trade-off? The team, “Oh, that’s interesting.” They were actually focused on the technical feasibility, not the real market and customer acceptance problem. So, by doing this upfront, you can make sure that you have a complete work process for the team. Then once you’ve made the decision, it minimizes rework by making sure the decisions stay closed.

Now, this decision list and prioritization should start early. It would be comfortable to wait until you know everything, but that’s too late. So, it’s a living document. Don’t wait to get started until you have enough information to make a good plan. Start with what you know, and then build out as you continue. So, one of the first things I talk about is, what is a decision? As an example, I’ve had teams come to me saying, “The operating system selection is a decision.” It’s like, “No. It’s actually not typical. It’s typically a collection of decisions.” So, I draw this little arrow here. It’s basically a decision is a point in which you select between different paths going forward and you pick one way versus another. So, deciding whether to include a stretch item in scope or not is a decision. Deciding between very specific designs and implementing a feature is a decision. Setting a critical to-quality parameter or balancing between different parameters, so cost versus reliability or cost versus performance, is a decision.

CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Key Systems Engineering Skills: Critical Thinking and Problem Framing

Traceability in Systems Engineering: A Key to Successful Construction Projects

In the world of systems engineering, “traceability” is a concept that plays a crucial role in ensuring the success of complex projects. While it’s a term more commonly associated with fields like aerospace, defense, and software development, its principles are increasingly being applied to construction projects to improve outcomes, reduce risks, and ensure seamless project delivery.

What is Traceability in Systems Engineering?

Traceability in systems engineering refers to the ability to link each requirement to its source and track its fulfillment throughout the project lifecycle. This process involves creating a chain of evidence that shows how each requirement was derived, implemented, verified, and validated.

Simply put, traceability ensures that every requirement is accounted for from the moment it is conceived until the project is completed. It enables project managers, engineers, and stakeholders to understand the origins, rationale, and status of each requirement, ensuring that nothing is missed or overlooked.

RELATED: The Complete Guide to the Systems Engineering Body of Knowledge (SEBoK)

How Does Traceability Work in Systems Engineering?

• Requirements Traceability Matrix (RTM): A core tool in traceability, the RTM maps each requirement to its corresponding design documents, test cases, and validation outcomes. This helps ensure that every requirement is directly linked to project deliverables.
• Bi-directional Traceability: This involves tracking requirements both forward (from requirements to design, implementation, and testing) and backward (from deliverables back to the original requirements). This helps in managing changes, assessing the impact of modifications, and maintaining alignment between project objectives and outcomes.
• Change Control and Impact Analysis: Traceability helps in managing changes to requirements by providing a clear understanding of how any change will affect the project. This is crucial for managing scope, cost, and schedule risks.

Applying Traceability to Construction Projects

While traceability is a fundamental practice in systems engineering, its application in the construction industry is becoming increasingly valuable. Here’s how traceability can be applied to make construction projects more successful:

• Ensuring Complete and Clear Requirements: In construction, poorly defined or misunderstood requirements are a leading cause of project delays, cost overruns, and rework. By applying traceability practices, construction teams can ensure that all requirements are clearly defined, documented, and understood by all stakeholders from the outset. This reduces the risk of ambiguity and miscommunication, ensuring that every stakeholder is aligned with the project’s objectives.
• Managing Complexity and Change: Modern construction projects are complex, involving multiple teams, disciplines, and stakeholders. Changes are inevitable, whether due to design modifications, client requests, or regulatory updates. Traceability allows construction teams to track every change back to its source, understand its impact on the project, and ensure that all affected requirements, designs, and plans are updated accordingly. This reduces the risk of errors, omissions, and costly rework.
• Improving Compliance and Reducing Risks: Construction projects are subject to numerous regulations, standards, and codes. Traceability provides a structured way to ensure that all project requirements meet the necessary compliance standards. By maintaining an audit trail of all requirements and their fulfillment, construction teams can quickly demonstrate compliance, reducing the risk of regulatory penalties, legal disputes, and reputational damage.
• Enhancing Communication and Collaboration: Traceability fosters better communication and collaboration among stakeholders by providing a single source of truth for all requirements. It ensures that everyone, from architects and engineers to contractors and clients, has access to the same information and understands how their work contributes to the overall project goals. This reduces misunderstandings, promotes accountability, and enhances teamwork.
• Facilitating Project Delivery and Quality Assurance: Traceability helps ensure that the project is delivered on time and within budget by enabling construction teams to proactively manage risks, anticipate challenges, and respond to changes efficiently. By maintaining a clear line of sight from requirements to deliverables, teams can ensure that all project goals are met, and quality standards are achieved.

RELATED: AEC Best Practices Guide to Requirements Management

Why is Traceability Critical for Construction Project Success?

• Reducing Rework and Cost Overruns: Traceability minimizes the risk of errors, omissions, and changes that lead to rework—a significant cause of cost overruns in construction. Industry studies estimate that rework can account for 5-15% of total project costs. By ensuring that every requirement is correctly implemented from the start, traceability helps reduce these costs and keeps the project on budget.
• Improving Stakeholder Confidence: Traceability provides transparency and accountability, which is critical for building trust with stakeholders, including clients, regulators, and project teams. When everyone can see a clear, documented path from requirements to outcomes, confidence in the project’s success increases.
• Ensuring Compliance and Avoiding Legal Issues: With construction projects facing stringent regulations and standards, traceability helps ensure that all requirements are met, reducing the risk of non-compliance penalties, delays, and legal issues. It provides an audit trail that can be used to demonstrate compliance to regulators, clients, and other stakeholders.
• Supporting Continuous Improvement: Traceability provides valuable data and insights that can be used to improve future projects. By analyzing the traceability data, construction firms can identify patterns, lessons learned, and areas for improvement, leading to better project planning, execution, and outcomes in the future.

Conclusion

Traceability is not just a concept reserved for systems engineering; it is a powerful tool that can transform construction projects. By applying traceability practices, construction teams can reduce costs, manage complexity, ensure compliance, and build stakeholder confidence. As construction projects become more complex and multidisciplinary, traceability will increasingly become a key driver of success, helping teams deliver high-quality projects on time and within budget.

By adopting traceability, construction firms can not only improve their current projects but also build a foundation for continuous improvement, innovation, and sustained success in the industry.

Are you ready to make traceability a cornerstone of your construction project strategy?

Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Joe Gould, McKenzie Jonsson, and Decoteau Wilkerson.

In this blog, we recap our webinar, “Application of Systems Engineering in Healthcare”. Click HERE to watch the entire webinar.

When it comes to healthcare, the first to market usually gains 80% of the market share, making development speed one of the most crucial aspects of success – or failure. That’s why many organizations are looking at systems engineering as a way of connecting needs to solutions.

In this webinar, Chris Unger of PracticalSE LLC and Vincent Balgos Director, Medical Device Solutions at Jama Software^® have partnered up for an engaging webinar on the application of systems engineering in healthcare.

We invite you to join in as we delve into transformative role systems engineering is playing in the healthcare industry.

What to Expect:

1. The Power of Simplicity:

Discover how focusing on the basics, while maintaining world-class performance levels, can yield astonishing returns. We’ll show you how simplicity can be a game-changer in the complex world of healthcare systems engineering.

2. Market-Driven vs. Contract-Driven:

Intrigued by the difference between market-driven and contract-driven industries? We’ll explore how systems engineering varies in these two landscapes. Learn why “Market Driven” industries emphasize competitive value creation and use cases more than traditional requirements, and how this shift can redefine your approach in healthcare.

3. Striking the Perfect Balance:

Explore the ideal state of systems engineering in healthcare, often a harmonious blend of Agile, Lean Startup, and more traditional systems approaches. Uncover strategies to adapt, innovate, and succeed in this dynamic field.

Don’t miss this opportunity to gain a comprehensive understanding of how systems engineering can revolutionize healthcare. Whether you’re a seasoned professional or just beginning your journey in healthcare systems, this webinar promises valuable takeaways for all.

Below is an abbreviated transcript of our webinar.

Application of Systems Engineering in Healthcare

Chris Unger: We’re going to talk today about systems engineering in the medical industry, particularly medical device development. So the medical device industry faces several challenges. There’s clearly constant time pressure in developing and launching safe and effective products. We’ve got to be faster than the competition with better products. And as you can see from the statistics, this is a challenge. Part of the challenges in delivering things on time is the shifting regulatory landscape. I’m sure everyone’s aware of MDR. There’s software for medical devices. The FDA is going to think about redoing design controls next year. When we were at GE Healthcare, there were like 8,000 regulations we had to monitor. So it’s a very challenging and shifting regulatory landscape. Not only do you have to be compliant with regulations, but you have to ensure your device is safe. And so quality issues, safety and just keeping performance are key elements of delivering on time and that’s getting more and more expensive as you can see here, billions of dollars of financial risk of getting this wrong.

So to make all that harder, there’s a constant increase in complexity. When I first started, there were typical software development teams were 20 to 40 people. It’s now hundreds of people and lots of interactions. So additional things like AI, machine learning, or new technologies, really have to manage a lot of complexity inside of your devices. The organizational structure is getting more and more complex. There’s a heavy focus on acquisition, so you’re integrating new teams, new cultures, and geographically distributed development teams. So that makes it all challenging. So we’re going to talk about how systems engineering can help address some of these particular challenges.

RELATED: Intelligent Engineering Management with Jama Connect^® Live Trace Explorer™

Unger: As I mentioned, a key differentiator is getting to market faster. So the success of a program in a market-driven environment is basically profits. The first mover tends to collect the lion’s share of the profits. We typically have many customers. You don’t have a single customer marketing and product management tells you roughly what they think the competition will be and what differentiates versus in a contract-driven environment, success is satisfying the contract. So within GE Healthcare, the avionics and oil and gas businesses typically had a single customer. We would produce a floating city block to British Petroleum or Shell, go to the North Sea or the Caribbean and you had a contract and you delivered to that contract versus an engine, an aircraft engine, or a medical device, we deliver to the marketplace. We decide the timing, we decide the features.

So the stakeholders and market-driven are internal to the business and you can negotiate budget and time. If you get a really, really cool feature, you can take an extra month or quarter to develop it, versus in a contract-driven, it’s really fixed. So the challenges of market-driven and contract-driven are different. Contract-driven requirements are a key commitment. You’ve got to negotiate a formal design control versus within a market-driven environment they’re critical. You have to deliver validated requirements, but they’re definitely an internal business tool that helps communication across all the business functions.

So what’s the value of systems engineering in a market-driven industry? We basically turn the ambiguous needs that we get from product marketing or product management and turn them into clear and feasible solutions to be implemented by the hardware and software teams. The key value we produce is that those implementations seamlessly integrate into the customer’s workflow and work systems. So they work really well from day one, they reliably meet their needs. They work really well after five years and not just meet their needs, they delight the customer. We really want to deliver something that the customer enjoys using. So we have to make it work day one, we need to make it work day 50. We need to make it work for every single customer. So you have to deal with all the known variability of hardware and process. Every installation and every service event has to produce a uniform, high-quality, high-performing product.

So with those constraints, we want to optimize the business value. So when we have multiple options, marketing will tell us the customer value of these options. The implementation teams will tell us the delivery and product cost of those functions. The role of systems engineering is to make trade-offs between those and really optimize the business impact based on the cost of implementation. So we want to make sure the work done by those implementation teams is tied to the maximum market impact. And associated with that is managing technical risks. If you go down a path and it turns out to be infeasible, while it might’ve been nice if it worked, you just wasted a lot of that work. So that cost has to be scaled by risk.

In doing all those first four bullets, our key value is making sure design decisions are identified and closed predictably, and that the team acts with one voice. So decisions are framed, the options are agreed to, the decision criteria are agreed to and the final decision is closed and stays closed as stakeholders change. So once you have a frozen design, do you want to make sure that actually integrates easily and when you have integration or quality problems, they’re found early and resolved early. When you have time to react, it’s a lot easier to adjust your design in the first half of your program. It’s really hard when you find severe quality issues with a month left before shipping.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences

Unger: And so really winning products happen when systems thinkers are effective. So clearly there’s going to be a need for some systems engineering process thinkers, but they’re system thinkers across the entire program. And so we want to make sure that everybody’s involved in systems and that the creativity of the entire program is maximized. So getting specific to GE Healthcare, what is systems engineering at GE Healthcare? Well, we have the essential customer-perceived performance. So a lot of our programs are imaging, so we have the image quality. Still, we also have things like maternal-infant care where we deliver the right humidity and temperature around the neonate. In delivering that essential performance, you’ve got to make sure it’s safe and you’ve got to make sure you have regulatory compliance. And I mentioned we really want products that are easy to use and delight the customer. So usability is a critical part of systems engineering. In doing that, we make sure we define the right implementation requirements and the right reliability strategy, and that it can be installed and serviced properly.

So with that being the overall goal, how do we organize? Well, there are a lot of things that are common across all of our product teams. We do have common program milestones. We do have a common systems’ lifecycle. It’s basically the V-cycle with iteration and agile built in. What differs is that different product teams at GE Healthcare have different levels of safety hazards, so FDA risk. We go from anesthesia where you can easily kill somebody down to ultrasound, where it’s non-ionizing equipment, that’s the light handheld probes. You can’t pinch or crush anybody to even service software that has zero patient impact. There are also almost no risks for anybody and we respond to that by adjusting the process rigor so that the higher-risk safety risk modalities have higher process rigor.

Additionally, things vary across the world or we have different locations with different cultures and different sizes of organizations. We have many systems engineers across the company, but the SE team sizes vary from less than 10. In fact, we had some sites with maybe 10 engineers and the systems engineer was half a person to teams that had over a hundred systems engineers. The scale of the programs we work on is less than 10 engineers and months-long programs to many hundred as engineers applied to a program that might last three years and were based on technology developed over the prior decade. And you want some systems engineering thinking even during that basic research decade.

RELATED: Understanding Integrated Risk Management for Medical Devices

Unger: The organization goes from product centralized, it’s like the SE GM for that hundred engineering group where they all reported to a dotted or solid line, to decentralized in where that team of 10 with one or half a systems engineer, there the manager was a general engineering manager and did not have a lot of systems engineering experience. So I joke that if there is a way of organizing systems engineering, we have one of those within our group somewhere.

But how did we think about tailoring? And so this is a page I put together that was generalized that you might be able to use. Obviously, as I mentioned, higher technical risks including safety risks. One way of measuring that is how many risks there are in your hazard analysis. For things that are a higher risk we looked for a higher level of functional excellence, more process documentation, more process compliance, and higher rigor of the technical design reviews, and maybe more independent reviewers. Team experience. This is subjective to measure, but Joel Goldstein did a very nice study, from Carnegie Mellon, that the value of systems engineering increases with program complexity, but it decreases with a more experienced team if you have a small team that is experiencing the technology and the application, they can get by with less process rigor and while systems engineering excellence delivers some value, it delivers less value.

To watch the entire webinar, visit:
Application of Systems Engineering in Healthcare

In this blog, we recap our webinar, “Concurrent Engineering in Aerospace and Live Traceability™” – Click HERE for the full version.

Concurrent Engineering in Aerospace and Live Traceability™

In this webinar, you will gain an understanding of the essential components of concurrent engineering, which include:

• The process itself
• Forming a team with members from different disciplines
• Utilizing a unified design model
• Collaborating in a shared workspace
• Implementing a software tool infrastructure
• Model-Based-Systems-Engineering (MBSE) and Live Traceability™ for Concurrent Engineering inside Jama Connect

Take this opportunity to discover how to speed the analysis of feasibility, programmatics, risk, and cost in addition to surfacing and resolving technical issues early between a space agency (customer) and contractors (suppliers).

Below is a preview of our webinar. Click HERE to watch it in its entirety.

The following is an abbreviated transcript of our webinar.

Concurrent Engineering in Aerospace and Live Traceability™

Cary Bryczek: A simple agenda for today’s webinar. I’ll begin with explaining just what concurrent engineering is, and then I’ll give you a demonstration of Jama with some ideas for how to adopt those concurrent engineering practices. And then I’ll just open up the floor for some Q&A.

I’ll start by telling you a little bit about my company, Jama Software. We’re the leader in requirements management. Our purpose is to ensure that innovators succeed with client success at the forefront of everything that we do. Through years of industry-specific experience and thousands of client engagements, we provide best practices and pre-built frameworks to help teams manage their product, system, and software requirements with live traceability through the development cycle.

Our clients believe from faster cycle times and speed to market, increased process efficiency, visibility, control and quality, and streamlined reviews, compliance and risk management, all in a single source of truth. Our Jama Connect software and services help teams manage complex development in regulated industries such as medical devices and life sciences, automotive, semiconductor, space systems, airborne & defense, as well as non-regulated industries such as industrial manufacturing, finance, insurance, and software development.

The reality at most companies is that the end-to-end systems development process is fragmented into domain-specific tools and spreadsheets that have no built-in collaboration. This leads to fragmented requirements traceability and requires significant manual effort through emails, meetings, and luck to try and prevent delays, defects, rework, and cost overruns.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Aerospace

Bryczek: Most companies have come to accept the situation as an unchangeable reality given the lack of a single platform to enable the entire process, nor a method to integrate spreadsheets and desktop tools. Concurrent engineering practices can help solve some of the lack of traceability and communication, but a collaborative requirements tool like Jama is what helps communicate the evidence and make sure what is being developed aligns with the mission, goals, and needs.

Let’s dig in. As defined by the European Space Agency, concurrent engineering is a systematic approach to integrated product development that emphasizes the response to customer expectations. It embodies team values of cooperation, trust, and sharing in such a matter that decision-making is by consensus, involving all perspectives in parallel from the beginning of the product lifecycle.

Traditionally, engineers faced with the task of designing a new complex system or architecture work in sequence, one step at a time, passing the design from one subsystem specialist to the next without interaction with the rest of the team. That’s the traditional, that’s the old style.

As seen in the figure on the left, this sequential engineering begins with customer requirements and then progresses to design implementation, verifications, and maintenance. The approach for sequential engineering results in large amounts of time devoted to product development. This drives higher cost and is less efficient as products can’t be made quickly.

And this is a big deal in the space industry because when we’re in the early phases of mission analysis, you can’t afford to have a really long, lengthy product development. Sequential really just doesn’t make sense. It’s just too expensive and you need to come up with those variants right away.

RELATED: The Essential Guide to Requirements Management and Traceability

Bryczek: So concurrent engineering, on the right, is based on teamwork and focused on a common design model that evolves iteratively in real-time. As the different subsystem experts provide their contributions, designers, and customers agree on requirements and take decisions in real-time to allow the best design for the right cost within the programmatic constraints. So concurrent engineering, it allows for all stages of product development to occur essentially at the same time.

As seen in sequential engineering versus concurrent, the figure in the middle of the screen that you see, initial planning really is the only requirement before the process can occur, including planning, design, implementation, testing, and evaluation. The concurrent design and manufacturing approach allows for shortening that product development time, gives you higher efficiency in developing, and producing the parts earlier, and it lowers those production costs.

The European Space Agency commonly produces a costed, risk-assessed, conceptual space mission or system design complete with various options including the scheduling, testing, and operations in only just a few weeks, and they’ve been doing it a really long time.

We think that concurrent engineering and design manufacturing, it emphasizes parallel types of tasks. So you have an integrated product development approach, some people might call it. It really has it so that where the functions of the design, engineering, and manufacturing are working in parallel at the same time, highly collaborative to bring that new product to market.

Who uses something like concurrent engineering? There’s a lot of people. Space agencies like the European Space Agency and NASA, automotive companies like Toyota and Harley Davidson, contract manufacturing companies, and even large energy and oil companies. There are a lot of organizations out there that are doing it and doing it very successfully.

CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Concurrent Engineering in Aerospace and Live Traceability™

In this blog, we recap our whitepaper, “Applications of Systems Engineering in Healthcare” – Download the complete paper HERE.

Applications of Systems Engineering in Healthcare

When it comes to healthcare, time to market is one of the most crucial aspects of success or failure. However, medical product development teams face several challenges that slow product development, and in the quest to speed up the process, some teams are turning to systems engineering to improve the process.

In this whitepaper, we’ll look at the challenges healthcare development teams face, the difference between market-driven and contract-driven industries, and how the power of simplicity can help healthcare systems engineering teams strike a perfect balance to adapt, innovate, and succeed.

The Challenges of Healthcare Systems Development

To understand how systems engineering can help, it’s important to first look at the challenges development teams face.

First, teams must balance time demands with the need to launch products that are both safe and effective. Today, the time to define requirements has increased by 29%, and unplanned requirements churn has increased by 81%, resulting in about 70% of medical products being delivered late.

The shifting regulatory landscape presents more challenges, including the increased cost of adherence to such regulations as Software as a Medical Device (SaMD), Software in a Medical Device (SiMD), Medical Device Regulation (MDR), and In Vitro Diagnostic Regulation (IVDR). At one of the top medical device development firms, for example, their product developers had to monitor approximately 8,000 regulations. Ensuring that products meet quality, safety, and performance standards has a significant financial impact; getting it wrong can cost billions of dollars. Across the industry, non-routine quality events cost between $2.5 and $5 billion per year.

In addition to increasing design complexity, there is also an increase in process complexity. Software development teams have gone from between 20 and 40 people to hundreds of people. Artificial intelligence (AI), machine learning (ML), and other new technologies represent complexity inside devices. Organizations are getting more complex as well, with a heavy focus on acquisition, which means constantly integrating new teams and cultures, sometimes dispersed across the globe.

Systems engineering can help product developers in healthcare manage these complexities and streamline development to keep them competitive in a rapidly changing market.

RELATED: The Complete Guide to the Systems Engineering Body of Knowledge (SEBoK)

Market-Driven vs. Contract-Driven

To understand how systems engineering can improve speed to market, it’s important to first understand the difference between a “market-driven” and a “contract-driven” industry.

In a market-driven industry, the first mover tends to get the lion’s share of the profits. Market-driven industries have many customers, and the stakeholders are internal to the business. Budget, time, and requirements are negotiated within the organization.

In a contract-driven industry, success means satisfying the contract. Budget and time are fixed by the contract with one (or very few) customers. In this scenario, requirements are a key commitment negotiated within formal design control.

The two different industry models present very different requirements challenges. In a market-driven industry, requirements are an internal business tool that helps communicate across business functions. They must be validated, but the development team decides on timing and features. If a team member develops a new, innovative feature, everyone can agree to take extra time to develop it. In a contract-driven industry, that likely wouldn’t be possible given the constraints of the contract.

Systems engineering can help the market-driven industry turn ambiguous needs into clear and feasible solutions to be implemented by hardware and software teams.

Systems Engineering: From Needs to Solutions

Product developers in a market-driven industry receive a lot of input from the various stakeholders within the organization. Their task is to turn that input into marketable products that work seamlessly on day one, day fifty, and years later. The key value produced is the seamless integration of those products into every customer’s workflow and work systems. Every installation and every service event must produce a uniform, high-quality, high-performing product.

Within those constraints, developers need to optimize the business value. When there are multiple options, marketing will inform the team of the customer value of these options. The implementation teams will pass on the delivery and product costs of those functions. The role of systems engineering is to make trade-offs between those and optimize the business impact based on the cost of implementing them. Associated with that is managing technical risks and scaling costs by risk.

The key value of systems engineering is making sure design decisions are identified and closed predictably with one voice across the team. Decisions are framed, the options are agreed to, the decision criteria are agreed to, and the final decision is closed, and stays closed even as stakeholders change. Once the team has a frozen design, integration or quality problems can be found and resolved prior to moving on to the next phase. By creating time to react, teams allow themselves space to adjust design early in the program rather than rushing to fix quality issues before shipping.

Winning products happen when systems thinkers are effective. When everyone across the program engages in systems thinking, the team will maximize the creativity of the entire program.

RELATED: How to Overcome Three of the Biggest Challenges in Medical Device Development

What is Systems Engineering in Healthcare?

As a process example, at one leading US-based medical device development company, engineering teams start with the end customer’s performance requirements, such as delivering excellent image quality in their imaging
products or the proper humidity and temperature for neonatal products. As part of delivering that essential performance, teams must ensure safety and regulatory compliance.

Their product teams also put a high emphasis on usability, ensuring that their products are easy to use and delight the customer. The teams define the right implementation requirements and reliability strategy, and they ensure that their products can be installed and serviced properly.

While there is tremendous diversity in products and programs across most medical device and life sciences companies, there are several commonalities across the product teams as well. Teams have common program milestones and a common systems’ lifecycle based on the V-model with iteration and Agile built in.

What differs in product teams are the levels of safety hazards and FDA risk. Teams develop everything from anesthesia technology, which could easily kill a patient, to ultrasound, which is non-ionizing equipment operated with light, handheld probes. To accommodate these different levels of risk, teams adjust the process rigor so that higher-risk modalities have higher process rigor.

Additionally, systems engineering teams can look very different across the world. Many organizations operate in different locations with different cultures and different organizational sizes. Systems engineering teams can vary from fewer than ten engineers to over one hundred engineers. The scale of the programs can range from just a few engineers over a few months to many hundreds of engineers applied to a program that might last three years and is based on technology developed over the prior decade. (Even in that research phase, teams should apply some systems engineering thinking.) Organizations can be product-centralized or decentralized within an organization.

TO LEARN MORE, DOWNLOAD THE COMPLETE WHITEPAPER HERE:
“Applications of Systems Engineering in Healthcare”

The ‘Square Root’-Process Model for System Engineering

In the rapidly evolving field of systems engineering, the traditional V-model has served as the cornerstone for development, defining system requirements and verification processes. However, the demands of modern engineering necessitate an extension of the V-Model to reduce time-to-market and elevate customer satisfaction. This article introduces the ‘square root’ model that extends the V-model that embeds continuous feedback and integration throughout the product lifecycle. By considering production, operation, support, and end-of-life sustainability from inception, the ‘square root’ model, visually represented in the accompanying diagram, ensures that engineering efforts align with practical constraints and market needs.

Leveraging Jama Connect^®‘s advanced features, we will explore how this model fosters collaboration, efficiency, and strategic foresight, setting a new standard for systems engineering excellence.

Throughout this article, when ‘product’ is mentioned, understand that it can also refer to a service, software, or system.

There are aspects in engineering and feedback loops that the V-model implies to improve the engineering assets (mainly Verification and Validation focused) at the same information abstraction level; This article will describe the need to extend the traditional V-model to ensure the estimated time-to-market can be met with ease, customer satisfaction improves each product iteration and create a better tomorrow, using Jama Connect unique features to support your engineering teams to achieve these results.

Where the traditional V-model, starting at ‘Stakeholder Requirements’ and ending at ‘Acceptance Tests’ (or ‘Validation’), describes the engineering’s team involvement in the product being engineered, it is important to understand that this is only a small part in the entire lifecycle of a product. It’s the repeatable part for that product’s new releases and it’s the part that can be used to analyze the impact of changes before that change gets implemented in production.

RELATED: A Path to Model-Based Systems Engineering (MBSE) with Jama Connect^®

Design Constraints

The word “constraint” has a negative connotation; Design constraints are limitations on what designers can do with a design. These limitations are usually byproducts of having deadlines, budgets, brand guidelines (and similar guidelines, see below), laws and regulations, finite resources, and limited decision power in terms of tools and processes.

Some product engineers view design constraints in a bad light because they feel like they’re being boxed in by a brick wall, while others embrace design constraints as directional guidelines that open the doors to creativity and strategic problem-solving.

On the surface, having design constraints can indeed feel like a bad thing; however, they can be extremely useful. Being limited to certain choices doesn’t necessarily mean being limited to certain outcomes. Often enough there are alternative options that are, at least, almost as good as what you originally envisioned.

Design constraints can come from various sources, in this article we’ll talk about the constraints that focus on time-to-market, customer satisfaction, and zero waste. In other words, design guidelines come from:

• Production;
• Operation and Support;
• (Ecological) Sustainability; the recycling of your product’s used materials.

These design constraints facilitate engineering with the end in mind. Your team’s early decisions during product definition must include upgradability, serviceability, and for sure: disposal, and sustainability.

Please Note: As these are complex topics by themself and not part of the core business of Jama Software, this article will only emphasize the need for feedback from these product lifecycle phases into the product definition as design constraints. Design constraints might also be known and used as Non-functional Requirements (i.e., the different ‘-bilities’, like producibility, serviceability, etc.)

Production and Manufacturing

When production and manufacturing aren’t involved from the start, your engineering team might waste valuable engineering time and effort on a product that cannot be manufactured with the means your production facilities have at their disposal. This means that the product’s entire time-to-market will need to be extended to re-engineer the product to your current production capabilities; wasting precious time and putting your competitive edge at an unnecessary risk.

As an example, a Printed Circuit Board (PCB) might require that a set of components must be aligned in the same direction and at a specified distance when wave soldered to avoid short-circuits in operation. These wave soldering characteristics can be recorded and maintained in Jama Connect as Design Constraints. Source: https://www.mclpcb.com/blog/wave-soldering-issues/

The other side of this same coin; By knowing what your production facilities can and cannot do at the start of the product definition, your teams are capable of estimating when the new bleeding-/leading-edge product they are developing needs new production means.

These insights, when considered at the beginning of the product definition, will allow your teams to research, develop, and implement the required new production techniques and have them ready when the product hits the factory shop floor. This includes having purchasing ready with new suppliers, their delivery times, required stock levels, and other input required for your factory shop floor to hit the ground running producing your new product when it completes its V-cycle.

Operation and Support

The full value of a system or product is realized in its use and operation during the expected product lifespan. Your customers want to receive a product that meets their expectations, but those expectations extend beyond a product that works on day one. Customer Satisfaction, and thus Customer Lifetime Value, is heavily influenced by the ease and availability of maintenance, servicing, and upgrades that will extend the product’s lifespan. When a customer calculates Return on Investment (ROI), they are not only considering receiving a working product, but they are also factoring in;

• Mean Time Between Failures (MTBF, a metric for failures in repairable systems);
• Mean Time to Failure (MTTF, a failures that require system replacement);
• Mean Time to Repair/Recovery/Respond/Resolve (MTTR, is the average time it takes to repair/recover/respond/resolve a failure in a product, service or system, usually technical or mechanical. It includes both the repair time and any testing time. The clock doesn’t stop on this metric until the system is fully functional again); and
• Mean Time to Acknowledge (MTTA, a metric useful for tracking your team’s responsiveness and your alert system’s effectiveness).

Reliability represent a series of metrics designed to help customers understand how often incidents occur and how quickly they, in collaboration with your Operation and Support, bounces back from those incidents. Valuable indicators to determine if their investment, and any additional investment to keep it operational, is effective.

Analysis of these reliability, MBTF, MTTF, MTTR and MTTA metrics focused on means to reduce these indicators, lead to product enhancements that improve customer satisfaction for both users (better uptime, improved performance, etc.) and decision makers (value on their investment).

E.g., the accessibility of a repairable component, to improve the MBTF, can be recorded and maintained in Jama Connect as a design constraint.

Sustainability

For sustainability, it all starts with the design. The design decisions for the product contribute 80% to the carbon footprint of the solution! How to make your products and systems ‘green’ from the start, a topic most companies struggle with.

Once your teams start to include sustainability in your product’s mission, you’ll need a structured approach, as several factors will push for different considerations. The most obvious considerations are the choice of materials and the optimizing the production process (reducing carbon emissions).

However, the repairability/serviceability of the product should be considered with a more extended lifetime vision, just like upgradeability and reusing components.

Techniques like Lifecycle Analysis (LCA, shows how much influence a product has on the environment during its entire life cycle: from raw material extraction to waste processing) exist to determine the Design Constraints necessary for the sustainability of the product being developed.

The (material) considerations that come out of an LCA (e.g. switch from fossil fuels to hydrogen) can be recorded and maintained in Jama Connect as a design constraints.

Jama Connect supports the ‘square root’-model

Collaborate with stakeholders from Production, Operation & Support and Environment, Health & Safety

Recording design constraints is not unique to a (Requirements Management, or Product Definition) application like Jama Connect; The ability to collaborate with colleagues in reviews, from the respective product lifecycle phases that normally don’t have to deal with the product definition phase (and thus don’t work in Jama Connect) is unique.

This unique feature allows your teams to engineer your products with the end result in mind, by involving the stakeholders from beyond their own engineering reach, to collaborate and achieve the optimum time-to-market, best customer satisfaction and create a better tomorrow for ourselves and future generations.

These stakeholders don’t require to be Jama Connect users to be invited and collaborate in a review within Jama Connect. Involving those stakeholders into the review process allows these stakeholders to verify their design constraints are adequately and sufficiently addressed by the requirements of your product definition.

RELATED: The Benefits of Jama Connect^®: Supercharge Your Systems Development and Engineering Process

First step in sustainability; reuse as much as possible

Not only does reusing and synchronizing requirements reduce your time-to-market and improve quality, but it is also a key strategy for getting your products sustainable. Jama Connect can help reducing the struggle to build on existing work when requirements, and their corresponding test cases, are spread across documents and systems, missing Live Traceability™. Your teams must manually identify and copy related content increasing the risk of rework and gaps. Additionally, teams tend to lack visibility across efforts, causing necessary changes to not propagate across reused content, potentially impacting quality and disconnected product design efforts.

Jama Connect simplifies and enhances the process of reusing requirements and verifications by allowing you to copy selected content with its container and its traced items. Synchronization ensures visibility and enables key use cases such as parallel product definitions, common content libraries (i.e. reusable component libraries) and product variants.

Further reading

• INCOSE (International Council on Systems Engineering): INCOSE is a professional organization dedicated to promoting and advancing the field of systems engineering. Their website (www.incose.org) offers a wealth of resources, including publications, articles, and conferences, that cover various topics in systems engineering, including the V-Model.

Other sources used

• LinkedIn article ‘The famous “V” becomes a “square root” symbol.’: https://www.linkedin.com/posts/gerschoeber_systemsengineer-systemsarchitect-sustainability-activity-7110975131434242049-U9og/
  • Keynote during INCOSE NL, oct 5, 2023: Leading for a sustainable future, https://incose.nl/en/workshop-2023/david-long/
  • Workshop during INCOSE NL, oct 5, 2023: Sustainability & systems thinking: life cycle analysis as enabler for making your products and systems ‘green’, https://incose.nl/en/workshop-2023/high-tech-institute/
• Jos Voskuil’s Weblog ‘MBSE and Sustainability’, https://virtualdutchman.com/2023/02/12/mbse-and-sustainability/
• Porsche CEO:
  • Porsche CEO “Our NEW Hydrogen Engine Is The End Of EVs!”
  • Porsche CEO Reveals “New Engine That Will DESTROY Electric Cars!”
  • https://europe.autonews.com/automakers/porsche-ceo-oliver-blume-says-evs-and-e-fuels-can-coexist
• Product Design Constraints Open the Door to Innovation, https://www.disher.com/blog/product-design-constraints/
• Design constraints: Why they’re actually useful, https://blog.logrocket.com/ux-design/design-constraints-why-theyre-useful
• MTBF, MTTR, MTTA, and MTTF, https://www.atlassian.com/incident-management/kpis/common-metrics
• Jama Connect^® Features in Five: Reuse & Sync

Pioneering Excellence in Healthcare: Q&A with Systems Engineering in Healthcare

On December 5th, 2023, Jama Software^® hosted an exclusive one-day thought leadership event, featuring industry experts Chris Unger – Retired GE Healthcare Chief Systems  Engineering Officer – PracticalSE LLC, Bijan Elahi – Founder of MedTech Safety, and Vincent Balgos – Director of Medical Device Solutions at Jama Software. Attendees of this event were invited to deep dive into best practices in Systems Engineering and Risk Management, crucial pillars of successful medical device development.

The following is the transcript of a Q&A session from this event. Please note that the answers were given verbally and may not be exactly as recorded. Some changes have been made for clarity.

“What are some insights for product development teams to consider when keeping up with the speed of innovation?”

Chris Unger: Separate out research (from development), and spend certain time on long lead items. Typically, our programs are 6 to 18 months. And so, if there is basic research that takes more time, make sure you have a certain amount of your budget – 5, 10% – with risk retiring the initial basic piece of the work, and the handoff between research and [development] programs in where we think we can retire the remaining risks in the 12 months. And then the rest of it has to really focus on what is really core. Eating the elephant one bite at a time. Focus on what’s really innovative. But one of my general managers said, ‘You want your product development to be a wall. Big, small, small, big, small.’ Product development should be a phased approach where you work on various scoped tasks. Focus on the high-risk and most innovative stuff. Low-hanging fruit can wait. Spend the time really on the breakthrough, and then maybe every six months for the next year just do small iterations, maybe some covers, maybe some better user interface and workflow, while you’re buying time for the next major innovation to come through. So, portfolio management.

Bijan Elahi: With respect to risk management, innovation in new technologies is useful for reducing risk to medical devices. You may have seen the definition of “state of the art” in the latest edition of ISO 14971 Standard, which says that the manufacturers are required to consider the consolidated findings of technology research practice to incorporate into the medical devices to reduce risks as much as possible. However, it also says that the latest technology state of the art is not necessarily the latest technology [from all industries]. And medical devices, we are a little slower than other industries like semiconductors. So, for us, state of the art must be generally considered good practice, and then innovations that are proven and accessible to be used to reduce risk.

Chris Unger: The other comment I might make is one of the reasons you slow down is scope creep. For every function, every person is like, “I just need my one. It’s just small.” It’s the straw that breaks the camel’s back. And one of our most successful businesses, the ultrasound team, said that time to market and this time blocks delivery was a team effort. Instead of having one person beating away, that all the functions sort of gang up on each other. It’s like, “Well, I didn’t put my extra in.” We’re all committed to delivering this every year, something important every year. And so rather than having the program manager fighting for scope, it’s the team that says, “Look, I’m willing to commit to this limited scope to get something this year, you help me out.” So, make sure it’s the team’s focus on speed to market.

Vincent Balgos: In this post-pandemic event, collaboration can pose a challenge in working remote, hybrid, onsite, especially for systems engineering and risk management where we need to work across the aisle amongst different types of groups.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Vincent Balgos: “So my question to maybe Bijan first, is what are some lessons learned that you’d offer to maintain efficiency and progress, that works better than others? And we are a bunch of engineers here, definitely want to talk about technical, but are there any key soft skills that we may also want to consider as well?”

Bijan Elahi: In one of my classes, I teach that you need to cultivate humility and curiosity. So, what do I mean by that? As I said, risk management is a team sport, and humility does not mean self-deprecation, it means to recognize that the answer is not all within you, it’s within your team. And the curiosity part is that some people are just shy about sharing their thoughts. So, curiosity is to seek it. It doesn’t always just come to you. So, this is a soft skill that I can offer you, to cultivate humility and curiosity.

Chris Unger: This is a good advertisement for the February webinar I am hosting with Jama Software. I was going to plan something on requirements writing techniques, which will probably be later in the year. I’d say a couple of things, make sure that you focus on communication. So, in a crisis, a lot of people just focus on getting their work done. And the first thing that you should maintain, a lesson straight off, is making sure you talk to the team, that you get consistency and use simple forms, and keep publicizing. Example like “What are my decisions? What are the important ones?” Just keep over-communicating, it’s something simple in the survival handbook, “Guys, here’s my list of decisions, here’s my list of risks.” Keep it simple, keep it single reference.

And the other thing I do is, don’t use that to communicate, use that to archive your decisions. I get really annoyed when my team says, “I wrote defects in the tool. Of course, they’re going to respond.” Talk to people, call them up, ask them questions. Do they understand? Do they understand why it’s important to do this? Do they accept that it’s their defect? I had one, my first program at my previous employer, we got to each milestone, we had like a hundred open defects. And people came to me complaining, “Well, I got rid of my defects. I fixed 50 of them and I transitioned 50 to every other defect. But it’s not fair Chris, because everybody else transitioned their defects to me last night. How am I supposed to…” But we’re a team. Don’t reassign the defect in the tool and assume they’ll accept it. Talk to them. Say, “I’m going to reassign these five defects to you. Do you agree that they’re yours?” Talk more than use the tool to communicate. I love Jama Connect. I love the risk management aspect, all the risk files. But if you are going to assign a risk mitigation to somebody, talk to them before you assign them.

Vincent Balgos: “What are some market and technology trends you see coming to the industry in 2024?”

Bijan Elahi: The big ones are Artificial Intelligence (AI) and Machine Learning (ML). A lot of medical devices are now deploying technologies that are based on AI and ML. And this has really created the challenge for risk management. In fact, we don’t know how to really completely answer this yet. This is an unanswered question. And the regulatory agencies, ISO experts, they’re all working on this. So, answering this question of how do we manage the risks of a medical device that is constantly changing? With current medical devices, if you want us to make a change to it, you’re supposed to submit something to the FDA. What about a medical device that is changing by the hour? It’s not really possible to keep making submissions. So, this is one of the challenges that’s happening in 2024.

Chris Unger: Yeah, that’s the obvious thing. I was a skeptic. People a long time ago said, “Are you doing AI machine learning?” And I kept responding with “No, it’s not ready. It’s not ready.” It’s ready. It’s coming. It’s now. It’s 2024. I wouldn’t say it’s a 2024 trend, it’s ongoing and continuing in cybersecurity. I mean, all these things are connected. That we want to network. Radiologists want to work remotely. It was a long time ago that somebody talked to us and said, “Look, this is great. I’m the head of a radiology network in northern Jersey. We’ve got five radiologists. And when people come to my clinic, I’ll do a quick read of every scan in my area, but I’m the liver guy. So, all the liver scans get sent to me. And somebody else is the head guy.

But that means a network, which means you’ve got huge network security. So, cybersecurity is just always going to get more and more critical. And we’ve never been liable. We’ve had hospitals come to us saying, somebody’s stuck a USB stick into your system and you let that virus go and it infected their network, but it went through your product. Why didn’t you protect it? And that was a huge malware. Whatever ransomware hospital costs more money than effective fiber is going to be way more effective.

RELATED: 2024 Predictions for Medical Device & Life Sciences Product, Systems, and Software Development

Audience Question: “I was curious, looking at your workflows with the dotted lines, I recently debated whether usability engineering should be its own pillar containing risk, containing system requirements or embedded within the existing infrastructure for those. Do you have any pros or cons or suggestions on whether you should look at usability engineering independently as a whole? Or as part of the risk plan system requirements plan?”

Bijan Elahi: Usability engineering is very well integrated into risk management. It is its own discipline, and it has its own standard IEC 62366:2015. But a lot of its work products are very similar to an actual integration with an ISO 14971 workflow. So, I can’t say that it should be independent, but I say integrated with risk management.

Chris Unger: Yeah, I think it’s both and, not either or. As Bijan said, there’s a use analysis report that is mandated. So, it’s its own discipline and it’s part of everything. It’s part of workflow. Remember I said, “Gee, we want, custom things that are easy to use. No training needed, just use it.” And that’s a customer value. It’s part of marketing. Think about reliability. So, if I take this and I drop it… what are the stresses? How do I test this stuff? It’s part of uses. When we did things, it was probably two-thirds of our reliability issues were unexpected use cases. So, we had this baby warmer, and it was in Philadelphia, so they had cobblestone streets, and they were just transporting it from one wing of the hospital to the other, no baby in it. And there was an infrared warmer, it went over it and the interim warmer fell over to where the baby would be. Because it was doing a shake test going over the cobblestone. And we didn’t think about that.

Another case we had a mobile X-Ray. Takes an X-ray system, moves it into the surgery, into the ICU, the recovery room. And it’s a battery… It was probably 600, 700 pounds. Great when you have this big hulking tester and they move it over this expected ramp, something like this was easy to move it over. You get 110-pound nurse in a hospital with a two-centimeter step going into the elevator and guess what? The only way they could get over the ramp was to take a running start and use the momentum. We had wheels falling off. What was that? So, we went to the hospital and watched them. Oh! We expected like 5 Gs and the upper limit (UL) is like 50 Gs or 10 x factor plus 200 Gs. Once we designed for 200 Gs, wheels stopped falling off. So, usability is part of reliability engineering. So, it’s part of everything and it’s used in analysis report.

Audience Question: This is a more general question, but for companies that have two or more variants of a product, what are your recommendations? And this is to both of you about managing both product development and product assets. So, let’s say 90% of the assets are common across three variants and how to handle risk management when the clinical usage of those three variants could be different?

Bijan Elahi: With respect to risk management. EU MDR allows you to do risk management for a family of projects. So, if this is a family that are very similar, you can do a common risk management and then do differential risk management for the differences between them to submit.

Vincent Balgos: I’ll also add that varying management configuration is a hot topic within the medical, especially as you build family of products and then you build your… Let’s say child products off that. How do you reuse and share some of that information for efficient product development? So, this is where Jama Software is really a great, unique opportunity where we’ve actually learned from other industries, particularly in automotive and in terms of how they deal with those different types of variants. So, we’re incorporating some good practices off the bat and again, happy to talk with each of you, especially if there’s specific questions on how to solve some problems.

Audience Question: My question is about integration. I mean we see more and more devices now have the ability to work together with solutions from other vendors. How can we can be prepared for that? I mean sometimes if your product is on the market, and somebody wants to use it and integrate it with a different solution. How can we be prepared for that from both a system engineer design perspective and for risk management?

Chris Unger: System engineering is kind of simple. Keep a configuration compatibility matrix to ensure that this version of your product is compatible with what version. And then really think through the use cases. The rainy day and sunny day. We had cases where our monitoring central station… So, we built some temperature monitors, fetal monitors, cardiac monitors, but we also then built a central station that have to work with our sensors but anybody’s sensors in the world. And we did pretty good with that.

We had a recall where somebody would plug in a… I forget what it was… temperature monitor? But it was a safety-critical device in the intensive care unit, and we didn’t have a fast enough response that it was plugging in. Usability. So, the nurse pulled it out, put it in again, pulled it out, and put it in again. And finally, the system had a race condition. It said you pulled it out, and when they put it in it tried to reset. So, the nurse had thought that it was plugged in it, and it wasn’t. And so, the nurse was assuming that the patient’s heart rate was monitored when it wasn’t, we had to recall the entire product. So have a standard interface. Have a compatibility matrix and test the unusual customer uses.

Bijan Elahi: With respect to risk management, if you’re making a medical device that is supposed to work with other medical devices together, then the together becomes a system. The patient is experiencing the risks that could come from the integration of all the devices that connect with your device. To manage the risk of that, what you need to know is which devices are going to plug into your device and then you test them to make sure that they’re safe together. And then you make a list of approved compatible devices that could be used with your device and your manufacturer makes another device that wants to be used with yours and you must check that too. Just keep expanding your list of approved devices.