In this video, we’ll discuss the reuse & sync capabilities in Jama Connect.

Jama Connect^® Features in Five: Reuse & Sync

Learn how you can supercharge your systems development process! In this blog series, we’re pulling back the curtains to give you a look at a few of the powerful features in Jama Connect^®… in about five minutes.

In this Features in Five video, Zeb Geary – Principal Professional Services Consultant at Jama Software^® – will go over the reuse & sync capabilities for requirements management in Jama Connect.

VIDEO TRANSCRIPT

Zeb Geary: Welcome to this segment of Features in Five. I’m Zeb Geary, a Principal Consultant at Jama Software. In this video, I’ll explain how your team can reduce time to market and improve quality by reusing and synchronizing requirements and other content in Jama Connect.

Teams often struggle to build on existing work when requirements and tests are spread across documents and systems. Lacking a live trace, they must manually identify and copy related content, increasing the risk of rework and gaps. Additionally, teams tend to lack visibility across efforts, causing necessary changes to not propagate across reuse content, potentially impacting quality and disconnected product design efforts.

Jama Connect simplifies and enhances the process of reusing requirements and verifications by allowing you to copy selected content with its containers and its traced items. Synchronization ensures visibility and enables key use cases such as parallel product definition, common content libraries, and product variance. Let’s look at reuse and synchronization in Jama Connect.

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

Geary: Here in Jama Connect, I’m looking at a project that we would consider a library or potentially a platform of 150% of our requirements. For this example, I’ve started building out the requirements and verifications for a new Jama Connect project, but I’ll be incorporating some standard or common requirements from this project. And through reuse, I’ll save time and ensure consistency with the platform.

I want to bring these common display requirements into my project from the platform. I see that these requirements have related verifications, and I want to bring these into my project as well. I’ll go ahead and select to reuse this folder. The reuse window shows me what I’ve selected for reuse and provides me with important options that reveal the significance of this capability. The first option determines if I will enable synchronization. If enabled, Jama Connect will establish a connection between the result of my reuse and its source so that I can monitor them for differences. I have options to include or exclude tags, attachments, and links, and to form a relationship to my source item from the resulting copy.

The final section of options determines how I will handle related content outside of my selection. Recall that the selective requirements have downstream verifications that I want to make sure I bring into my project. I will select the option to include related content and to mirror the relationships in my project. This saves me a lot of time since I will not have to recreate these relationships in the new project and removes the risk of missing verifications related to my selected requirements.

Finally, I indicate where I want to reuse the content to. I’ll select my project and I can have Jama Connect copy the project hierarchy as well into my target project, or I can select an existing location in my project. I selected my location and I will reuse with Sync.

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

Geary: In my project, the common display requirements have been reused with their related verifications. Here in my project, I can use Sync View to see how my reused items may differ from the library or any other project using these common requirements. Let’s check out this folder called “Scheduling.”

I can see from our sync items view that I’m in sync with the platform, meaning there’s no difference there, but we have a parallel effort that I am out of sync with. In Compare View, I can see exactly how we differ and bring those differences, if necessary, into my project. Sync View provides me with the visibility I need to make sure I’m working with the latest applicable requirements in my project. Here I will update the requirement text and I’ll create the missing requirement in my project. Now my project and this parallel effort are in sync.

As we have seen, reuse and synchronization is a key feature supporting critical requirements and verification activities. A Jama Software consultant can help you properly support your process with reuse and sync. If you have a Success Program with Jama Software, see our offerings under Improving Your Process to request assistance from a consultant. Your customer success manager can help you learn more about Jama Software Success Programs. If you would like to learn more about how Jama Connect can optimize your product development process, please visit our website at www.jamasoftware.com.

In the previous Jama Connect™ for Medical Device Development solution post, we learned how Jama Connect could:

• Establish and manage trace between design inputs and design outputs.
• Establish and manage trace between design inputs and verifications.
• Provide insight across these related Design Control activities.

Specifically, we saw how trace helped ensure alignment of these controls through acceptance criteria, increasing confidence in our verification activities and supporting visibility into the conformance of design outputs.

Capturing and managing design controls in Jama Connect expands the concept of traceability far beyond simply a reporting output required of the Design History File (DHF). Now, we’ll look at the importance of the trace in Jama Connect.  It’s for more than connecting information for the sake of documentation. It’s a way of working. The matrix provided to the DHF becomes a byproduct of working in Jama Connect.

Use the trace to build efficiencies into the design and

development process.

Organizations that use documents and spreadsheets to manage requirements, verifications and risk management feel burdened with the overhead of trying to manage the trace of information across documents. I’ve worked with many teams who’ve said managing trace was the number one concern about their current way of working, and the reason for their transition to Jama Connect. When we talked about their desired state after deploying in Jama Connect, near or at the top of the list was no longer having to generate and manage the trace matrix.

Prior to Jama Connect, many of these organizations waited until the end of an effort to create their required matrix. While working with these customers, I realized the trace matrix should not be an effort in itself — it should be a byproduct of how teams work. When trace becomes just how teams work, not only do they remove the burden of having to generate it in the end, they can actually use the trace to build efficiencies into the design and development process.

The out-of-the-box configuration provided with the Jama Connect for Medical Device Development solution was constructed around the value of trace – not simply having trace but using trace.

