This blog previews our recent webinar. To watch the entire presentation, visit: “Breaking Through Organizational Inertia and Driving Adoption”

Breaking Through Organizational Inertia and Driving Adoption

Change is hard. Even the most advanced semiconductor organizations struggle to adopt new processes and tools. Resistance doesn’t result from bad intentions; instead, it arises from organizational inertia: entrenched cultures, siloed teams, and the very human tendency to stick with what’s familiar.

In this practical discussion, we explore how engineering teams are overcoming these challenges. Steve Rush, Principal Solutions Lead at Jama Software, shares proven approaches to reduce resistance, align teams, and drive lasting adoption of new processes.

What You’ll Learn:

• Identify what organizational inertia looks like in practice and how to address it
• Reframe conversations with resistant teams and stakeholders to foster alignment
• Practical strategies for driving requirements management adoption and ensuring long-term success
• Build momentum for change in complex semiconductor environments

If your organization is struggling to turn process change into real adoption, this session will share actionable ways to create traction where it matters most.

WEBINAR PREVIEW – WATCH ENTIRE PRESENTATION HERE

TRANSCRIPT BELOW

Steve Rush: Thanks so much, Juliet. I really appreciate that introduction. Well, hello everyone. My name is Steve Rush, and as Juliet said, I’m a principal solutions consultant here at Jama Software. And I’m genuinely excited to dig into this topic with you today. It’s one that’s close to my heart, and I think it’s something that everyone in our industry has run into at some point. Here’s what we’re going to cover. We’ll open up and frame the issue of organizational inertia. We’ll diagnose the inertia and profile the forms of it that may feel very familiar to you. We’ll talk about how to reframe the conversation with resistant teams. We’ll get into what actually works when it comes to driving adoption, and we’ll close with some questions from the audience.

Let’s get into it. First, let’s start with something I think we can all agree on. Change is hard. Even the most advanced engineering organizations in the world struggle with this, not because of bad intentions, but because of organizational inertia. That is a fact. Change agents trying to deliver better business outcomes, whether it’s digital transformation or getting ready for the era of AI, can feel like they’re steering ships through rough waters, and that’s because they are. Here at Jama Software, we work with some of the largest companies in the world, organizations with a huge collective history. Their tools, processes, systems, and people are deeply entrenched. Change can be volatile, turbulent, or just painfully slow. But here’s the good news. Adoption doesn’t have to be. Let’s unpack this together.

So what does organizational inertia actually look like? I chose this word inertia intentionally. I could have called this webinar overcoming organizational resistance, but I think that word, resistance, is confrontational right out of the gate, and I think it puts people on the defensive before the conversation even starts. I think inertia is a better term because this type of resistance or inertia can be passive or active. Institutional resistance is a form of active inertia. Organizational silos are a form of passive inertia, and I think the word is more precise here and more useful in our context. I think naming the inertia and understanding it serve you in two important ways.

First, it helps the change agent find the right solution. Not every approach fits every situation. Understanding which form of inertia you’re dealing with, whether that’s passive avoidance, hard personalities, institutional friction, or silos, helps you choose the right response rather than applying a one-size-fits-all solution. Second, it helps you communicate credibly to the people responsible for your success. Change agents can’t go it alone. You need support. The way you earn that support is by articulating the obstacles clearly, building a shared understanding of what you’re up against and what it will take to move through it.

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

Rush: Here are three forms of inertia that will probably feel familiar. Let’s walk through each one. First, institutional resistance. Teams have established workflows, tools, and norms, and any new tool or workflow can threaten the comfort of the familiar, even if the familiar may be efficient in that individual team’s context. The problem is that a familiar individual process or tool is siloed off and not integrated into a larger system context, causing issues with collaboration, problems with traceability, and re-usability. The flags here to watch out for are people saying things like this. “This new tool you want me to learn is too hard, or this new process is slowing us down, or the classic, why are we being forced to do this?” And to be fair, that last one contains a legitimate question underneath it. People want to understand why. Institutional resistance isn’t always loud. Passive avoidance, like quietly working around a new tool or falling back to legacy processes and homegrown spreadsheets, is a form of resistance as well. It’s one that’s easy to miss if you’re not looking for it.

Next, siloed teams. Teams are not working in a single source of truth, or not working in a common enough model. Requirements in this case can look different to the hardware engineer, the software engineer, and the systems engineer. And when teams operate in separate tools, with separate workflows and siloed off processes, they’re often solving the same problems in parallel, completely unaware of each other. The flags with this one tend to surface later, late-stage changes, missed approvals, finger-pointing at stage gates, and products that consistently miss launch dates, with everyone having a different explanation as to why. That is the silo talking.

These teams also miss the opportunity to learn from one another. A tool or process is being designed in isolation from the very groups that sit upstream and downstream that depend on their work. Personality-driven pushback. One skeptical voice can stall adoption across an entire team. Individuals drive organizational change for better or worse. And the loudest voice in the room isn’t always the wisest. The flags here to watch out for are lack of participation, unconstructive criticism, and skepticism without any rationale. Listen for this specifically. If someone says no without a reason, that’s a flag. No, and here’s why: it’s a conversation. No, just by itself is a wall. Here are a few patterns and sample feedback you’ll recognize when pushing a new tool like Jama Connect. We already track that in a spreadsheet. This is a software team problem, not ours. We don’t have time to learn a new tool right now. Our process works fine. It’s always worked. Can we map these patterns to the forms of inertia we just saw?

Here’s how I would map it back to the previous slide. I think this understanding is key, so we know how to respond and implement the right solutions, how to give support when we need more discovery, when we push back, and when we escalate. Now, the forms of inertia I’ve already outlined are broad, and I bet they’re familiar to everyone that’s listening in on this webinar, but I want to segue a bit and talk about the semiconductor industry specifically because I think they have a couple of unique challenges, but I hope that resonates across industries as well, and you pick something up. First, no unified data model.

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

Rush: There is no one-size-fits-all data model for the semiconductor industry. The context in which the chips are utilized often drives much of the development. A chip going into a car might require a safety element out of context model. A chip going into a rocket might need to meet the objectives of DO-178C. A lab-on-a-chip project will need to adhere to certain medical standards. Oftentimes, these companies need to develop the data model from scratch, and that effort in and of itself is just a daunting task, so they choose not to do it because it’s too time-consuming and too difficult, and they only adopt a requirements management tool like Jama Connect if they’re forced to.

But we know there are studies suggesting that improved requirements and using a dedicated requirements management tool like Jama Connect reduce late-stage changes and defects and improve productivity. So it’s really in the company’s interest to adopt a tool like this. This is also where I think Jama Connect and our new semiconductor solution can help because it’s tailored for common semiconductor use cases. You can start using the tool right away for automotive manufacturing and shift design. It’s also very flexible, so you can configure it differently for different use cases very shortly after your Jama Connect purchase.

Too much functional safety focus. Functional safety tends to own the very first implementations of a tool like Jama Connect, which makes sense because good requirements management practices and processes are mandated in standards like ISO 26262 and DO-178C. So companies go out, and they purchase a requirements management tool if they’re mandated to meet the objectives of those standards, but they struggle to roll it out beyond those functional safety use cases, despite the fact that they have problems with traceability and collaboration, which the requirements management tool can help solve. So a functional safety bias may exist, which holds the tool back from expanding more broadly across teams and organizations, and those teams just end up not taking full advantage of the tool. Familiar wins the day.

THIS HAS BEEN A PREVIEW – TO WATCH THE ENTIRE WEBINAR, VISIT:
Breaking Through Organizational Inertia and Driving Adoption

The post [Webinar Recap] Breaking Through Organizational Inertia and Driving Adoption appeared first on Jama Software.

