Tag Archive for: Collaboration & Alignment

aerospace & defense

As we enter 2023, Jama Software® asked selected thought leaders – both internal Jama Software employees and our external partners – across various industries for the trends and events they foresee unfolding over the next year and beyond.

In the second part of our five-part series, we asked Craig E. Miller, PhD – Principal Engineer at Ansys, to weigh in on product and systems development trends he’s anticipating in 2023.

Visit part 1 of this series, 2023 Predictions for Product & Systems Development Teams here. We will link the remaining 2023 Industry Predictions as they are published.

Read more about the author at the end of this blog. Note: The opinions expressed are those of Craig E. Miller, PhD.

2023 Predictions for Aerospace & Defense Product Development

Design Trends – What are the biggest trends you’re seeing in your industry right now? How will they impact A&D product, systems, and software development?

Craig E. Miller: The most common design trend — one that will continue in the short and long term — is identifying how a digital transformation can enable a connected digital thread. A connected digital thread enables an organization to realize efficiencies encompassing all design teams, how these teams exchange data, and how enterprises will exchange data. A&D companies that can weave the design digital thread with business will become industry leaders. The digital thread can significantly improve efficiency relating to supply chain, energy, and safety. For example, virtually certifying subsystems — to quickly add suppliers to approved vendor lists — can add flexibility to supply chains. Coordinating digital hardware design, embedded software, and data (from T&E and/or the field) can enable trade studies to optimize energy efficiency of complex systems and can identify failure modes and expedite design modifications on existing (and future) platforms for continuous improvement.

Biggest Challenges – What are some of the biggest challenges you think A&D engineering firms will be working to overcome in 2023?

Miller: Probably the biggest problem that A&D firms need to solve is balancing resource allocation. How do you fulfill your future digital strategy without compromising short-term production work? Another significant challenge is managing supply chains, as global conflicts and inflation threaten to disrupt them. I would also add workforce enablement and cross-pollinating primary engineering efforts across aeronautics, space, and cyber as important challenges with respect to maintaining a competitive edge.

RELATED: How to Realign Engineering Teams for Remote Work with Minimal Disruption

Regulations – What changing regulatory guidelines do you anticipate having an impact on companies in 2023?

Miller: Enabling virtual certification and coordinating virtual hardware design with software and data both require standards and regulations on virtual engineering. Such standards and regulations need to be coordinated among government, academia, and industry, and consortiums should start as soon as possible.

Tool Innovation – From an A&D engineering toolset perspective, what are some of the processes you think forward-thinking firms will be working to leverage or incorporate into their process, and why?

Miller: Aerospace and defense firms recognize that making the right choices, early, is the only way to succeed against the dual problems of increasing complexity and decreasing timelines. And one of the best ways to improve decision making is through engineering simulation standards, some of which are being developed right now. These standards should capture contextual metadata, facilitate collaboration, and make it easier to share knowledge within an organization — all of which contributes to faster, better-informed decisions.

It will be vital for the industry to support and adopt effective standards in the years ahead. And the challenge goes beyond development and adoption, because you have to manage the transition, too. In other words, if you adopt a standard without defining a clear path from “here” to “there,” you risk your teams developing ad hoc approaches, and that leaves you once again without a standard.

In your opinion, what are the biggest differences between an A&D company that survives to see 2030, and one that doesn’t?

Miller: The biggest discriminator has to be the ability to adapt to increasing complexity on shorter time-scales. These two pressures are everywhere, and they compound each other.

What advice would you give to new companies entering the A&D industry?

Miller: Take advantage of hard-earned wisdom and start with the right approach. Common traits of successful digital transformation initiatives are an open ecosystem, mission-centric alignment across teams, and a connected digital thread to facilitate and maintain that alignment. This is the what established firms are trying to achieve, but to get there they must contend with their legacy data and processes, as well as promoting a cultural transformation to enable this journey.

RELATED: Integrating Requirements Management with Planning and Checklist Processes for Aerospace Development

Predictions –

What do you predict for regulation in the A&D industry in 2023?

Miller: Certification for process and people. Regulation of training standards for people supporting a digital transformation. What coursework, certifications, etc. are required when matriculating from traditional design and manufacturing into modern environments? And this isn’t a question just for design and manufacturing engineers — it applies equally to management, to track that change process.

Will those trends still be prevalent 5 years from now? 10 years?

Miller: The trend of digital transformation will evolve for the next 5-10 years. There are many aspects of an A&D business that digital transformation will affect, and each will have its own prioritization that dictates the short- and long-term tasks to enable their digital strategy.