Using the trace in the Jama Connect for Medical Device Development solution enables you to:

1. Manage scope through trace

Often, coverage, or gap, analysis is seen as a way of simply dotting i’s and crossing t’s to make sure a trace matrix shows full due diligence in product definition, verification and risk management. While very important, it serves only reporting what was done and as evidence after the fact. However, when this information is live and accessible, it becomes meaningful during design and development activities, not just at the end.

In the Jama Connect for Medical Device Development solution, teams can use trace views and filters to make assessments about work prioritization and managing scope. For example, the solution provides visibility into:

• Accepted system requirements lacking subsystem requirements to make sure they are working on the right things.
• Subsystem requirements not tied to a system requirement to understand and manage scope.

This way, gap analysis provides meaningful data in the moment for decision making and course correction.

2. Plan and identify connected activities

Often, team members authoring requirements, especially system requirements, have a sense of the lower level product definition and verification activities. However, they may not know the full picture or they may not be tasked with defining lower level definition.

Some examples:

•  A systems engineer, in a top-down approach, may define a system requirement that will require interaction across software and electrical subsystems, though the engineer may not have the details.
• A hardware team, in a bottom-up approach, may identify a requirement of the firmware which needs to be managed through a system requirement.

In both examples, a higher-level design input, the system requirement, describes a function fulfilled across disciplines.

For Requirements

In Jama Connect we encourage capturing information about lower-level needs in the higher-level items, for allocation and for more detailed gap analysis. To handle the examples above, system requirements are configured to capture impacted disciplines, as shown below using a multi-select field:

In addition to capturing the impacted disciplines in the system requirement, the configuration requires subsystem requirements capture the single owning discipline, as shown below using a single select field:

With this level of detail captured in system requirements and subsystem requirements, trace again proves useable throughout product definition activities. Filters provided with the out-of- the-box configuration give visibility into system requirements impacting specific disciplines but lacking a subsystem requirement for each impacted discipline. For example, we can easily identify system requirements allocated to software that lack a software requirement, same for any other disciplines identified.

This looks at system requirements from a gap analysis perspective (“where am I missing something?”). Another use of this same view identifies work to be done. Like the example above, if I am a Software Engineer, I can use that same filter to identify all accepted system requirements that I need to work on – those expecting but lacking a software response.

For Verification

The concept described above for disciplines also applies to verification methods. The out-of-the box configuration of system and subsystem requirements provides a multi-select field for defining the verification method for the requirement:

In the verification items, we capture the method in a single select field:

Just like we saw for requirement allocation to disciplines, we can use trace for more detailed gap analysis to begin defining verifications early, as requirements are accepted. For example, trace can tell us which requirements verified by “Testing” or “Inspection” lack a verification of that type. Testing teams can easily identify verification coverage gaps and address those gaps as requirements are accepted, instead of having to wait for large, fully formed requirement documents to be approved.

The benefits of trace.

The benefits of trace and the ability to use trace as described above are only possible if trace becomes a way of working. There are three keys to making this a reality:

1.Capture design controls in a single system.

Including design controls in a single system marks the fundamental requirement of a useful trace. It’s too much work to manage connections across multiple documents and there’s too little confidence in the manual maintenance of the trace to be useful. A single system, like Jama Connect, affords teams the opportunity to make trace useful and actionable.

2. Create through trace.

To encourage trace as a way of working, you have to make it easy to connect to new or existing information. You can create new information, both upstream and downstream, directly from related items In Jama Connect. This allows for authoring of new information and the automatic tracing of items.

The image below shows just one way to establish the trace. This approach created new items directly from their related items.

We’re looking at a system requirement. I can create any of the listed related items directly from here, automatically establishing a trace. Note that what’s presented as options is determined by rules dictating what information can be traced. This ensures only valid traces are established. The Jama Connect for Medical Device Development solution enforces relationships through a relationship rule aligned to 21 CFR 820.30 and ISO 13485:2016.

3. Actively monitor trace

Jama Connect provides many ways to navigate item relationships, assess coverage and identify gaps. Trace View and Filters are important features supporting these activities. The key here is to act on the information these views provide. You can fill gaps and establish relationships established directly from these views. This is “actionable traceability.”

Catch up on all posts in the series.

We designed the Jama Connect for Medical Device Development solution to help device manufacturers realize the goal of designing and developing safe, effective and innovative Medical Device products. A goal we can all get behind!

Hopefully this series helps you as you work toward that goal. Each post had a purpose:  to introduce the Jama Connect for Medical Device Development solution and describe components of the solution, to learn how to incorporate systems thinking into design inputs activities, then to understand design inputs, design outputs, verifications, and the relevant regulations and standards informing the solution, and finally, how to use the trace.

I hope it’s been informative and helpful. Through these concepts, the solution brings value and introduces visibility and efficiency into design control activities.

 Stay up to date on the Jama Connect for Medical Device Development solution here.

LEARN MORE

In the previous blog of this series, we talked about the application of systems engineering principles to the design inputs process. In this post, we explore how the Jama Connect™ for Medical Device Development procedure guide describes connecting design inputs with subsequent processes: Design Outputs and Verifications. By supporting these processes in a single system and ensuring traceability we can build confidence in the conformance to design inputs and the proper definition of verification activities.