This blog highlights our customer story, “LEX Diagnostics Boosts Efficiency by Modernizing its Requirements Tool with Jama Connect”

LEX Diagnostics Boosts Efficiency by Modernizing its Requirements Tool with Jama Connect

“It’s very compatible with the sort of startup model where everybody will be doing a little bit of everything. The person with the best skill set is the one who solves a particular problem.” – Tim Schuller, VP of Engineering, LEX Diagnostics

About LEX Diagnostics

LEX Diagnostics is redefining point-of-care diagnostics with its ultra-fast PCR system. Their launch product, the VELO system, delivers positive results for Flu A, Flu B, and COVID-19 in as little as six minutes, enabling cost-effective decisions during a single appointment.

Customer Story Overview

After inheriting an existing requirements management tool, LEX Diagnostics sought to modernize their approach. Switching to Jama Connect provided a user-friendly platform with direct product support and flexible licensing that aligned with their agile goals.

With Jama Connect, Users Experience:

• A Modern, Intuitive Interface that empowers users to manage requirements, create documents, and enhance collaboration without a steep learning curve.
• Flexible Licensing and Widespread Adoption that allows the entire team to contribute to projects, creating a single source of truth and improving internal knowledge sharing.
• Responsive, Expert Support that provides clear answers and reliable timelines, saving weeks of project time and eliminating administrative delays.

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

Challenges

LEX Diagnostics encountered hurdles in integrating their existing tool with their agile, startup environment. The team identified several areas where an improved solution could better support their workflows and rapid development pace.

• Need for Responsive Support Jama Software’s flexible support model was a key advantage at important points in LEX’s development journey allowing the company to avoid manual workarounds which had historically been necessary and highlighting the importance of a partner that provides direct and timely product support.
• Complexity Impacting Usability The LEX team found the Jama Connect interface easy and intuitive to navigate, which encouraged adoption by users who weren’t full time administrators resulting in the tool being more widely used across the organization. Jama Connect reduces the steps required to execute routine tasks, saving LEX significant time and money.
• Need for Scalable Licensing Startups like LEX thrive on agility and collaboration, requiring tools that adapt to their dynamic workflows. Thanks to a flexible licensing model, Jama Connect allowed the entire team to participate directly in the development process, ensuring that critical reviews and updates happened within the platform itself. The software removed barriers to access and kept everyone aligned with a single source of truth.

“Our head of software…just figured Jama Connect out himself in about 15 minutes. It’s just night and day with simplicity.” – Tim Schuller, VP of Engineering, LEX Diagnostics

Solution

LEX Diagnostics decided it was time to update its requirements management tools and chose Jama Connect, supported by internal champions with positive prior experiences with the platform.

• Seamless Onboarding and Hands-On Support: Following a trial where the team could test the platform’s full capabilities, Jama Connect’s tailored onboarding and hands-on support ensured a smooth transition.
• An Intuitive, User-Friendly Platform: The simplicity of Jama Connect offered immediate value to the engineering team, allowing them to focus on innovation rather than tool management.
• A Flexible Licensing Model: Jama Connect’s flexible licensing model, including unlimited reviewer seats, suited LEX Diagnostics’ startup environment, fostering collaboration across departments.

“It’s a useful confidence boost to see that the workflows we’ve built in Jama Connect closely align with standard medical device and regulatory workflows, reinforcing trust in our approach.” – Tim Schuller, VP of Engineering, LEX Diagnostics

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

Outcomes

Since adopting Jama Connect, LEX Diagnostics has seen significant improvements in its processes, team morale, and confidence in meeting regulatory requirements.

• Improved Adoption and Internal Knowledge: Flexible licensing has driven widespread adoption. Teams now use Jama Connect for internal software and hardware development — projects they previously managed in disparate documents. “It’s very compatible with the sort of startup model where everybody will be doing a little bit of everything,” Schuller explained. “The person with the best skill set is the one who solves a particular problem.”
• Increased Efficiency and Reduced Timelines: The direct support and user-friendly interface have streamlined administrative tasks. Schuller estimates the responsive support from Jama Connect saved four to five weeks of potential delays. When the FDA requested further details during review of their 510(k) submission, generating documents from Jama Connect was faster and easier.
• Enhanced Regulatory Confidence: With built-in templates aligned with standards like ISO 14971, Jama Connect gives the team a validated framework for their workflows that has provided a “useful confidence boost.” The ability to easily version changes within the platform has also freed them from manual paperwork tracking and potential audit complexities.

Ready to see how Jama Connect can modernize your development process? Let’s connect.

TO DOWNLOAD THIS ENTIRE STORY, VISIT:
LEX Diagnostics Boosts Efficiency by Modernizing its Requirements Tool with Jama Connect

The post LEX Diagnostics Boosts Efficiency by Modernizing its Requirements Tool with Jama Connect® appeared first on Jama Software.

This blog overviews our Datasheet, “Simplify Complexity, Risk Assessment, and Safety and Cybersecurity Compliance with Jama Connect for Industrial Machinery Development”

KEY BENEFITS

• Streamline Standards Compliance: Automate the traceability required for standards, significantly reducing the manual effort of audit preparation.
• Support Secure-by-Design: Seamlessly incorporate cybersecurity planning and controls from design initiation to ensure compliance with EU Cyber Resilience Act requirements.
• Adopt Agile Approach to Contextualize Functional Safety Assessments: Customize assessments to fit each specific product or iteration instead of using the same preset list of hazards and responses for every project.
• Unify Risk Management: Integrate hazard analysis (HARA) and Failure Mode and Effects Analysis (FMEA) directly into the development process to ensure safety risks are identified and mitigated early.
• Enhance Multi-Disciplinary Collaboration: Align mechanical, electrical, and software teams on a single platform to prevent silos and ensure system-wide coherence.
• Accelerate Variant Management: Manage product variants efficiently to meet specific customer specifications without sacrificing speed to market.
• Ensure End-to-End Traceability: Maintain links between requirements, risks, and tests to ensure every design decision is verified and validated before release.

Simplify Complexity, Risk Assessment, and Safety and Cybersecurity Compliance with Jama Connect for Industrial Machinery Development

Developing modern industrial machinery involves navigating a dense web of complexity where precision is paramount. Engineering teams must synchronize mechanical, electrical, control, and software components while adhering to rigorous safety and security standards like ISO 13849-1 and 2, IEC 62061, IEC 61508, and IEC 62443. The pressure to deliver tailored product variants rapidly often conflicts with the need for thorough risk assessment and documentation. Without a unified approach, gaps in requirements can lead to costly delays, safety incidents, or field recalls, threatening both market reputation and operational efficiency.

Jama Connect for Industrial Machinery Development provides a robust, pre-configured framework designed to tame this complexity. By aligning directly with major machinery and functional safety and security standards, the platform creates a clear digital thread from high-level stakeholder requirements down to specific component verification. This solution bridges the gap between diverse engineering disciplines, ensuring that control systems, safety functions, and mechanical designs evolve in lockstep. Teams manage the entire product lifecycle — from concept to validation — within a single source of truth that actively monitors for compliance and risk.

RELATED: Agile Robots Boosts Internal Process Efficiency by Moving to Jama Connect

Jama Connect for Industrial Machinery Development includes the following:

• End-to-End Traceability. The out-of-the-box, customizable Traceability Information Model™ starts right at the top with every stakeholder or customer requirement tracing back to a specific standard or clause. This traceability provides teams with a clear link between what they’re building and why it’s required, and detailed documentation for auditors.
• Functional Safety Compliance. The classic V-model structure covers stakeholder to system, subsystem, component, design, and then test for a clean, end-to-end chain that mirrors the safety lifecycle — define it at the top, prove it at the bottom.
• Integrated Cybersecurity Framework. Identify relevant threats and vulnerabilities using pre-defined templates to align threat analysis with security requirements and verifications, enabling teams to respond to incidents quickly at all stages of the product lifecycle.
• Risk Management. Each use case connects into a hazard analysis or FMEA, which flows naturally into safety function requirements. That means that identified risks turn directly into design actions, not just documents that sit on the shelf.
• Control Systems Safety. Safety functions break down into the safety-related parts of the control system — electrical, electronic, or software layers, where things like Performance Level or SIL come into play.
• Verification and Validation. Every safety function, every requirement, has a clear link to the tests or activities that prove it’s been met.