About the Author:

Craig E. Miller, PhD – Principal Engineer at Ansys

Craig Miller is a Principal Application Engineer with ANSYS Inc, where he leads several multiphysics simulation efforts for the Aerospace & Defense industry. Prior to ANSYS, he designed and analyzed a range of products, from nuclear reactors to fiber optic devices. Craig was a Graduate Research Fellow while earning his Ph.D. at the University of Maryland and earned his BS in Engineering Science at Penn State.

As we enter 2023, Jama Software® asked selected thought leaders – both internal Jama Software employees and our external partners – across various industries for the trends and events they foresee unfolding over the next year and beyond.

In the first part of our five-part series, we ask Josh Turpen, Chief Product Officer at Jama Software, to weigh in on product and systems development trends he’s anticipating in 2023.

We will link the remaining 2023 Industry Predictions as they are published. Read more about the author at end of this blog.

2023 Predictions for Product & Systems Development Teams

What product, systems, and software development trends are you expecting to take shape in 2023?

Josh Turpen: Natural Language Processing (NLP) is coming to the engineering space in a big way. Far from the “robot overlords” that have been feared, this technology is revolutionizing quality by spotting poor writing and anti-patterns as engineers are working, instead of late in the process during Root Cause Analysis (RCA) for test failures.

RELATED: Jama Connect Advisor™

In terms of product and systems development, what do you think will remain the same over the next decade? What will change?

Josh Turpen: Development will continue to struggle with the changing regulatory and security landscape. This has been a perennial problem in software and hardware is feeling it more and more with an increasingly connected ecosystem. I’m excited for tools that offer easy traceability to regulatory requirements. It makes it so much easier to validate everything from tests to requirements to regulations, ensuring that you’ve met the mark. This level of discipline should become the norm.

How do you foresee regulations shifting in product and systems development over the next decade? Or maybe just engineering, or systems engineering, in general.

Josh Turpen: Security and safety regulations for advanced technology will start coming with severe financial, and potentially criminal penalties. We’re starting to see the beginning of this, and it is high time the industry paid close attention. We’re moving beyond a point where security vulnerabilities are annoying and into a time where they will become casualty events.

Any major disruptions in product and systems development you’re anticipating in 2023?

Josh Turpen: I don’t think NLP quality linters will be a “major disruption” but more of a leading trend in quality focus in the systems engineering space.

What sorts of process adjustments do you think development teams will need to make to be successful in 2023?

Josh Turpen: The delta between those companies that have embraced a distributed workforce and those that haven’t will continue to grow. Those that still insist on collocated teams and “big meetings” for process control are going the way of the Dodo.

What do you think will be some of the differentiators between a company surviving to see 2030, and those that do not?

Josh Turpen: Embracing distributed teams and the technology that helps them be productive.

Organizations that define, measure, and improve processes are always going to outperform those that do not.

Josh Turpen: Companies that codify change into their process will dominate. They can absorb change, measure the impact, adjust accordingly and iterate. If your product development process can’t do this, it is what needs to change.

RELATED: How to Streamline Reviews and Collaborate with Remote Teams, Customers, and Suppliers with Jama Connect®

What advice would you give to new companies developing products or systems from scratch?

Josh Turpen: Define your outcomes! These can change as new information becomes available, but don’t underestimate the power of clearly stating your objective.

What topic(s) do you wish companies were paying more attention to?

Josh Turpen: Process measurement and improvement. It shocks me the number of companies that have a product failure and their “RCA” is a big meeting without data. As an industry we are awash in data and those companies that are using this data to improve will dominate.

Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2023 approaches?

Josh Turpen: We are the recognized industry leader and have the largest repository of systems engineering data on the planet. New capabilities built on that data, like the Jama Connect Advisor™
and our Industry Benchmarks are just the beginning of the journey. New capabilities to spot process issues and anti-patterns are on the horizon.

About the Author:
Josh Turpen, Chief Product Officer, Jama Software

With a deep background in software development and consulting, Josh oversees the ongoing innovation and refinement of Jama Software’s core product offerings. Beginning as an engineer, Josh’s career has taken him from Indiana to Germany, Colorado, and Portland. His work with the U.S. Department of Defense solidified his knowledge of safety-critical systems, and the vital role requirements and risk management plays within them. Having led product and engineering organizations, with teams distributed across the globe, Josh understands the daily challenges our customers face in a constantly changing marketplace and the tools they need to be successful.