The Jama Connect for Medical Device Development solution focuses on two key aspects from the Design Output requirements defined by 21 CFR 820.30 and ISO 13485:2016 section 7.3.4. Design outputs:

• must  reference acceptance criteria, ensuring they are essential to proper functioning,
• are evaluated for conformance to design input requirements

Design outputs will vary based on the product, technology, discipline and applicable standards.

The regulation and standards are not specific about the content of the design outputs themselves. The significant activity then from a design control perspective is ensuring a trace to design inputs and visibility into the verification of those design inputs.

When defining design inputs (i.e., system and subsystem requirements), the guide recommends stating acceptance criteria directly in the requirement items. In fact, the system and subsystem requirements are configured capture it out of the box. Below is a sample System Requirement using the out of the box system requirement configuration.

Verification items, traced to design inputs, should be defined based on the acceptance criteria. Similarly, design output items (e.g., architecture diagrams) are traced to design inputs and refer to requirement details and acceptance criteria for design and development.   

 For some disciplines, like Software, Jama Connect may contain more detailed levels of abstraction and, therefore, may have items that tie directly into development tools. For other disciplines, Jama Connect may contain very basic information and pointers to other systems managing design outputs details, like parts for manufacturing.  

 The Relationship Rule below provided with the Jama Connect for Medical Device Development out of the box configuration shows how design outputs (in orange) and verifications (in green) trace directly to design inputs (in blue).  

Using this approach, the design input serves as the point connecting design outputs and verifications. Design outputs contain or point to evidence of the implementation of the design input, while verifications provide evidence through testing that the intent of the design input is met. Both design outputs and verifications reference the acceptance criteria captured in the design input during their definition and by nature of the trace. 

Connecting design inputs with design outputs and verifications.

The trace established by connecting design inputs with design outputs and verifications is visible in Jama Connect’s Trace View. The sample of a Trace View below shows a requirement with two related items downstream, a verification and design output. The verification in this example shows “Passed”, which indicates the intent of the requirement was met via implementation of the related design output.  

By capturing acceptance criteria during the Design Input process, exposing that information to related downstream processes, and using trace as a part of normal product definition activities, manufacturers gain visibility into the conformity of design outputs and build confidence in their verification activities and results. As seen in the Trace View above, relating information in Jama Connect is key to understanding coverage and verification.

In the next blog in this series, we’ll explore making further use of the trace, beyond simply matrix generation.

Haven’t read the earlier blogs in the series? You can catch up here.

Part One: Jama Connect™ for Medical Device Development Explained

Part II: Solution Components of Jama Connect for Medical Device Development

Part III: Design Inputs in Jama Connect for Medical Device Development 

Watch a demo to see Jama Connect Medical Device Development Solution features in action and understand how teams use it to support their development process.

WATCH NOW

As medical device manufacturers develop complex products, they require a product development approach capable of managing that complexity.   

At the same time, manufacturers must continue to ensure compliance and alignment with regulations and standards. These define requirements that ensure safety and quality and reduce risk—but ultimately do not prescribe specific tools or techniques.  

This is especially apparent in design control activities. Regulatory requirements define the “what” for compliance but leave the “how” to the manufacturer, as long the procedures describing that “how” remain documented and prove sufficient as part of the quality system.  

This lack of a prescribed approach to managing design controls can lead to uncertainty, but Jama Connect for Medical Device Development envisions that gap as an opportunity. Here, manufacturers have the space to deploy systems engineering techniques within design control activities, supported with a robust requirements, risk, and test solution. 

Note: Now that our medical device blog series is concluded, you can go back and read the series intro, Part I, and Part II.

Bring systems engineering into the design control process to manage medical device complexity.  

Systems Engineering solves the problem medical device manufacturers face. It takes a complex problem and divides it into manageable units so developers can see the solution both holistically and in its interrelated parts.   

Aligning to 21 CFR 820.30 and ISO 13485:2016 can naturally guide manufacturers towards this approach, requiring trace across user needs, design inputs, design outputs and verifications. The guidance does not account for the abstraction required within these areas, especially design inputs, allowing the manufacturer to determine and implement appropriate techniques and tools.   

The Jama Connect for Medical Device Development solution includes:  

• A Procedure and Configuration Guide    
• An out-of-the box configuration of Jama Connect   

Together, these components bring Systems Engineering principles and design control requirements into a single recommended approach. 

Here’s how.

1. Apply systems thinking.

The FDA guidance (FDA, 1997) indicates that product concepts are to be “elaborated, expanded, and transformed into a complete set of design input requirements.” Jama for Medical Device Development’s procedure guide applies systems engineering principles during this design input process.  

• User needs are fulfilled by functions of the system. 
• The system allocates them to specific engineering teams or product components for further, discipline-specific definition.   

In some instances, like where software is the system, abstraction of design inputs from system-level to subsystems may not cross disciplines. However, the need for hierarchical product definition remains and is reinforced by software specific standards such as IEC 62304 and IEC 82304.

2. Capture and organize design inputs.

In Jama Connect, these levels of abstractions are managed as Item Types, discrete objects within Jama Connect that allow the solution to enforce rules for how information should trace to one another.   