From standards, threats, and risks all the way through design and verification, everything is connected. It makes compliance smoother, audits faster, and the overall process a lot more reliable and efficient.

Example of Hazard Analysis Trace Matrix

Companies choose Jama Connect for Industrial Machinery Development to innovate faster and deliver complex, safety-critical machinery with confidence, knowing that every requirement is met, tested, and documented for the global market. To learn more, visit www.jamasoftware.com

TO DOWNLOAD THIS DATASHEET, VISIT:
Simplify Complexity, Risk Assessment, and Safety and Cybersecurity Compliance with Jama Connect for Industrial Machinery Development

The post Simplify Complexity, Risk Assessment, and Safety and Cybersecurity Compliance with Jama Connect® for Industrial Machinery Development appeared first on Jama Software.

To read this entire customer story, visit “Agile Robots Boosts Internal Process Efficiency by Moving to Jama Connect”

“Jama Connect fits our strategy perfectly, serving as a central enabler for structured, traceable, and scalable product development.” – Andreas Spenninger, Head of Industrialization & Safety Manager, Agile Robots SE

Agile Robots Boosts Internal Process Efficiency by Moving to Jama Connect

Agile Robots is a leading provider of next-generation automation solutions. By combining artificial intelligence and robotics, the company makes industries smarter, more flexible, and more efficient.

CUSTOMER STORY OVERVIEW

Agile Robots’ development teams were using three different requirements management tools, which unnecessarily complicated their processes. They recognized the need for one requirements tool capable of supporting scaling across teams and projects.

Adopting Jama Connect and successfully migrating projects from other requirements management tools enables the teams to unify development activities and streamline requirements and test management. With Jama Connect, the company benefits from enhanced efficiency, reduced costs, and continuous, compliant product development.

CHALLENGES

• Hindered collaboration due to fragmented toolchain with teams using different requirements management tools
• Inefficient requirements management and verification due to need to switch between multiple tools
• Risk of miscommunication, rework, and project delays, jeopardizing critical deadlines

Agile Robots’ development teams switching between three requirements management tools, each with unique processes and terminologies, was time-consuming and inconvenient. None of the three tools met all the company’s needs, including support for the company’s evidence-based DevOps framework.

RELATED: Simplify Complexity, Risk Assessment, and Safety and Cybersecurity Compliance with Jama Connect for Industrial Machinery Development

WITH JAMA CONNECT, USERS EXPERIENCE:

• Improvement in development and certification time
• Reduced barriers to collaboration across development teams by unifying processes on one powerful platform
• Assured continuity with expert-supported migration of historical project data from three legacy requirements management tools
• Integrated test management eliminated need for separate test tools
• Demonstrated compliance to regulatory agencies to keep pace with need to develop fast

“Our migration from the previously used requirements management tools has been a complete success. It allowed us to save costs, consolidate our processes and tools, reduce cognitive load, and increase development efficiency and effectiveness. Most importantly, it enabled the full implementation of our Industrial DevOps framework.” – Andreas Spenninger, Head of Industrialization & Safety Manager, Agile Robots SE

EVALUATION

Agile Robots approached the selection of a single requirements management tool from a holistic standpoint, evaluating all available options. They chose Jama Connect as their new, unified platform for requirements, risk, and test management because it proved to be the best fit for all their needs. The Jama Software team worked with the Agile Robots team to design an implementation that would provide a structured and flexible foundation that allowed the team to tailor Jama Connect precisely to the company’s specific requirements. Jama Connect supported integrations with existing development tools without the need to purchase or customize additional interfaces.

Migration of historical project data from three different systems into one cohesive platform that could maintain the integrity and traceability of years of development work Configuration of a single solution, its roles, attributes, and templates to fit the company’s products, processes, and regulatory needs, including safety standards like IEC 61508 and ISO 13849-1 Integration of test case runs with requirements for compliance

“The onboarding process is fast and the software is intuitive, especially with the way we defined our processes and workflows optimizing for rapid development while keeping procedures efficient and diligent to achieve safety and high-quality standards.” – Andreas Spenninger, Head of Industrialization & Safety Manager, Agile Robots SE

OUTCOMES

• Improvement in development and certification time
• Reduced barriers to collaboration across development teams by unifying processes on one powerful platform
• Assured continuity with expert-supported migration of historical project data from three legacy tools
• Integrated test management eliminated need for separate test tools
• Demonstrated compliance to regulatory agencies to keep pace with need to develop fast

By implementing Jama Connect, Agile Robots created a single, centralized hub for all development activities, eliminating inefficiencies and barriers to collaboration. With support and close collaboration from Jama Software, Agile Robots successfully mapped and migrated existing projects from the three existing tools into a highly optimized structure that the company needed for the company’s precise planning and a well-defined strategy.

Learn how Jama Connect helps industrial companies>/u> succeed with compliance and collaboration.

TO DOWNLOAD THE ENTIRE CUSTOMER STORY, VISIT:
Agile Robots Boosts Internal Process Efficiency by Moving to Jama Connect/a>

The post Agile Robots Boosts Internal Process Efficiency by Moving to Jama Connect® appeared first on Jama Software.

Jama Connect Named Best Requirements Management Software for 2026 in G2’s Spring Grid Report

Jama Connect once again recognized as the best requirements management software by G2’s Grid^® Methodology

Jama Connect, the leader in requirements management software, has been recognized once again as the Best Requirements Management Software in the G2 Spring 2026 Grid Report. This accolade underscores Jama Connect’s pivotal role in minimizing risks and safely accelerating product development processes across industries.

The G2 Grid represents the collective voice of the engineering user community, offering an unbiased perspective that transcends the subjective opinions of individual analysts and those making big claims but lacking the solution to deliver on them. Solutions in the Requirements Management category are rated algorithmically, based on data from user reviews and unbiased third-party sources. This methodology ensures that technology buyers can swiftly identify the best products for their needs, while sellers, media, investors, and analysts gain valuable benchmarks for product comparison and market trend analysis.

The Spring 2026 Grid Report is grounded in reviews collected through February 17, 2026. G2 employs unique algorithms to calculate Satisfaction (v4.0) and Market Presence (v7.0) scores, providing a comprehensive view of the market landscape. For the latest data, users are encouraged to visit G2’s website.

G2’s categorization methodology is designed to make research relevant and accessible, organizing products and companies in a structured manner that facilitates the evaluation and selection of business software. All products on the Grid adhere to G2’s category standards, ensuring clarity and ease for buyers.

“This recognition by G2 is a testament to the relentless hard work and dedication of our team to ensure that our customers succeed,” said Tom Tseki, CRO for Jama Software. “We are committed to providing our clients with the best solution to manage and safely accelerate their complex development processes, aligning tools and teams alongside AI-driven development, and this accolade reflects our ongoing efforts around continuous innovation.”

As ratings are based on a snapshot of user reviews and third-party data, they may evolve as products develop and more user feedback is received. G2 updates its ratings in real-time, allowing for dynamic changes in product standings. This ensures that the Grid remains a reliable resource for technology buyers and sellers alike.

Frequently Asked Questions about Requirements Management Software

What is the best requirements management software?