Supply chain collaboration: Interactive or ReqIF. Which is right for you?

There are two main types of requirement collaboration in the supply chain: Interactive and ReqIF. While interactive collaboration is on the rise and offers the most benefits, there are cases where it is not feasible. Jama Software supports both methods and, in this post, we will discuss each method’s use-case and pros/cons.

Interactive Collaboration: The High-fidelity Option

We all know that collaboration in product development helps improve quality, reduces risk and speeds up development. For this reason, Jama Connect® has context-based, interactive collaboration built into the platform. Reviews are a formal, effective collaboration method that guides teams in fulfilling regulatory requirements.

In addition to using these industry leading capabilities in-house, our customers frequently use these capabilities to collaborate with external stakeholders. For instance, Jama Connect allows you to invite reviewers simply by email (Jama Connect licenses include more than enough reviewer licenses for this purpose). This works extremely well in practice. In fact, one medical device developer, RBC Medical Innovations, was able to shed hundreds of team-member days during development to save $150,000 in cost savings per project.

As a fully web-based software as a service (SaaS) product, Jama Connect offers customers a standard and secure web interface for cross-department or cross-company collaboration. Inviting customers or suppliers into your Jama Connect system is as easy as sending an email. User security can limit what is seen and allows for granular control of permissions. Our full version tracking enables everyone to see what has changed, who changed it and all impacts on upstream/downstream traceability.

RELATED: The Limitations, Drawbacks, and Risks of Using Legacy Requirements Management Tools

The Alternative: Controlled Data Exchange via ReqIF

Data exchange between organizations is nothing new, and many organizations have collaborated for decades, typically by exchanging documents. While this approach technically works, it results in unstructured data that provides no traceability, no understanding of changes between versions and no easy way to provide structured feedback.

The automotive industry is a great example of complexity across the supply chain with OEM’s traditionally working with hundreds of suppliers. It’s not unusual to find tens of thousands of requirements in an automotive specification, so managing these requirements is a challenge. In response, the industry developed an international standard for the lossless exchange of requirements called Requirements Interchange Format (ReqIF) and the standard was finalized in 2011.

A requirements exchange with ReqIF has some similarities to the old (and dreaded) document exchange process: One party exports a ReqIF file and hands it to the other party. The transfer can happen via a portal upload, automated exchange or even as an email attachment.

But here’s where the similarities end: A ReqIF file contains structured requirements data consisting of individual requirements with visibility into structure, attributes, related elements, and traces. ReqIF also supports incremental updates. If one party creates another version and exports a month later, you could import that version into your environment and the tool would show you clearly which elements, attributes, and traces have changed. For instance, you could use suspect links to re-validate only those items that have changed. Compared to trading .pdf files, which yes believe it or not many organizations still do, this is an extremely significant time saver and error avoiding capability.

While the standard is certainly more advanced than simple document sharing, it does have drawbacks. Not every tool adheres to the standards in the correct way. Data exported can be missing embedded images, required fields in one system are not required in another and user information (meta-data) is not universally available.


RELATED: Jama Connect in the Digital Engineering Ecosystem

Collaboration via ReqIF

ReqIF is commonly used to solicit feedback from a supplier. A producer could export the requirements for a supplier, including attributes for providing status feedback and comments. The supplier would then import the ReqIF file into the tool of their choice, where they could fill out the supplier attributes and send the resulting export back.

In addition, they could start integrating the imported requirements into their own development system. For example, they could establish traceability from the customer requirements through to design while keeping the process invisible to their customer.

Image Source: IREB Magazine

There are other use cases that ReqIF supports as well, but for all of them, the foundation is a controlled asynchronous exchange of structured requirements that keeps individual items, attributes and traces intact. Jama Connect supports this workflow and we have many customers that are using it today.

Bottom Line: How to Collaborate?

If you are using Jama Connect, the built-in collaboration capabilities are the most effective way to work together. Having 100% Live Traceability™ has been proven to increase product quality while reducing time to market.

However, if you are working with people outside your organization, that may not be able to collaborate using your Jama Connect instance a ReqIF-based collaboration could be an acceptable alternative.

Learn more about the benefits of upgrading your requirements management process with our paper, “Getting the Most from a Requirements Management Tool.

Product Team

A product team and an engineering team could be viewed as two sides of the same product development coin. So, ask yourself, “Who only uses half a coin?” It’d be like using just one side of your brain.