Concept-level information is captured as Intended Use and User Needs, engineering design responses as System and Subsystem Requirements. The total resulting set of requirements are referred to as the Design Inputs.

3. Establish the trace.

Below is a Relationship Rule provided as part of the out-of-the-box configuration of Jama Connect for Medical Device Development. In blue are the concept-level and design inputs:  

These Item Types are unique data elements within Jama Connect. They allow us to create logical groupings we can use to manage the hierarchical levels of abstraction and to further organize across disciplines.   

 Standardizing engineering principles for requirements management using discrete Item Types is a valuable shift. It shows customers shifting focus from pure document generation to support for how they actually work, which can range from top-down, to middle-out, to bottom-up product definition.

The end result: Actionable information and accepted design inputs.

This shift to a focus on discrete items instead of whole documents encourages teams to act on information as it becomes ready. By capturing status within each individual item (e.g., a specific system requirement), items are independently driven from “Draft “to “Accepted.” 
 
“Accepted” indicates a requirement is ready for: 

• Documentation in the Quality Management System (QMS).  
• Further decomposition or development.  
• Defining Verification.  

This single state can initiate several activities for other teams and does not require full document completion, which tends to restrict visibility and reduce momentum.  

Although this approach encourages a shift from a document-focused product definition, in reality a document needs to be generated for the Design History File (DHF). To support these potentially conflicting needs, the out-of-the-box configuration: 

• Drives organization of information based on a systems engineering approach.  
• Uses Jama Connect’s filtering capabilities to pull together information across the project for document generation.   

Using filters for document generation allows you to do more than collect different types of requirements for a single document. You can use data within the items, specifically in the Status of the items, to generate a document of only accepted design inputs. You can also take a baseline as part of the document generation process. The result is a snapshot of accepted design inputs that you can use for comparison reporting to show how design inputs may have changed over time. You can also indicate in each item’s version history which version of a requirement was included in the generated documents.  

 Use this Design Inputs approach with the Jama Connect for Medical Device solution to make it easier to generate documentation you need while supporting how you work with systems engineering approaches.  

  In the next post in this series, I’ll show you how to connect design inputs with design outputs and verifications.    

Watch a demo to see key Jama Connect Medical Device Development Solution features in action and understand how teams use it to support their development process.

WATCH NOW

Solution components in the Jama Connect for Medical Device Development solution help teams reduce time-to-value, provide guidance around customer-specific needs, and drive adoption.

We wanted the solution to offer a collection of training and documentation components that aligns to industry regulations so product development teams could get ramped up quickly.

The result: an out-of-the-box configuration of Jama Connect, an accompanying Procedure Guide, and Jama Professional Services. It’s a solution designed to reduce time-to-value, account for and provide tailored guidance around customer-specific needs, and drive adoption through tailored training and on-going support. Let’s take a look at the components and see how they help achieve those goals.

Note: Now that our medical device blog series is concluded, you can go back and read the series intro, Part I, and Part III.

Procedure and Configuration guide: Jama Connect, clearly aligned with regulations.

The Jama Connect for Medical Device Development Procedure and Configuration Guide provides detailed alignment between these regulations and standards and the out of the box configuration and recommended use of Jama Connect:

•        ISO 13485:2016
•        ISO 14971:2019
•        21 CFR 820.30

The scope and processes described in the guide are clearly identified and justified.

An important point to note: we identified the Jama Connect capabilities that align with the most relevant design control requirements needs. Then we targeted those needs, and optimized Jama Connect to meet them exactly.

The regulations and standards establish the design control requirements and provide some guidance, but they are not prescriptive in terms of tools or techniques. The procedure and configuration guide explains in detail how to bring in best practices from systems thinking, supported by use of Jama Connect, while still complying with design control requirements. .

Teams building complex medical devices will benefit from this systems-thinking approach and the way the Procedure and Configuration Guide builds these layers into the configuration. The principles and guidance provided by the Systems Engineering Body of Knowledge (SEBoK) and the recommended use of Jama Connect will bring clarity around product definition and verification activities.

Out-of-the-box-configuration: Start with standardized guidance and build from there.

The out-of-the-box configuration provides a recommended project template that allows customers to get up and running quickly.  It also serves as a starting point for customer-specific discovery and configuration. Each aspect of the configuration aligns with the applicable regulations and standard through detailed process activities and tasks described in the procedure guide

The configuration also provides Export Templates you can use to generate documentation from Jama Connect for transport into your Quality Management System (QMS), typically used to house all Design History Files for sign-off and audit.

On-site consulting and training services to align your teams quickly.
Jama Software’s Professional Services team works to help customers reach several goals:

• Build adoption, decrease time-to-value, and maintain ease of use.  
• Focus on process alignment, people readiness, and best practices for configuration and use.   
• Take advantage of the recommendations and guidance described in the Procedure and Configuration Guide and built into the out of the box configuration.    
• Provide end-user training tailored to the customer’s use and configuration of Jama Connect . 

Taken as a whole, the Jama Connect for Medical Device Development solution provides the guidance, justification and a starting framework that not only answers “what” Medical Device manufacturers should do when deploying Jama Connect, but also “how” and “why” they should do it.    

In upcoming blogs in this series, we’ll explore specific aspects of the Procedure and Configuration Guide and the out of the box configuration of Jama Connect. We’ll also look at how the solution components described in this blog are applied in practice.    