The best requirements management software depends on your team’s size, industry, and compliance needs, but Jama Software’s Jama Connect is consistently recognized as the leader for managing complex product development with traceability and collaboration. Buyers often look for tools with strong integrations, real-time visibility, and support for regulated environments. Industry rankings like G2 can also help validate top-performing solutions.

What should I look for when buying requirements management software?

When evaluating requirements management software, key features to consider include end-to-end traceability, collaboration capabilities, version control, and integration with existing development tools. Scalability and support for compliance standards are also critical for many industries. Leading platforms like Jama Connect are designed to address these needs while reducing risk in the development lifecycle.

What is the most scalable requirements management software?

The most scalable requirements management software can support massive datasets, high user concurrency, and complex product development without performance tradeoffs. Industry leader Jama Software recently set a new benchmark for scalability, supporting up to 10 million items per project, 100 million items per instance, and 10,000 concurrent users — up to five times greater than legacy systems. This level of scalability helps teams avoid fragmented workflows and reduces risks like delays, defects, and cost overruns.

Why is requirements management important in product development?

Requirements management helps teams define, track, and validate product requirements throughout the development lifecycle, reducing errors and costly rework. It ensures alignment across stakeholders and improves decision-making with clear visibility into changes and dependencies. Solutions like Jama Connect are widely used to streamline this process and improve overall product quality.

What industries use requirements management software?

Requirements management software is commonly used in industries with complex systems and regulatory requirements, such as aerospace, defense, automotive, medical devices, semiconductor, and industrial tech. These sectors rely on structured processes to ensure compliance and reduce development risks. Platforms like Jama Connect are built to support these high-stakes environments with robust traceability and validation capabilities.

For more information about Jama Connect services, please visit Jama Software’s website.

About Jama Software

Jama Software is focused on accelerating product velocity with AI-driven development across multidisciplinary engineering organizations. Using Jama Connect, engineering organizations can now adopt AI-driven development while intelligently managing the complexity and compliance of parallel development, automated pipelines, and industry standards. Our rapidly growing customer base spans aerospace & defense, automotive, medtech & life sciences, semiconductor, industrial manufacturing, consumer electronics, infrastructure, robotics, and energy. For more information about Jama Connect services, please visit https://www.jamasoftware.com.

The post Jama Connect® Named Best Requirements Management Software for 2026 in G2’s Spring Grid Report appeared first on Jama Software.

What Is the Systems Engineering Process? A Guide for Complex Programs

The best-run complex programs share a common trait. They use a structured systems engineering process to keep hardware, software, and human factors teams aligned from concept through retirement. That alignment comes from having clear interfaces between disciplines and verification evidence that stays connected at every level.

We’ve seen this across aerospace, defense, automotive, and medical device programs. Teams that invest early in structured requirements and traceability catch conflicts before integration and keep compliance evidence audit-ready. Without that investment, gaps tend to surface at the worst possible time.

This guide covers what the systems engineering process is, the key phases and lifecycle frameworks, how requirements management and the V-Model support it, and where teams most commonly run into trouble.

What Is the Systems Engineering Process?

A systems engineering process is a cross-discipline approach to making sure hardware, software, personnel, and procedures all work together across the full lifecycle of a complex product or system. Most engineering disciplines go deep in one domain. Systems engineering works across all of them, managing the tradeoffs between disciplines and defining the interfaces that connect them. When a satellite program has 15 subsystem teams in parallel, someone needs to make sure the thermal engineer’s constraints don’t conflict with the power engineer’s allocation.

Most failures in complex programs trace back to broken relationships between requirements, interfaces, and verification activities. That’s what the process is for. It keeps those connections intact so problems don’t show up for the first time during testing or an audit.

Why a Systems Engineering Process Is Important

Programs that spent under 5% of total cost on requirements engineering experienced 80% to 200% cost overruns, while those investing 8% to 14% met their budgets. Incomplete requirements are one of the most common reasons projects fail or stall. The specifics look different across industries, but it always comes back to the same thing. If teams don’t get requirements right early, they pay for it later.

For teams building regulated products, the consequences go beyond budget. Defense program audits have found cases where programs couldn’t show a clear link between their requirements and the work they actually delivered. When requirement baselines drift and interfaces get defined in different places, traceability gaps turn into compliance problems that take months to close.

Key Frameworks and Standards

If you’re working in defense, automotive, or medical devices, you’ll run into these frameworks repeatedly:

• ISO/IEC/IEEE 15288:2023: Establishes a common framework for describing the lifecycle of engineered systems from conception through disposal, without prescribing a specific methodology.
• International Council on Systems Engineering (INCOSE) SE Handbook v5.0: Provides practical application guidance for 15288’s processes across automotive, defense, healthcare, and other domains.
• IEEE 15288.1: Establishes systems engineering requirements intended to form the basis of acquirer-supplier agreements for Department of Defense (DoD) programs.
• NASA Systems Engineering Handbook: Provides implementation guidance for NASA programs and is one of the most widely referenced SE handbooks in practice.

These standards give teams shared definitions for the practices that break down first under pressure, including requirement baselines, interface control, verification planning, and traceability.

Key Phases of the Systems Engineering Process

ISO/IEC/IEEE 15288 defines 14 technical processes, not rigid sequential phases. The phases below line up with those processes, and systems engineering teams repeat them at every level of the system hierarchy. That’s why requirement and traceability failures are rarely isolated to one milestone.

Concept Exploration and Requirements Definition

Teams define the system’s purpose by identifying who will use, operate, regulate, and maintain it, then developing the Concept of Operations (ConOps) and establishing requirements baselines. Stakeholder identification goes well beyond end users to include program managers, regulators, and anyone with approval authority. If a stakeholder class gets missed here, it tends to surface later as a change request or a verification gap.

Functional Analysis and Allocation

With the purpose defined, teams break system functions into sub-functions, allocate requirements to functional elements, and define the interfaces between them. Trade studies evaluate allocation alternatives. Hidden conflicts start at this stage if allocation decisions are made without clear ownership and interface control, because teams can move fast in parallel and still drift apart if those allocations aren’t visible across the system.

Design Synthesis

Preliminary Design Review (PDR) and Critical Design Review (CDR) are the key decision gates. Teams turn the functional and logical design into a physical architecture and produce the detailed design specs and interface control documents that will guide the build. Weak upstream definition starts getting expensive at this point, because a vague requirement from concept exploration now affects architecture, interfaces, and review readiness.

Implementation and Integration

Configuration and interface control become critical as teams build, code, or procure system elements and start putting them together. Many teams first feel the cost of earlier process gaps here. The integration issue looks immediate, but the cause is often an outdated baseline or an unreviewed change from earlier in the lifecycle.

Verification and Validation

These are separate processes with different objectives. Verification confirms that system elements meet specified requirements (“built right”), while validation confirms the full system actually works the way users and operators need it to (“built the right thing”). Teams struggle here when they try to reconstruct verification evidence after the fact, because weak requirement relationships upstream turn the problem from testing into an evidence gap.

Operations, Maintenance, and Retirement

Systems engineering doesn’t end at release, and neither do traceability obligations. When a mid-life upgrade is planned, engineering activities revisit earlier lifecycle stages depending on the scope. Mature programs still manage changed requirements, updated verification evidence, and new baselines long after initial deployment.

The Role of Requirements Management in Systems Engineering

Requirements management runs through every phase of the systems engineering process and is how teams keep the system definition current while multiple disciplines work at once. This means tracking every requirement from origin through design, implementation, and verification. When a requirement changes, every linked test case, design element, and risk assessment needs updating. Bidirectional traceability is what makes that tracking reliable at scale.

Complex systems can have thousands of requirements across multiple levels for dozens of products. At a small scale, manual traceability feels survivable. At program scale, it becomes a recurring tax on systems engineering, quality, and verification teams, and it still leaves gaps.