In a perfect product development world, communications are seamless, specifications are clear, and product and engineering teams work without friction. Except, we live in the real world where life is messy, responsibilities overlap, specifications change, and the way teams interact can introduce friction.

In the rush of product development, it’s important to establish boundaries for each team while also working as a unit and develop processes to head off trouble before it begins. This only gets more complicated with bigger and more technical projects.

The Product Team

Before the first line of code is written, someone needs to own the product and fully understand what’s being built and why.

It’s the product team that should understand the why, inside and out. From ideas that turn into research that guides specifications to conversations with customers, the product team is lining up the rubber ducks in neat little rows so engineers can focus on the technical problems. What do the ducks look like? How do they sound when squeezed? And what do users want?

Product teams tend to dream big, but they must also manage expectations and align goals with those of the overall business. That’s why it’s a good idea to get an engineering lead involved early in the planning process to build cross-team cohesion.

For example, if you’re building the next great blogging platform, maybe your commenting mechanism is the “killer feature” and the engineering team needs to focus on issues like authentication and moderation tools. How much of the apple can we bite off at a time? Such questions circle back to product team responsibilities like the business goals and strategy. Prioritization is the byproduct of open talks between teams to determine what is needed and what can be delivered on time.

It’s also worth noting that tension between teams is a natural and healthy aspect of working cross-functionally. Each team has its own set of internal goals, but those must align with overall strategic goals for the company (or product).

The product manager serves as the CEO for whatever is being built. If he or she asks for the moon, there must also be the understanding of the challenges that await.

We’ve probably all been in a meeting where something ambitious is proposed and the engineering team rolls their eyes, thinking, “If we could build that we’d all be zillionaires.” The balance here is one of awareness.

Technical teams need to be just as ambitious as their product counterparts, and that means understanding a little bit of each other’s worlds to know what’s feasible and what will cause deadlines to crash.


RELATED: A Guide to Good Systems Engineering Practices: The Basics and Beyond

The Engineering Team

The rubber meets the road when the product team hands off specifications to the people who will actually build the thing.

Engineering is the technical team of developers and managers who write the code and create the front end, so the clearer the guidance they get upfront, the better. That doesn’t mean micromanaging from the product team, but it does mean regular check-ins to increase buy-in, build cohesion, and avoid surprises.

Going back to our blogging platform example, let’s say there are some whiz-bang features on the front end that will dazzle users. A product manager might tell engineering to focus on those features. If the product team has done its job, the tech leads can accurately inform them how long it will take to implement the features.

However, they could just as easily warn the product team that there are backend issues to tackle to enable those frontend goodies. There’s no way to have one without the other, and this is another area where the tension comes in, as timelines might have to be readjusted.

When teams understand that they’re on the same side, everyone can take a step back to see the full map and make sure they’re headed to the same destination. It’s also where teams who understand each other excel.

Product must comprehend the engineering team’s needs, and engineering must grasp the importance of the product planning that came before. Maybe it’s a matter of a few sprints to see where the marquee feature is in a week. Or perhaps a lower-priority feature that really puts a kink in the line just needs to be delayed.

Either way, the only solution is to drop the egos and hash things out in realistic terms. Again, if product has done the job, both teams should be like looking at the release like a big X on a treasure map and walking there together.

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

One Team

If all of this sounds familiar, you’re not alone. Everyone in these teams is working under a number of different dynamics.

It could be that product feels it has defined everything so thoroughly that the engineering team can take the ball to the goal after a simple handoff. Of course, that is rarely the case.

More likely, there’s a stream of reviews to comb through and see how things are advancing (which, if you’re using the right solutions, can be handled faster and with less meetings) while moving the goalposts when one side reports a change in the variables.

So, what do you do? Learn to function as one team while respecting each other’s territory. After all, you’re all headed to the same goal. Even if your organization compartmentalizes each side, find a way to cross the streams. For many, the move from Waterfall development to Agile created a more efficient, functional model for developers, and a variation on that theme can serve you here as well.

First, create a great set of fundamentals with your product team by bringing in engineers as early in the planning stages as possible. Ask what’s feasible and go to lunch and dream about unlimited budgets. Integrate the engineering team as best you can, because their insight will save squabbling down the road. Then create specifications that are realistic.

Next, empower each side of the table with respect. Product may want the moon tomorrow and engineering will explain how much lift is needed to get there, so friction is inevitable. In the big picture though, both sides are arguing for the same goal, so keep that front-of-mind and allow room for either side to concede territory as needed. Conflict is normal and necessary, but if one side is utterly powerless and is continuously overrun, the “team” notion falls apart and the idea of collaboration breaks down.