Download a Solution Brief for an overview that explains all the ways Jama Connect for Medical Device Development can help your teams manage shifting complexities and maintain product quality and safety.

DOWNLOAD NOW

Today, Jama Software announces a new solution: Jama Connect for Medical Device Development. The launch feels especially relevant right now. Over the next few weeks I’ll share details about it with you here in the blog. I’m going to talk about:

• The solution background: why it came to be and what it does.
• Solution Components
• Design Inputs
• Connect Design Inputs, Design Outputs and Verification
• Traceability

We’re pleased we’ll be able to help medical device manufacturers support design control activities in the highly regulated product delivery environment and contribute to their goals of quality and safety.

Note: Now that our medical device blog series is concluded, you can go back and read the series intro, Part II, and Part III.

Streamlined and focused configuration for medical device development.

The idea for the Jama Connect for Medical Device Development solution grew from the need to align quickly to medical device regulations and standards within a requirements platform.

The highly configurable Jama Connect platform allows customers to align the system with specific requirements, risk, and test process needs. If there’s a particular type of information to capture or a specific list of values that would support the overarching process, customers can configure Jama Connect to align and support it.

However, a highly configurable system introduces challenges. During deployments, you have to ask, “Yes, we can do anything, but what should we do?” Think of a highly configurable system as a blank canvas. You can find yourself staring, directionless, and not know where to begin.

That matters when there’s an entire team staring at the blank canvas. It wastes resources and impacts the time it takes to gain value from the system. In the end, the result can be a misaligned, frustrating deployment and low user adoption.

An out-of-box configuration that brings immediate benefits.

The challenge described above is precisely why Jama Software created the Jama Connect for Medical Device Development solution. We wanted to help Medical Device manufacturers who deploy Jama Connect in a highly regulated environment:

• Increase the value of Jama Connect, and decrease the time to realize that value.
• Access a recommended, out-of-the-box configuration.
• Maintain alignment with design control regulations and standards that Jama Connect is best suited to address.

With the Jama Connect for Medical Device Development solution, deployments no longer start with a blank canvas. Instead, the picture comes out of the box, justified and properly aligned with medical device regulations and standards. Configuration is still possible and valuable, but streamlined and focused.

Customers can hold an out-of-the-box configuration and recommended guidance against their operating procedures to:

• Identify and justify unique, customer-specific needs.  
• Determine the best approach to address those needs.  
• Incorporate customer-specific nuances for tighter alignment to the company operating procedures.  

In next week’s blog post, we’ll explore solution components in more detail.

Discover more details and watch a demo of the new Jama Connect for Medical Device Development solution here.

LEARN MORE

There are three main aspects of a project that tend to be in regular tension with one another: quality, schedule, cost. Typically, project management is about managing the tension that arises as focus and prioritization shift between these three elements.

Many times, organizations are forced to decide between pushing schedules, reducing costs, spending more on resources, and maintaining quality throughout the life of a product’s development. As a part of a product development lifecycle, requirements play a very important role in attempting to reduce or at least mitigate the tension between these areas.

Know What You’re Developing, and Why

Quality is, of course, a highly significant aspect of any product development effort. For many organizations, quality is paramount — especially in the case of highly-regulated industries like medical devices or automobiles, where quality concerns essentially amount to safety risks.

To ensure quality, you need to know what you are developing and why. And then, what are the requirements that meet those needs? In other words, a product should be defined to a meaningful degree before development begins. The distinction and order of “why” and “how” before “what” is a key element of requirements management.

This certainly does not mean that the product must be fully defined and agreed upon before any development happens. However, there should be enough definition to demonstrate that stakeholders agree on the needs and the high-level requirements meeting those needs, including acceptance criteria.

This is where a single source system becomes crucial, allowing cross-functional visibility to facilitate feedback and reviews to reduce the time and work between definition and development.

Requirements and Quality Assurance

Requirements are used to define the qualities of a system, features, or subsystem that meet actual user needs. A dedicated requirements management platform, like Jama Connect, helps ensure that development activities trace to actual needs and builds confidence that those needs are being addressed through gap analysis.

A gap in coverage happens when a need has been identified, but the engineering response to that need has not been provided. We often see this when higher level requirements don’t relate to anything, such as when an epic might be lacking stories.

Another aspect of improving quality is getting the right people involved at the right time. More eyes can sometimes be a hindrance to speed, but having people show up late to a discussion is usually worse. It’s important to make sure that not only the correct people are involved, but that the process for collaboration and reviews is clearly defined and well supported with a purpose-built solution, like Jama Connect.

Lastly, a discussion about quality would be incomplete without verification and validation (V&V). When writing requirements, it’s important to remember that the ability for a requirement to be verified is a key quality of a good requirement.

Typically, verification will happen against each requirement and is established by acceptance criteria determined while defining requirements. Validation, on the other hand, is concerned with whether or not you built the right product.

Through verification, you may determine that the product or feature works, but validation is focused on answering whether you actually met the need you set out to fulfill.

When considering the decisions and trade-offs made around quality, especially in relation to cost and schedule, having verification and validation activities closely tied into requirements definition can bring quality discussions closer to the front-end of an effort and avoid impacts of finding issues late in the lifecycle. Having a live and actionable trace matrix is essential in supporting this, especially where a product’s quality is non-negotiable.