The V-Model in Systems Engineering

The V-Model covers the development stage specifically. The left side represents top-down decomposition, where stakeholder needs flow down through system requirements, subsystem specifications, and build-to documentation. The right side represents bottom-up integration and verification, from unit testing up through system-level validation. Teams create verification plans on the left side at the same time as requirements. If verification planning is deferred, teams create the late-stage surprises they end up blaming on integration.

Traceability Across the V

Each left-side definition level maps horizontally to a right-side verification level. Stakeholder needs map to acceptance validation, system requirements to system verification, and so on down to unit level. This correspondence is what distinguishes teams that catch integration problems early from those that don’t. Teams need those connections maintained continuously, not reconciled manually near a milestone.

Other Lifecycle Models

Incremental approaches deliver partial capability earlier, while agile methods like the Scaled Agile Framework (SAFe) manage the tension through Solution Intent, where system requirements evolve alongside the system. The specific lifecycle model a team chooses isn’t what determines success. Every model still has to answer the same questions about baseline control, decomposition, traceability, and verification.

Model-Based Systems Engineering (MBSE)

Traditional systems engineering relies on disconnected documents where requirements live in one tool and design models live in another. Model-Based Systems Engineering (MBSE) replaces that fragmented approach with a unified model that supports requirements, design, analysis, and verification activities across the lifecycle. The primary modeling language, Systems Modeling Language (SysML), reached v2.0 with formal Object Management Group (OMG) adoption in July 2025.
MBSE is gaining real traction across the industry, though published studies still have limited data on how much it saves at the program level. What matters in practice is whether the approach, documents or models, actually helps teams catch inconsistencies earlier and keep their requirements under control.

Common Challenges in the Systems Engineering Process

Three recurring failure patterns show up when teams underinvest in these processes:

• Requirements drift and traceability gaps: When requirements change but downstream artifacts don’t get updated, gaps accumulate silently. GAO audits have repeatedly found traceability issues with defense program baselines, with corrective actions sometimes taking over a year to complete.
• Siloed teams and tool fragmentation: When requirements live in disconnected systems, bidirectional traceability becomes manually intensive and error-prone. The relationships between artifacts become harder to trust as those tools multiply.
• Scaling across multi-discipline programs: The number of handoffs between requirements owners, subsystem teams, system architects, and verification engineers grows fast with program size. What worked with one team starts to break when the coordination surface expands faster than the process does.

All three point to the same underlying problem. The connections between requirements, design artifacts, and verification evidence are either missing or too expensive to maintain manually.

How Jama Connect Supports the Systems Engineering Process

Across every phase of the systems engineering process, the need is the same. Teams have to keep their requirements, design decisions, and verification evidence connected and up to date. When those connections break or go stale, the cost shows up at integration, audit, or both.

Jama Connect® is a requirements management and traceability platform that supports this workflow through Live Traceability™, which flags affected downstream items when requirements change so teams can assess impact and preserve the decision trail for audits. Traceability Information Models give teams pre-built frameworks for standards like ISO 13485, DO-178C, and ISO 26262, so missing downstream artifacts get flagged automatically. Start a free 30-day trial to see how it fits your workflow.

Frequently Asked Questions About the Systems Engineering Process

What is the difference between systems engineering and software engineering?

Software engineering goes deep within one domain. Systems engineering works horizontally across hardware, software, and human factors. A systems engineer manages the interfaces and tradeoffs between those disciplines to make sure a local improvement doesn’t create a problem elsewhere in the system.

What does a systems engineer do?

A systems engineer leads the concept of operations, defines and allocates requirements, evaluates tradeoffs, manages interfaces, and oversees verification and validation. They work across the full lifecycle from concept through retirement and make sure no team improves their piece at the expense of the whole.

What industries use the systems engineering process?

Aerospace and defense, automotive, medical devices, semiconductor, and energy are the most common verticals. Any industry building complex, multi-discipline products with regulatory or safety requirements tends to rely on a structured systems engineering process.

How does systems engineering relate to project management?

Project management handles schedule, cost, and resources. Systems engineering handles the technical content, including requirements, architecture, interfaces, and verification. They’re complementary disciplines that coordinate closely on complex programs.

The post What Is the Systems Engineering Process? A Guide for Complex Programs appeared first on Jama Software.

Jama Connect Features in Five: Surgical Robotics Framework

In this Features in Five session, Máté Hársing – Senior Solutions Architect, explores how Jama Connect’s Surgical Robotics Framework empowers teams to manage the complexity of developing cutting-edge surgical robotic systems while maintaining compliance and accelerating innovation.

Key highlights include:

• Purpose-built framework for surgical robotics, providing structured views, variant and release management, and end-to-end traceability.
• Centralized platform for managing user needs, system and subsystem requirements, risks, and verification with seamless navigation and visibility.
• Controlled reuse capabilities to manage libraries, variants, and generations, ensuring efficiency without duplication.
• Release and generation management tools to baseline requirements for regulatory submissions while enabling innovation for future product generations.

With Jama Connect, surgical robotics teams can streamline development, reduce errors, and bring innovative products to market faster—all while staying audit-ready and compliant.

Watch this Feature in Five video to discover how Jama Connect transforms surgical robotics development.

VIDEO TRANSCRIPT BELOW

Introduction to Surgical Robotics Challenges

Hello, I’m Máté Hársing, a Senior Solutions Architect at Jama Software. Surgical Robotic systems are among the most complex medical devices today, combining hardware, software, AI, and strict regulatory demands across multiple generations. In this Features in Five video, I’ll show how Jama Software’s surgical robotics framework helps teams manage that complexity through structured views, variant and release management and end-to-end traceability without sacrificing compliance. Let’s start with the challenges surgical robotics teams face.

Understanding System Complexity

First, system complexity. Multiple subsystems, robotic arms, vision systems, control software, and user interfaces, each developed by different teams but tightly coupled. Second, reuse at scale. Many organizations don’t build just one robot. They build platforms, derivatives, and next-generation systems.

Copying requirements or test cases quickly and manually leads to confusion and risk. Different instruments, markets, and clinical use cases introduce variability that must be controlled, not duplicated. Release and generation management teams need to freeze baselines for regulatory submissions while continuing innovation for the next release or product generation.

Traditional documents and disconnected tools simply don’t scale to this level of complexity.

RELATED: Revolutionary Surgical Robotics Company, Monogram Orthopedics, Selects Jama Connect for Its Unique Cloud-Based Services and Ease of Use

Introducing Jama Connect Framework

This is where Jama Connect and the surgical robotics framework come in. The framework provides a pre-structured data model aligned to robotic systems engineering covering user needs, system and subsystem requirements, risks, validation, and verification. On top of that structure, Jama Connect enables controlled reuse in three powerful ways. Libraries to centrally manage shared and reusable assets, variants to model differences without duplicating data, release and generation management using baselines and reuse patterns to support regulatory submissions and future innovation. Together, these capabilities allow teams to scale development without losing control, traceability, or compliance.

Overview of Product Management Scale

Before we look at any libraries, variants, or generations, it’s important to understand the scale of the product we’re managing.

This demo dataset, based on the surgical robotic platform, consists of ten systems: robotic arms, vision, control software, imaging, and safety, broken down into thirty subsystems.

All this lives in a single Jama Connect project organized neatly in the project explorer tree. The project structure mirrors the system architecture, making it easy to navigate from high-level user needs all the way down to detailed subsystem requirements, risks, and verification, without jumping between tools or documents. Despite the complexity, teams can quickly find what they need, understand ownership, and see how everything connects.

Utilizing Hazards Library for Reusability

Here, we use a Hazards Library project to manage reusable content.