If both teams are aligned, truly listening and making necessary adjustments, there’s no reason even large, complex projects can’t be finished on time and on budget. It takes work, especially if an organization is averse to cross-functional teamwork.

The payoff, though, is happier, more productive teams who share in the product’s success. It’s up to both sides to come to the table ready to cooperate.

Does that mean having certain boundaries? Yes! It’s unlikely the engineering team has done the market research to say whether a feature is desired by users. And it’s equally unlikely that the product team will accept a major delay for technical implementation if it was in the original specification.

Each side has a job to do, but the key is understanding that everyone is marching under the same umbrella in the end. That’s why it’s important to play the role you’re in while listening and accepting the experience and knowledge of the entire team.

preparing for fda inspection

FDA Inspection


In Part One of this two-blog series, I shared 5 best practices to prepare your organization for FDA inspection success. Inspections by the FDA can lead to regulatory action and consequences such as warning letters, recalls, and consent decrees. Thus, you want to put your best foot forward to demonstrate the compliance of your Quality Management System (QMS). In this Part 2, we’ll focus on the logistics for running a smooth and efficient inspection.

1: Tone and philosophy

First and foremost, everyone interacting with the FDA should be truthful, professional, and courteous. While this may seem like common sense, it is worthwhile to emphasize. The FDA is there to protect the public good by finding the evidence that your Quality Management System is compliant, so convey that you are there to help them in that goal.

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

2: Typical Roles

In its aim to demonstrate compliance to FDA regulations, an organization is balancing 3 things: 1) Providing the investigator with requested documents, information, and subject matter experts (SMEs) in a timely manner; 2) Understanding what topics the investigator may request go to next and prepare accordingly; and 3) Keeping a record of what the investigator has examined.

To that end, here are roles to have during an inspection.

  • Host – Serves as the primary interface with the investigator. This role is typically best served by your Head of Quality, as that individual understands the organization’s QMS and understands the FDA approach. If there is more than one investigator, there should be one host per investigator.
  • Scribe – Takes notes on conversations with the investigator and what the investigator is examining throughout the inspection. Like the host, assign one scribe per investigator. Folks great at listening and typing quickly make for great scribes.
  • Back Room lead – This person runs the Back Room, coordinating all the requests coming in, sending requests to the front room, and prepping SMEs. Even more importantly, this person is monitoring what is happening in the front room, anticipating areas of inquiry, and preparing accordingly.
  • Doc Control – Whether your organization is paper based, 100% with electronic records, or a hybrid, Doc Control is key to retrieving those records in a timely manner and keeping track of what has been presented and reviewed by the investigator.
  • Tech Reviewers – These folks inspect records before they head into the Front Room to ensure it’s the right document and noticing any issues that the host should be aware of before they are presented to the investigator.
  • Runners – Individuals who can retrieve information and SMEs as needed.

3: Set up a Front Room and Back Room

Typically a conference room, the Front Room is where activities with the investigator(s) are centralized. Aside from the investigator, Individuals are limited the bulk of the time to the host, scribe, and SME’s.

The Back Room is where document, information, and SME preparation occurs. A large conference room works best, not too far from the Front Room.

RELATED POST: The Rapid Rise of Digital Health Technology: Challenges and Keys to Success

4: Communicating between the Front Room and Back Room

Determine how information between the Front Room and Back Room will be shared. This includes document and information requests, as well as the conversations that are occurring. One way that works is a web-conference call (no audio or video) in which the scribe shares a document in which they are typing in live. This shared screen is then projected in the Back Room.

Direct chat channels between the scribe and Back Room Lead are also helpful to communicate information the Host should be aware of, like any delays in document retrieval, etc.

5: Documents/Request Management

Determine how documents and request management will occur. There will be time periods when requests are coming fast and furiously. Whether through a spreadsheet or database, it is important to keep track of what has been requested, when it has been presented to the investigator, and returning any hard copy records after the investigator is through with them.

Providing the investigator with the requests in a timely manner demonstrates that your organization’s QMS is under control and has nothing to hide.  Keeping a file of everything the investigator has reviewed is key if there is any action taken by the FDA that requires formal response by your organization. It is vital to know what was specifically reviewed so it can be referenced and referred to as necessary to inform those responses.


Your organization has worked hard to build and run its Quality Management System and prepare for an FDA inspection. Implement these tips to run an efficient inspection and demonstrate your compliance to FDA regulations.