Staying on Schedule Requires Visibility and Tracking

Schedules are mostly concerned with timelines and meeting time-based delivery of the product or its features.

In order to manage a project, the approach needs to be determined and then the infrastructure put in place to support that approach. From a product definition standpoint, the requirements may need to be organized in a way that makes sense for decomposition and capturing the granularity needed to properly define and align the product and teams. From there, development teams will collect those requirements into backlogs of work and manage the development of activities using a preferred methodology.

A quick way to build efficiency into this process, regardless of the methodologies implemented, is to manage at the level of discrete, individual items and move away from documents.

In terms of releasing pressure on the schedule, the idea is that instead of gating development and work based on large documents, manage the state of individual requirements, moving them independently through definition, acceptance and into development. Of course, logical groupings of requirements will necessitate some structure, but just identifying that appropriate organization will minimize the collection size and improve speed.

An obvious detriment to the schedule is people working on the wrong things. This can happen when teams do not have visibility into how what they are working on connects to the larger product definition.

To avoid this, consider the trace to a defined need as part of the approval and criteria for adding requirements into the backlog. Working on requirements lacking this trace runs the risk of working on the wrong thing. Of course, as you get into development cycles, new work may be discovered that helps facilitate and enable development, but this should be considered as potential scope creep.

Lastly, when it comes to schedule, it’s important that teams are tracking their work. You’ll likely be asking different questions at different phases of the effort. The important thing is that you clearly identify what you need to track to ensure progress and minimize issues that might fall through the cracks.

Once you know what you need to track, then you need to capture that data. In Jama Connect, as an example, you can track the state of requirements across the workflow, from draft through approval, which helps determine progress and find roadblocks. At a minimum, you’ll want to consider tracking the status of testing as well. That information is not the only key to the schedule but is also very important when assessing quality.

Avoid Rework by Defining, Agreeing, and then Developing

From a project management standpoint, the key metric related to cost is typically actuals again budget, where we’d take a baseline of the estimated cost and compare it to the actual cost to date. However, the cost is about more than money spent against the budget. It is also concerned with the cost of missed opportunities or lost market share.

One of the most expensive occurrences in product development is rework. Rework happens when teams get through some development activities only to find that they didn’t build the right thing or that the user needs are not actually fulfilled by what was developed.

To avoid or at least reduce rework, teams must define, agree, and then develop. The more teams can align around what it is you’re actually building and just how that thing will be verified, the better-aligned development activities will be. Additionally, as requirements are generated, verification should be defined at each level of abstraction.

Another way that teams can avoid cost and potentially positively impact their schedule is to reduce the time that teams are waiting to begin activities. This tends to happen when visibility across a development lifecycle is low and access to information is limited.

Using a single source system, like Jama Connect, and providing individual requirement status allows teams to start acting on information as it’s available and ready. As an example, if requirements are accessible and their status is visible, quality teams who handle V&V activities can begin their planning and verification activities much earlier than if they were waiting for documents to be released.

Change is another aspect of cost that’s often overlooked. Change is inevitable as we learn new information and get feedback throughout the product lifecycle. However, the cost of change can be mitigated by identifying and evaluating the impact of that change across the product. Change to a single requirement could impact definition and verification across multiple degrees of separation. Using trace, costs can be avoided by identifying and communicating these impacts early, even before applying the change.

Inform and Justify Decisions to Understand Impacts

In order to balance the three elements of project management discussed here, consider decisions that are being made and the tradeoffs determined during the lifecycle of your product development effort. In most cases, the decisions are working to balance quality, schedule, and cost.

The key to project management is being able to inform decision-making, justify these decisions, and understand the impacts. Properly managing your requirements can inform these decisions by being able to track requirements by their individual state, assess the trace for impacts and gaps, and ensure visibility and communication across teams.

Want to learn more about successfully managing every project? Check out our eBook “Project Management Best Practices” for 21 tips on taking the pain out of project management.  

At a conference I attended recently, I listened to teams discuss the challenges they faced in deploying software in their organizations. The consensus was that the software is easy; the people are hard. That is to say, getting up to speed with a new software solution itself is relatively easy compared to getting people to change their behavior and successfully adopt new software. 

ROI Requires that Teams Actually Use the Solution  

One of the speakers said something that really stuck with me. This person said, “There is no return on investment without adoption, and there is no adoption without user acceptance.” And while that may seem obvious, many times the end user of the software is forgotten. Other priorities — like budget, schedule, and various agendas — put a lot of pressure on the deployment plan. The human aspect, as important as it is, gets lost. 

Gaining Acceptance Later in the Implementation Will Cost You 

When implementing a new solution, it’s imperative that you get your team on board from the get-go – and not just for the purpose of keeping them happy. Just as it’s more costly to identify inaccurate requirements late in the product delivery lifecycle, the same principle holds true for user acceptance. Resistance from users identified late is always going to be more costly than adoption issues identified and addressed early.  

While implementing a new solution may be a top–down decision, it’s important to remember that the users are the ones who will need to adapt to the change. The primary impacted stakeholders (i.e. the end–users) will be more receptive to a major change if they are participating in the process, rather than being told that they must adopt a new tool.  