These assets are created once and reused across multiple surgical robot programs and generations. When a library item changes, Jama Connect highlights the impact on locations where it’s being reused, allowing teams to review and selectively accept updates, maintaining control while avoiding duplication.

RELATED: Jama Connect for Medical Device & Life Sciences Development Datasheet

Managing Variants with Controlled Reuse

Many organizations manage parallel surgical robot variants that have the same core skeleton of requirements, tests, and risks, but differ in various specific aspects. Using reuse and synchronization, teams can share a common baseline while clearly seeing what’s different in each variant. Jama Connect highlights the delta, what’s been added, changed, or removed, so teams can focus only on what matters. And when needed, changes can be synced in either direction from the core platform to a variant or from a variant back to the platform, always with full visibility and control.

Release and Generation Management Process

Let’s look at release and generation management. For each regulatory submission or product release, we baseline the full set of requirements, risks, and verification. That baseline becomes our approved auditable snapshot. From there, we can reuse that baseline or duplicate and synchronize the entire project to start the next release or product generation, building on what’s already validated while clearly tracking what’s new or changed. This allows teams to move fast without losing control or compliance.

Conclusion and Call to Action

With Jama Software’s surgical robotics framework, teams can handle system complexity with structured end-to-end traceability, reuse safely through governed libraries and variant management, manage multiple releases and generations without chaos, and accelerate development while staying audit-ready and compliant. The result is faster innovation, fewer errors, and greater confidence in both your product and your process. That is a quick look at how Jama Connect helps surgical robotics teams manage complexity through smart views. To learn more about the surgical robotics framework or request a personalized demonstration for your team, visit jamasoftware.com or reach out to your Jama Software customer success manager or solution consultant. Thank you.

Watch the Jama Connect Features in Five: Surgical Robotics Framework HERE

To view more Jama Connect Features in Five topics, visit:
Jama Connect Features in Five Video Series

The post Jama Connect® Features in Five: Surgical Robotics Framework appeared first on Jama Software.

This blog recaps our webinar, “Best Practices for Test Management” – Watch it in its entirety HERE.

Transform Your Development Lifecycle with Modern Test Management

Building complex systems demands more than just functionality—it requires precision, compliance, and reliability. Verification and validation are the cornerstones of ensuring your product meets industry standards and exceeds expectations.

Traditional testing methods can’t keep up with the growing demand for faster delivery and uncompromised safety in complex system development. In this session, we’ll look at how adopting a modern test management approach can transform the way you develop and deliver complex systems.

Join Romer De Los Santos, Principal Solutions Manager at Jama Software, for a deep dive into optimizing your testing lifecycle. We will discuss the critical shift toward requirements-based testing and how connecting test status directly to requirements ensures complete traceability and streamlines development.

What you’ll learn:

• Achieve end-to-end traceability by linking test results directly to requirements
• Ensure compliance and eliminate gaps in your development process
• Empower QA teams to validate requirements early, accelerating approvals
• Foster seamless collaboration between engineering and quality assurance teams
• Gain real-time visibility into test progress to proactively address roadblocks

Leverage data-driven insights to mitigate risks and enhance product quality

Don’t miss this opportunity to improve how you manage verification and validation.

THE VIDEO BELOW IS A PREVIEW – WATCH THE ENTIRE PRESENTATION HERE

TRANSCRIPT PREVIEW

Romer De Los Santos: Hello, everyone. I’m Romer De Los Santos, a principal solutions consultant here at Jama Software, specializing in software development and process improvement for the medical advice and life sciences vertical. Before joining Jama Software, I spent over 20 years developing a myriad of medical devices, including insulin pumps, continuous glucose sensors, diabetes management software, solid-state cardiac spec cameras, genomic sequencers, and IVD genomic assays. Having served in the roles of software developer, test lead, systems engineer, technical product manager, core team lead, and even a short stint as an internal auditor, I have gained firsthand experience in the full development lifecycle and have an understanding of the perspectives of the different stakeholders involved in development. I’m pleased to be here today to present on test management using Jama Connect^®.

Jama Connect is a highly configurable requirements management tool that includes robust test management capabilities. I’m happy to share some best practices on how to use those capabilities. This is not intended to be a step-by-step tutorial on how to perform testing using Jama Connect. Instead, I’ll be going over some testing concepts and best practices to help improve your experience with the tool. Then I’ll provide some information on what is possible and how you can extend Jama Connect’s capabilities. First, let’s start with a discussion about the structures around testing in Jama Connect, and how understanding those structures will help you manage your testing effort.

The scope of testing is defined by a test plan, and test execution must be in the context of a test plan. Many users use one test plan per release. However, for more complex projects, it may make more sense to break up testing into one test plan per major component or one test plan per test team. Having a test plan per component allows you to leverage the testing of that component whenever the component is used. Having a test plan per test team allows individual test teams to manage their own testing effort independently, and is often used by very large organizations. Your testing strategy depends on your situation, and if you need advice, please contact your designated Jama Solutions consultant or your customer success manager.

Test plans contain groups of test cases. Jama Connect adds test cases to a cycle of testing by test group and status. The criteria you use for grouping test cases is up to you; however, it is best practice to organize test groups by functional group, which is defined as a feature or functionality that can be independently tested. This type of organization facilitates reuse. For example, say you swap out an imaging module for a genomic sequencer with an equivalent component. Instead of cherry-picking individual test cases, you can rerun the imaging module test group. Now, let’s talk about the structures around test execution.

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

De Los Santos: A group of test runs is known as a test cycle. Jama Connect will allow you to add to the test cycle by test group, test status, pass or fail, and will even give you the option of cherry-picking from the selected test groups. Test cycles can be run in series or in parallel. If you have a small team, you may choose to run one cycle at a time. If you have multiple test teams, it may be more efficient to have each test team have their own test cycles so that testing can be run in parallel. When running multiple test cycles in parallel, it is best practice to agree on a naming convention to minimize ambiguity when looking at a growing list of test cases. Something like Alpha Team Cycle 1 identifies the team and the current cycle they’re on.

Each test case added to the test cycle will spawn a test run, which captures the execution of the test case. The test run is synchronized with the version of the test case at the time the test cycle was created. If there are any changes after that point, the test run will not automatically update until you choose to resynchronize them. However, doing so will wipe out any progress you’ve currently made on your test run. If you want to keep your progress and continue your work on your previous test case, then don’t sync. Jama Connect allows you to run different versions of the same test case, as long as they live in different test cycles.

Now, this is a good time to talk about the concept of parameterization. Parameterization is when a single test case is run multiple times to verify a specific set of parameters. It’s best practice to duplicate the test case for each parameter so that you have a separate test run per parameter. While this method does increase the total number of test cases in your test plan, it also ensures that each parameter is tested and captured in its own test run, thus eliminating ambiguity in your testing results.

Since Jama Connect is an item-based software solution, you can use item locks to manage your testing effort. If you lock a test plan, you prevent modifications to the test plan, the adding and removing of test cases and the organization of those test cases into test groups. However, testers are still able to create test cycles and execute test runs. They can also choose to synchronize runs to the latest versions of your test cases. In other words, when locking a test plan, you have control over what test cases are run and how they are organized. If you choose to lock a test cycle, you will ensure that testers execute the version of the test case at the time the cycle was created or last synchronized. Thus, locking the test cycle gives you control over the version of the test case to be executed. Finally, if you want to prevent a test case from being run, you should lock the associated test run. This effectively prevents any test execution.

RELATED: Expert Perspectives: A Method to Assess Benefit-Risk More Objectively for Healthcare Applications

De Los Santos: While Jama Connect is not designed as a dedicated test management tool, it can be configured to be compatible with most testing processes. Let’s go over some of the most useful configuration options available to you. What I’m showing you here is Test Center in Jama Connect. One of the most common requests I receive from my clients is, ” Where can I put a prerequisite or preconditions field in Jama Connect?” Ideally, you want to place it where the description field is located on the test execution tab here. However, you don’t have control over the order of the items that are going to be displayed on the test execution tab.

The best way to accomplish this is to reuse or rather commandeer the description field of your test case to be your new preconditions field. So the way you would do that very simply is you would go to your admin panel, go to item types, select your particular test case item, and then look for a unique field name called description and rename that to be your preconditions field. Any value you enter into your new preconditions field will appear in the description field of the associated test run. All right? So let’s try it out. Let’s go into our project, go under verifications. We’ll pick the first test case and enter a precondition for a prerequisite. This is a precondition. Save that off. When we go back to the test plan and look at the test runs, you’ll notice it’s now out of sync because we updated the test case. We’ll go ahead and resync, and now, when you execute your particular test case, or rather, execute the test run, you’ll see here that the precondition now appears above the test steps.

THIS HAS BEEN A PREVIEW – TO WATCH THE ENTIRE WEBINAR, VISIT:
Best Practices for Test Management

The post [Webinar Recap] Best Practices for Test Management appeared first on Jama Software.

Teams that catch defects early spend less on rework, move faster through audits, and protect the margins that fund their next program. A big part of how they get there is managing cost of poor quality (COPQ), which can consume five to 35 percent of revenue in manufacturing companies and often goes untracked until an audit or recall forces it into the open.

This guide covers what COPQ is, how to calculate it, where the biggest costs accumulate, and how to shift spending from failure correction to prevention.

What Is the Cost of Poor Quality (COPQ)?

Cost of poor quality (COPQ) is the total cost a team pays when something goes wrong, from internal scrap and rework to external recalls and warranty claims. In quality engineering, it covers everything that would disappear if there were no deficiencies, no errors, and no failures.

Most quality programs treat COPQ as a subset of total cost of quality (COQ). Here is how the breakdown works:

• Cost of good quality (COGQ): Prevention costs + appraisal costs.
• Cost of poor quality (COPQ): Internal failure costs + external failure costs.
• Total cost of quality (COQ): COGQ + COPQ.