Change is difficult, and without a full understanding of the benefits of a new solution, teams may feel frustrated or resistant. One way to preemptively combat resistance is by identifying long- and short-term goals for each team member and encouraging users to be involved in the implementation process. 

The Key to User Adoption is People  

Having worked in professional services for over a decade, I have come to see just how valuable it is to understand the people side of deployments. In my years as a business analyst, I’ve seen from the inside just how difficult it can be to get people on board with new solutions, particularly those that also come with process changes, and how to make those changes stick. 

My interest in this topic goes even deeper. A few years ago, I completed a master’s program in psychology where I studied human behavior and why people do or do not change. I’ve found that what I learned during my study of psychology has translated quite well to the consulting world. 

In this post I won’t be able to outline the perfect adoption plan for your organization; this would be futile as no two companies have the same needs or challenges. But I will discuss the approach we recommend when planning for a solution rollout that maximizes adoption. 

If You’re Taking a Trip, Bring the Whole Team Along 

 I’m going to start with an analogy:  

Let’s say you’ve pretty much determined that everyone on your team could benefit from a vacation. You’ve even heard people say so. You’ve had some good conversations about what people want and need, and with that knowledge you pick out a destination that’s going to recharge everyone. 

Next, you have to figure out what kind of transportation you’re going to use to get everyone to the identified location. You’ve gone online and talked to some others about what kind of vehicle works best for teams like yours.  

So, with the information you have, you go ahead and buy the perfect car for this trip. It has all the things you need.  

In case you haven’t figured out how the pieces of my analogy fit into the rollout of a new solution, here it is:  

• The people are those who would benefit from a new process and solution to meet their business objectives 
• The “destination” is that ultimate goal, where the benefits are realized 
• The “car” is the new software solution that gets you to that ultimate goal

But here’s something you have to consider before you embark on this journey: You have to figure out where everyone lives, what kind of baggage they’re bringing with them, and how you’re going to organize picking them all up so you can all be in the car at the same time, happily enjoying the journey to your destination. More on that in a bit.  

Key Factors in Planning a Successful Software Deployment 

If you’ve ever actually planned an out-of-town experience with coworkers (or family, for that matter), you know it’s impossible to make everyone happy all the time. Introducing a new way of working to your teams can be even more difficult. Why? 

Before I answer that, remember that these are the main things to keep top-of-mind when planning a successful deployment: 

• Bringing new teams into a new solution, with new processes, is not simply a functional or technical issue; it is a people-centric change. 
• Benefits that require that people adopt the solution inherently require that those people change behavior. 
• The longer adoption problems go unaddressed the more difficult and expensive they are to address.

New data for 2019 reveals the growing gap between product complexity and requirements management. Find out more by downloading our report. 

Design Your Approach Based on the Specific Needs of Your Team  

Change is hard – especially when people are involved. You can put up your pie chart or line graph with anticipated benefits and have everyone nodding their heads in agreement, and you can find the perfect “car” to get you there. But you cannot assume that pointing at that amazing vacation spot on a map or showing off your awesome new vehicle will translate to motivation and acceptance for the people who must be on board in the end.  

Of course, some will be on board immediately, so make sure you identify those people and train them to evangelize for the effort. These advocates are a great asset as you complete your rollout to the rest of the organization. Successful organizations often pair these early adopters with new users to help them get up to speed with the new process.   

Others may need more attention, and you must pay careful attention to their fears and objections and speak to them early and often. 

Consider the Delta Between Where Your Team is Today and Where You Want to Be 

You must consider the maturity of your organization and teams. Of course, it doesn’t have anything to do with the emotional maturity of the individuals (though that could come into play), but the maturity of their processes and toolset and how they’re accustomed to getting their work done today. In my experience as a consultant, I find that team maturity ranges widely, especially when it comes to requirements management processes and supporting tools.  

Knowing where teams are — or their level of maturity — is important for a number of reasons, not least of which is anticipating resistance. Think about the person who is currently using a Word doc that they keep somewhere on their laptop to manage the requirements for a really complex product. This might be considered a pretty basic level of maturity. 

Now, before bringing this person into a new solution, it is important to think about the degree of change being asked of this person. What does a single-source collaborative system feel like to a person coming from Word files on their computer? What resistance can you anticipate and what will be your approach? Again, communication early and often is going to be key to getting this person on board with a new solution.  

Learn more about best practices for change impact analysis by reading our blog post. 

Engage with People to Counteract Resistance 

When change is introduced, the initial reaction from most is to resist. This isn’t necessarily a bad thing, as not all change is good. But if you don’t address resistance, it can lead to rigidity, causing teams to dig their heels in and get stuck.   

When you are bringing on a new team into your deployment effort, don’t just set up training on how to use the tool. You’ll want to engage with your people at a personal level so you can uncover their anxieties and address them. You’ll need to anticipate their questions and welcome their concerns. When you know their concerns, you can address them; it’s the concerns you don’t know about that can manifest very late and cause problems for the whole deployment.  

For example: Consider a person who has yet to log into the software even a month after deployment. What did we not know about this person that let them slip through the cracks? A quick way to find out is to simply ask them. 

Remember that unanswered questions today turn into resistance tomorrow. Provide opportunities for people to voice their questions early so you can address them. Consider establishing clear channels for communication with users.  

Explore product development strategies for systems engineers by downloading our whitepaper. 

Adopt a Change Management Model to Give Your Project Structure 

There are many change management models out there, and I recommend researching these until you find one that make sense for the size of your company, its culture, and your strategic goals. I personally like the ADKAR model from Prosci. 

The five parts of this specific change management model fit well with how we’ve been discussing bringing on teams to improve adoption: 

• Awareness of the need for change. 
• Desire to participate and support the change. 
• Knowledge on how to change. 
• Ability to implement required skills and behaviors.
• Reinforcement to sustain the change. 

 We’ve also seen great success from teams who have read this book: “Change Management: The People Side of Change,” by Jeffrey M. Hiatt and Timothy J. Creasey.  

A good change management model, like ADKAR, will help you consider the approach you want to take as you get started on your deployment plan. You’ll want to think about:   

• How you will build awareness, not just of new processes and solutions, but also why you’re taking on this initiative and what you hope it will do for your organization. 
• How you will communicate the benefits of using the solution, particularly the “what’s in it for me” for each individual or each team. 
• How you will build knowledge about how the solution works, relative to the current tool, and how to get the most of it. 
• How will you ensure people gain the ability to use the solution with the proper training for their position, in a style that will help them feel empowered and not burdened through the learning curve. 
• What kind of reinforcements you can use to ensure that the process change sticks and the initiative’s objectives are met. 

These are just a few examples of how to use the ADKAR model but the key is to engage with this line of thinking early and be open to adjusting as you learn more.

To learn more, watch our webinar to learn about other best practices for implementing new technologies.  

Systems thinking is an approach to solving complex problems by breaking their complexity down into manageable units so the system can be evaluated holistically and by each constituent part. This approach is critical to how we align Jama Connect™ to tackle the daunting complexity of medical device development.  

In our experience working with some of the market’s foremost medical innovators, we’ve seen that teams who embrace systems thinking are better-positioned to modernize and improve their product development processes. Jama Connect is informed by systems thinking and regulatory requirements, while its framework remains flexible enough to accommodate the unique needs of diverse development teams.

In this post, we’ll lay out how and why complex medical device development teams should be using systems thinking to streamline and strengthen processes, according to a recent webinar.  

Why Systems Thinking? 

Complex medical device development teams use systems thinking as a diagnostic tool: a disciplined approach to examining problems more completely and accurately before taking action. Systems thinking encourages teams to ask the right questions before assuming they know the answers.

A systems thinking approach opens up your team and organization to procedure-level improvements and the ability to take full advantage of solutions that support them. 

Even manufacturers developing complex systems that involve multiple disciplines and require the management of numerous subsystems may not be realizing the full value of systems thinking for managing design, collaboration and traceability across teams.  

Visibility and Collaboration 

With a systems thinking approach, teams developing complex medical devices can improve their processes by enhancing visibility and enabling more seamless collaboration and coordination between stakeholders.  

Complex medical device development requires that the right people have visibility into the relevant parts of the system, and a systems-thinking approach helps ensure that the right questions are being asked and addressed. 

Systems thinking also drives teams to coordinate and communicate through a common system need. Collaboration becomes easier and more effective when teams are free to find approaches within their disciplines that are most effective for them, while still meeting the needs of the system.  

Design History File, Verification and Traceability 

Systems thinking also gives teams better tools for managing complexity and change during the design process. With an applied systems approach, organizations can realize and resolve inefficiencies in their product development processes while producing the necessary outputs for the design history file (DHF). Jama Connect, designed to support systems thinking, aligns how your team works with the artifacts required for compliance and the DHF. 

If you’re following ISO 13485 and the FDA regulations for design control, for instance, you’re already driving toward a general systems approach. The regulations require the definition of user and patient needs and the tracing of engineering responses to those needs as design inputs. However, the regulations rightly leave room for manufacturers to define their own procedures, so long as the outcome demonstrates the relationship between the needs, the subsequent design inputs and the resulting design outputs and verifications.  

Applying a systems approach to how you work means that the value of understanding the interrelatedness of the design requirements doesn’t just live in the trace matrix document. This value is realized when you can visualize and interact with the trace during your design definition activities and beyond. The trace must be maintained throughout the design process to be helpful. Thus, the matrix you need for your DHF becomes a byproduct of how you work, not something you stitched together at the end of the design stage when you needed that documentation.  

The same can be said for your design input files and other artifacts: They’re most valuable when they are considered as byproducts of how you work.  

Additionally, verification and quality teams can leverage systems thinking to assess and define verification activities for the system even as other teams explore their responses to the system needs. 

Since lower-level requirements and outputs are defined within the context of a specific system need, traceability allows teams to understand that context and the downstream impacts of any change made.  

Customized Solutions for Medical Device Developers 

Our professional services team has also established a recommended framework for Jama Connect via our Medical Device Services. This framework, informed by systems thinking, guides regulatory compliance while remaining flexible enough to accommodate the diverse needs of teams and organizations.  

In this framework, the need for documentation informs rather than constrains, and it isn’t at odds with your drive to improve your process or the solutions you deploy to realize those improvements.  

Stay tuned for more posts about improving medical device development and the integral role Jama Software is playing for its customers.