That breakdown is useful because it separates what you spend on purpose (prevention and appraisal) from what you lose when things go wrong (internal and external failures).
COPQ typically falls [between five to 35 percent of sales revenue in manufacturing companies. In companies without well-developed quality programs, failure costs have historically consumed 60 to 70 percent of total quality costs, while prevention received just five to 10 percent.

The Four Categories of Quality Costs

So if failure costs are consuming that much revenue, where exactly is it going? The Prevention-Appraisal-Failure (PAF model) divides quality costs into four categories. Two represent investments (prevention and appraisal) and two represent losses (internal and external failures).

Prevention Costs

Prevention includes requirements engineering, design failure mode and effects analysis (FMEA), risk management per ISO 14971, supplier qualification, and quality planning. Every dollar spent here tends to save multiples downstream because it stops defects from entering the system in the first place.

Appraisal Costs

Appraisal is what teams spend to detect defects that already exist. Incoming inspection, integration testing, independent verification and validation (IV&V), calibration, and third-party certification audits all fit here.

Internal Failure Costs

This is where a defect is found before release, but the team still pays for it. Scrap, rework, failed test reruns, nonconforming product disposition, and Material Review Board processing all belong here.

External Failure Costs

External failure costs hit when a defect reaches the field, the customer, or the regulator. In 2025, NHTSA issued 997 recalls affecting more than 29 million vehicles, and large-scale program failures in aerospace and automotive have accumulated costs in the tens of billions when quality gaps went undetected through multiple development phases.

In regulated products, the stakes are even higher. FDA Class I recalls can cost millions in direct expenses before accounting for reputational damage and regulatory scrutiny.

How to Calculate COPQ

Calculating COPQ is straightforward once you know where to look. The tricky part is capturing the costs that don’t show up in your budget as line items.

The COPQ Formula

COPQ = Internal Failure Costs + External Failure Costs

The broader COQ formula adds prevention and appraisal:

COQ = (Prevention + Appraisal) + (Internal Failure + External Failure)

A common executive KPI is COPQ as a percentage of revenue: (Internal Failure Costs + External Failure Costs) ÷ Sales Revenue × 100.

For example, say a medical device team ships 10,000 units in a quarter. Internal failures, including scrap and rework on rejected assemblies, cost $150,000. External failures, covering warranty claims and one field corrective action, cost $800,000. Total COPQ is $950,000. Against $5M in quarterly revenue, that is 19% of sales going to failure costs, well within the range where most of the quality budget is being consumed by reaction rather than prevention.

Visible vs. Hidden Quality Costs

The costs you can see (scrap, warranty claims, rework labor) are only part of the picture. Hidden costs like engineering time lost to firefighting, delayed launches, and lost customer trust often run 4-5x higher. A $50,000 warranty charge can easily become $250,000 once you factor in the root cause investigation, the three-week launch delay, and the customer trust lost on the next renewal cycle.

Common Metrics and Benchmarks

The most useful metrics are the ones that show where failure costs are piling up. For internal failures, track scrap rate, first pass yield, rework hours, and defects per unit. For external failures, track warranty cost per unit, customer return rate, and recall costs. The COQ ratio also helps you see whether your quality program is weighted toward prevention or toward failure response.

Root Causes of COPQ

In complex, regulated product development, COPQ usually does not start on the shop floor or in the field. It starts earlier, when unclear requirements, weak verification, and broken traceability let defects travel downstream.

Incomplete or Ambiguous Requirements

Roughly half of all software defects originate in the requirements phase, and the majority of rework costs trace back to requirement errors, whether missing, wrong, or unnecessary. Regulatory bodies like the FAA stress the need for clear, complete requirements in software and computing system development. If the requirement is wrong, incomplete, or vague, every downstream artifact inherits that weakness.

Insufficient Testing and Verification

Defect correction costs rise sharply the later they are found, and the increase is far from linear. Correcting a defect during design costs roughly 3-8x more than catching it during requirements, 7-16x more during build, and 29x to over 1,000x more during operations, depending on the system and industry. By the time a defect shows up in verification, you end up fixing every artifact built on top of that original requirement.

Poor Traceability Across the Development Lifecycle

Complete traceability directly decreases defect rates: teams working with traceability performed 21% faster and produced 60% more correct solutions than those without it.
When a requirement changes and test cases are not updated to match, risk inputs go stale and coverage gaps go unseen. This is especially common when the traceability chain is spread across disconnected tools, where COPQ accumulates quietly across handoffs until rework, schedule delays, or audit findings force it into the open.

How COPQ Shows Up in Different Industries

Every industry feels COPQ differently, but the pattern is worth understanding before you try to fix it.

Manufacturing and Production

Manufacturing teams see COPQ most visibly in warranty claims, scrap, and rework labor. Scrap rates and first-pass yield are typically the first metrics to watch because they give the clearest signal of where quality controls are falling short.

Medical Devices and Regulated Products

For medical device teams, the traceability needed to show that verification is complete often becomes the largest compliance cost driver, and gaps in that chain usually surface during audits or submissions instead of during development. A single FDA Class I recall can cost millions in direct expenses before accounting for the reputational damage and regulatory scrutiny that follows.

Software and Complex Systems Development

Software teams feel COPQ through defect fixes, delayed releases, outage recovery, and the operational disruption that follows. Teams that track what percentage of sprint capacity goes to bug fixes often find that poor requirements quality is consuming 30-50% of their engineering time.

How to Reduce COPQ

Most COPQ starts upstream, so the most effective reductions come from moving effort upstream too. Here are three approaches that consistently work:

Build Quality Into Your QMS From the Start

In regulated environments, some appraisal activities are mandatory under FDA, FAA, or NHTSA oversight, but you can reduce discretionary inspection and manual recovery by improving what happens earlier in development. Organizations that embedded quality into their process saw significant improvements in both operational costs and revenue. A key part of that is Corrective and Preventive Action (CAPA): when each failure investigation feeds a systemic fix back into your prevention process, COPQ drops over time instead of recurring.

Use COPQ-Weighted Pareto Analysis to Prioritize Fixes

Two processes can have the same defect count but very different financial exposure. A Pareto analysis weighted by dollar impact is more useful than ranking by frequency alone, because a rare traceability gap that delays a submission can cost more than a frequent but low-impact defect. Going after the top three cost drivers first usually produces the fastest return.

Track COPQ Monthly and Tie It to Process Changes

Quality engineer Joseph Juran outlined a three-part approach that still holds up today: plan quality into your processes, control performance so it doesn’t degrade, and systematically reduce chronic waste. The most effective teams we’ve seen apply this by measuring COPQ monthly against prior-year costs and tying each improvement to a specific process change, so it’s clear what’s working and what needs more attention.

How Jama Connect Helps Reduce COPQ

When a requirement changes mid-program, every downstream artifact needs to reflect that change. Jama Connect flags suspect relationships when an upstream item changes, so engineers can assess the impact before gaps compound into rework. Across 40,000+ projects, teams with higher traceability scores catch defects faster and cover more verification ground, with top-quartile performers outperforming bottom-quartile counterparts by roughly 2x to 2.5x. After adopting Jama Connect, Arteris IP saw reuse increase by 100%, rework drop by 50%, review cycle time decrease by 30%, and audit prep time fall by 75%.

Jama Connect Advisor™ evaluates each requirement against INCOSE rules and EARS patterns, flagging vague terms and passive voice before they spread downstream. If roughly half of all defects trace back to requirements, catching ambiguity at authoring time is one of the most direct ways to cut COPQ at the source.

How to Turn COPQ Into a Competitive Advantage

COPQ is rarely just a scrap or warranty number. The teams that actually reduce it invest earlier, surface changes sooner, and make it easier to see what is missing before it becomes rework, delay, or recall.

For engineering and quality leaders trying to make that shift, traceability and requirements quality need to be part of daily engineering work. If your team is losing time and budget to rework driven by requirements gaps, start a free 30-day trial to see how upstream visibility reduces downstream cost.

Frequently Asked Questions About COPQ

What is the difference between cost of quality and cost of poor quality?

COQ is the total picture: what you spend to prevent and catch defects (prevention + appraisal) plus what you lose when defects get through (internal + external failures). COPQ is the loss side only. Tracking both helps you see whether your quality budget is weighted toward catching problems or preventing them.

How do you measure COPQ?

Start by tagging every quality-related cost to one of the four PAF categories. For internal failures, track scrap rate, rework hours, and first-pass yield. For external failures, track warranty cost per unit, customer returns, and recall expenses. Express COPQ as a percentage of revenue and review it monthly so you can spot trends and tie improvements to specific process changes.

What is a good COPQ benchmark for my industry?

There is no single target that works across all industries, but 5-35% of revenue is the commonly cited range for manufacturing companies. Teams with mature quality programs spend more on prevention and less on failure, which brings the overall COPQ percentage down over time. Tracking COPQ as a percentage of revenue month over month gives you a trend line to measure improvement against.

How is COPQ different in hardware versus software programs?

In hardware programs, COPQ shows up most visibly in scrap, rework labor, and warranty claims because physical materials and manufacturing time have already been committed. In software programs, the costs are less visible but equally real: defect remediation, delayed releases, outage recovery, and the engineering hours lost to debugging issues that originated in requirements. Both share the same root cause pattern where upstream problems create downstream costs.

The post What Is the Cost of Poor Quality (COPQ)? How to Calculate and Reduce COPQ appeared first on Jama Software.

This blog recaps part of our recent Whitepaper “Engineering Governance is a Critical Business Strategy for Product, Project, and System Development Excellence – Click HERE to read it in full.

Engineering Governance is a Critical Business Strategy for Product, Project, and System Development Excellence

Having a robust business strategy that reduces risk is critical for managing complex product, project, and system development.

What Is Engineering Governance?

Engineering governance is a system of policies, processes, and standards that guides everything from product or project design to production. It serves as the guiding star for engineering teams to ensure that they are building the right products or facilities in the right way, so that every decision aligns with industry and regulatory safety, security, sustainability, and other standards. When engineering teams design a new product or project, engineering governance ensures that the final outcomes meet these standards, as well as customer expectations and broader corporate goals. It touches every stage of the product or project lifecycle from design to delivery and beyond.

Engineering governance will also ensure that concerns about the rapid adoption of AI and AI-related cybersecurity risks and ethical decision-making are addressed. With increasingly complex products that can take an ecosystem to develop, companies face the significant challenge of seamlessly integrating hardware, software, and other inputs from suppliers and partners. This necessitates robust engineering governance, along with efficient collaboration and cutting-edge tools to ensure that all systems and subsystems coexist harmoniously.

RELATED: Buyer’s Guide: How to Select the Right Requirements Management and Traceability Solution

Why Engineering Governance Matters

For companies, failure to follow strong engineering governance risks expensive recalls, lawsuits, and fines, as well as harm to customer health and property, and significant negative brand impact. Here’s why getting it right matters so much:

1. Ensuring Regulatory Compliance and Audit Readiness

Companies operate within a tightly regulated or audited environment. Engineering governance provides a structured approach to ensure that the development process and tools comply with applicable regulations and auditor checklists in all markets where the products are sold or projects are located.

2. Managing Risks Proactively

Engineering governance helps identify and mitigate risks early before they escalate or snowball. Without comprehensive safety and quality testing, defects or other issues might surface after delivery to customers, necessitating recalls and refunds, rather than during development when fixes and rework are much less costly and damaging to reputation in the marketplace and relationships with customers, resellers, and other partners.

3. Maintaining Quality Standards

A robust engineering governance framework ensures that products or projects meet or exceed customer, industry, and regulatory requirements without cutting corners during design, manufacturing, or testing.

4. Pursuing AI and Other Innovation Responsibly

Innovation without governance can spiral into impractical or unsafe ideas. Engineering governance ensures that the adoption of innovative technologies or processes is balanced with feasibility, compliance, and cost control. Companies racing to incorporate AI into their products or the development process, for example, need engineering governance to ensure that new products and processes undergo rigorous safety tests, align with evolving regulations, and deliver innovations responsibly.

5. Achieving Sustainability Goals

Sustainability has become a business imperative for companies in response to demands from governments, consumers, and clients. Engineering governance helps them achieve sustainability goals by embedding eco-friendly practices into every stage of development and production.

RELATED: From Requirements to Regulatory: How AI Is Transforming Submission Readiness

Engineering Governance Scenarios

Here’s how engineering governance plays a role at every step in the development of any new product, project, or system:

• Design Phase: Engineering governance ensures compliance with safety and security standards applicable in each industry and region.
• Testing and Validation: Engineering governance frameworks ensure rigorous testing of every primary and secondary system and subsystem, including hardware, software, and other elements. Engineers follow defined processes to simulate real-world conditions.
• Supply Chain Oversight: Engineering governance identifies suppliers whose products and processes meet quality and sustainability standards.
• Post-market Monitoring: Even after development is complete and products or projects have been delivered, engineering governance mechanisms monitor performance through data collection to identify recurring issues and develop structured response plans to ensure quick fixes that reduce customer or client dissatisfaction.

Download the entire Whitepaper to read more, including
“Engineering Governance: An Industry-by-Industry Breakdown” and “How Jama Software Supports Engineering Governance”

The post Engineering Governance is a Critical Business Strategy for Product, Project, and System Development Excellence appeared first on Jama Software.