Tag Archive for: Collaboration & Alignment Page 2

Tag Archive for: Collaboration & Alignment

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

In this blog, we recap our eBook, “Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Aerospace” – To download the entire thing, click HERE.

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

Use a Single Platform to Accelerate Innovation in Aerospace Systems Development

Consistently meeting product security, reliability and safety requirements proves the top challenge for aerospace systems development lifecycles. Contract complexity, streams of new regulations and policies, in addition to the challenges presented by increasingly networked systems, add to the already onerous development processes. This can lead to unmet technical performance parameters or delayed airworthiness certification reviews which for commercial aviation today takes years, to possibly lengthen out even more.

Effective management of these shifting complexities impacts your ability to meet compliance and ultimately, critical timelines. As a result, your development teams could find themselves:

  • Mired in rework
  • Making trade-offs without context
  • Stuck in unproductive meetings

In this industry, aircraft and space systems development requires strict attention to safety and security requirements, as well as continuous innovation and fast paced development to remain competitive. Ineffective stakeholder collaboration and communication between suppliers, government customers, contractors, and vendors can lead to delivery delays and cost overruns.

Bottom Line: The accelerated development of safe, high-quality aerospace systems, coupled with a highly complex regulatory and contractual environment, create competing challenges, and make it difficult for teams to focus.

What if you didn’t have to compromise?

This Buyer’s Guide incorporates insights from Jama Software’s more than ten years of experience partnering with forward-thinking systems development teams. We’ve designed a platform to help aerospace systems development teams manage the systems engineering data and controls. This allows them to:

  • Align to industry regulations quickly
  • Simplify contract deliverables and certification preparations
  • Accelerate time to market and mission

Use these insights to better understand the challenges you’re up against and thoughtfully consider potential solutions. Plus, learn how to get the buy-in you need to undertake the kind of transformation necessary to succeed with complex systems development.

Making the Case for Change

Jama Connect for aerospace systems development helps organizations to manage systems complexity and replace documents or legacy tools with a single digital platform. When requirements, architecture, V&V, and safety analyses are managed in a centralized location, contract deliverables and certification preparations become a straightforward process and the business impact and value of the platform becomes clear across the organization. That makes executive buy-in easier.

Corrective actions can cost anywhere from $1.6 million for a small change (Gulfstream Model G–1159A and G–1159B airplanes and all Model G–IV and GIV–X airplanes to remediate the ground spoiler actuator installation) to a large corrective action that has indirect costs of lost revenue and diminished market cap at over $20 billion (Boeing 737 MAX). Those costs are especially significant considering the price tag of system development – $75 million in FAA compliance alone—and an average timeline of three to seven years for type certification alone. For a space system, a failure can mean the entire loss of a system or spacecraft; typically there is only a single system created.

Chart showing time-to-market competitive market costs.

If your company is not considering the importance of transitioning to a more streamlined development process, time is not on your side. Failing to act quickly can leave your organization even further behind. But to see the value a positive impact a system can have, stakeholders in an organization have to appreciate the challenges first.

This is where you come in. You can help quantify the problem within your organization and provide data to help make the case for change.

Go through the exercises in the next section using data from your organization to identify your current situation and the size of the potential opportunity.

RELATED: CIMdata: Digital Thread in Aerospace and Defense

Tools to Assess Four Development Pain Points

Throughout the past decade of working with organizations developing complex aerospace systems, four common systems development pain points continuously arise for those who have yet to transform their process.

We’ll provide context around the problems and share equations with examples to help you uncover the savings from a modern systems development solution. Remember to adjust the variables according to your company’s metrics to get a more precise estimate, and rethink how your team functions.

Improving any one of these four aspects of your development process produces real savings. While the calculations on the following pages aren’t cumulative, they impact one another and can add up to significant value for your organization.

This is the potential of using a modern systems development platform. If realized, it can radically change your business and be the competitive edge you need in today’s market.

The Four Common Development Pain Points

  • Unproductive Work Time
  • Lengthy Time-to-Market
  • Rework
  • Defects

Unproductive Work time

Are your days spent in inefficient meetings, sifting through emails and document versions for historical information or waiting for reviews and approvals? You’re not alone. Many teams suffer the repercussions of archaic, siloed development. A modern process maximizes efficiency by tackling the root causes of momentum-killing delays and holdups.

Calculate how much unproductive work time is costing your business and imagine the possibilities of getting that time back. What could you do with one extra hour each day?

PRO TIP: We’ve seen long status meetings shrink or vanish when teams have the right solutions in place. Think about your team’s schedule and adjust the average time saved per person based on the time spent in meetings each week.

Lengthy Time-to-Mark

Time to market or meeting a mission deadline and quality are usually seen as compounding challenges. Understanding the impact of change, capturing decisions, communicating feedback and reusing
existing intellectual property — all aspects that can help speed time-to-market — can be improved with a modern systems development solution.

PRO TIP: Cost savings can certainly be great and have an impact on your bottom line, but don’t forget the qualitative implications. Consider what it would mean for your systems line and brand to be first-to-market with game-changing systems.

RELATED: Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development

Rework

In our experience, approximately 30-50% of a given project is rework. Rework is any time spent on extra work — including mid-development changes, incorrect testing or fixing defects — and it costs your company big time. Requirements errors cause the majority of rework. Improving the ability to track requirements from definition through testing to catch changes and adjust scope can ensure
you’re building the right thing and massively reducing overall lifecycle costs.

Complete the equation below to get an understanding of the number of hours your team spends in rework and the value of that in work hours alone.

PRO TIP: If your organization is working on more than one system at a time, repeat this calculation for each and add up the savings for a holistic view.

Defects

It’s common for requirements to have a defect at some point between definition and delivery. The important thing is to have a system in place that can quickly and accurately identify defects and
track their impact up and downstream. This provides visibility into the problem as early as possible when it’s less detrimental to fix.

PRO TIP: This calculation factors in personnel hours, but you should also think about the cost of parts, delays, and missed opportunities. Plus, should defects go undetected due to sub-par requirements or testing, releasing lower-quality systems could have devastating consequences.

“A document-centric approach often requires a gatekeeper and really limits collaboration – that creates a bottleneck. With Jama Connect, all our development teams can work together from anywhere with a shared collaboration hub.” – David Cubbage, Director, LEO Satellite Engineering and Production, Telesat

This is a preview of our eBOOK, “Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Aerospace”
– To download the entire thing, click HERE

Project Lifecycle Management (PrLM): A Comprehensive Guide

In this blog, we’ll recap our eBook, “Project Lifecycle Management (PrLM): A Comprehensive Guide. Click HERE to download the entire thing.

Project Lifecycle Management (PrLM): A Comprehensive Guide

Welcome to “Project Lifecycle Management (PrLM): A Comprehensive Guide.” In our eBook, we will explore the principles, methodologies, and best practices for effective project management throughout its lifecycle. Whether you area. seasoned project manager or someone new to the field, this guide will provide you with the knowledge and tools necessary to successfully navigate the various stages of a project and deliver exceptional results.

Project Lifecycle Management (PrLM) vs. Product Lifecycle Management

We know there is often some confusion between Project Lifecycle Management (PrLM) and Product Lifecycle Management (PLM) so just to set the stage, here is the high-level difference:

  • Project Lifecycle Management (PrLM) — the focus of this paper — refers to the overall management of a project from its inception to its completion. It encompasses activities such as project planning, execution, monitoring, and delivery. PrLM focuses on managing the project-specific processes, resources, and deliverables to ensure successful project outcomes within the defined constraints of time, cost, and quality.
  • On the other hand, Product Lifecycle Management (PLM) deals with managing a product from inception to delivery throughout the course of its entire lifecycle. PLM involves the strategic planning, development, and support of a product while taking into account factors like design, engineering, manufacturing, testing, distribution, and even customer service. Throughout its lifespan, it attempts to maximize the product’s quality, functionality, financial success, and market viability.

In summary, while PrLM is concerned with managing the overall project activities, PLM is focused on managing the lifecycle of a specific product, system, or software, including its development, production, and market presence.

With that clarified, let’s begin our journey into the world of Project Lifecycle Management.

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

Understanding Project Lifecycle

What is a Project Lifecycle?

A project lifecycle refers to the series of distinct phases that a project goes through, from its initiation to its closure. It is a structured approach that helps project managers effectively plan, execute, and control their projects. Each phase of the lifecycle has specific objectives, deliverables, and activities that contribute to the overall success of the project. By understanding the project lifecycle, project managers can proactively manage risks, allocate resources efficiently, and ensure that project goals are achieved.

Importance of Project Lifecycle Management

Project lifecycle management is crucial because it provides a roadmap for project managers to follow. It enables them to break down complex projects into manageable stages, making it easier to monitor progress and track outcomes. By adhering to the project lifecycle, organizations can enhance their project success rates, improve resource allocation, and minimize risks.

Common Methodologies Used by Project Lifecycle Management

Project Lifecycle Management methodologies provide a structured framework for managing
a project from initiation to closure. It is important to note that because of the similarities in desired outcomes and development process cross-functionality, PrLM and PLM methodologies often overlap. Here are descriptions of some of the top PrLM/PLM methodologies:

  • Waterfall Model – The Waterfall model is a sequential approach to PrLM. It divides the project into distinct phases, such as requirements, design, implementation, testing, and maintenance. Each phase must be completed before moving to the next. It’s suitable for well-defined projects with stable requirements.
  • Agile PrLM – Agile PrLM is an iterative approach that emphasizes flexibility and collaboration. It allows for continuous feedback and adjustments throughout the project. Agile PrLM is ideal for projects with evolving requirements and a need for rapid iterations.
  • Stage-Gate Model – The Stage-Gate model breaks the project into stages or phases, each with a decision gate where project stakeholders review progress and decide whether to proceed to the next stage. It’s useful for ensuring alignment with strategic goals and minimizing risks.
  • Spiral Model – The Spiral model is a risk driven PrLM approach that combines elements of Waterfall and iterative development. It involves repeated cycles of planning, risk analysis, engineering, and evaluation. It’s suited for projects with evolving requirements and high uncertainty.
  • V-Model (Verification and Validation Model) – The V-Model extends the Waterfall approach by emphasizing the importance of validation and verification at each phase. It highlights the relationship between development phases and corresponding testing activities, ensuring a robust validation process.
  • Iterative and Incremental Model – This PrLM approach involves breaking the project into smaller, manageable increments that are developed and tested iteratively. It allows for early delivery of partial functionality and is commonly used in software development.
  • PRINCE2 (Projects IN Controlled Environments 2) – PRINCE2 is a structured project management methodology that includes a well-defined project lifecycle. It focuses on governance, documentation, and clear roles and responsibilities, making it popular in government and public sector projects.
  • Critical Chain Project Management (CCPM) – CCPM is a PrLM methodology that prioritizes resource management and identifies the critical chain of tasks that impact project completion. It aims to reduce project delays and improve resource utilization.
  • Design Thinking – Design Thinking is a human-centered approach to PrLM that emphasizes empathy, ideation, and prototyping. It’s often used in creative and innovative projects to solve complex problems and improve user experiences.
  • Hybrid PrLM – Hybrid methodologies combine elements of multiple PrLM approaches to tailor the methodology to the specific needs of a project. Organizations often customize their PrLM processes by selecting components from different methodologies. Selecting the appropriate PrLM methodology depends on the project’s nature, goals, constraints, and the organization’s culture. Project managers and teams may adapt or blend these methodologies to best suit the project’s unique requirements and dynamics.

RELATED: Requirements Traceability Benchmark

Common Phases of a Project Lifecycle

This image shows a circular flow chart depicting the common phases of a project lifecycle.

Although the specific phases may vary depending on the project management methodology used, there are typically five common phases in a project lifecycle: initiation, planning, execution, monitoring and control, and closure. Each phase serves a distinct purpose, from defining project objectives and creating a project plan to delivering the final outputs and conducting a post-project evaluation.

Grasping the fundamentals of project lifecycle management enables project managers to lay a strong foundation for their projects. The next chapter provides a comprehensive
overview of the project lifecycle, emphasizing its significance, the key stakeholders involved, and the challenges that may arise. With this knowledge, project managers can embark on their project journeys with confidence and a clear understanding of the path ahead.

Initiating the Project

Defining Project Objectives and Scope

The initiation phase is the starting point of a project, where the project objectives and scope are defined. This involves identifying the desired outcomes, deliverables, and benefits that the project aims to achieve. Clear and well-defined objectives help align the project team and stakeholders, providing a common understanding of what needs to be accomplished. Additionally, project scope defines the boundaries of the project, specifying what is included and excluded. It is essential to establish realistic and achievable objectives and scope to set the project on the right track from the beginning.

Conducting Feasibility Studies

Before committing resources and efforts to a project, it is crucial to assess its feasibility. Feasibility studies evaluate various aspects, such as technical, economic, operational, legal, and scheduling feasibility. This analysis helps determine whether the project is viable and aligns with organizational goals and resources. It allows
stakeholders to make informed decisions about proceeding with the project, modifying objectives, or exploring alternative approaches. Conducting thorough feasibility studies during the initiation phase minimizes the risk of undertaking projects that may prove unworkable or unprofitable in the long run.

Identifying Stakeholders and Their Requirements

Identifying and understanding project stakeholders is a critical step in the initiation phase. Stakeholders include individuals or groups who have a vested interest in or can
influence the project’s outcomes. It is essential to engage stakeholders early on to gather their requirements, expectations, and concerns. By involving stakeholders
from the beginning, project managers can gain valuable insights and build support and commitment for the project. This identification process lays the foundation for effective stakeholder management throughout the project lifecycle.

Developing a Project Charter

A project charter serves as a formal document that authorizes the existence of the project and provides a clear understanding of its objectives, scope, constraints, and stakeholders. It outlines the project’s purpose, defines the project manager’s authority, and establishes the project’s high-level requirements. Developing a project charter during the initiation phase helps align stakeholders, gain project sponsor approval, and set expectations. The project charter becomes a guiding document that shapes the project’s direction and provides a reference point throughout its lifecycle.

Establishing the Project Team and Roles

During project initiation, it is essential to assemble a capable project team and define their roles and responsibilities. This involves identifying the necessary
skills and expertise required for the project and selecting team members accordingly. Assigning roles and responsibilities clarifies expectations, promotes accountability, and ensures that all necessary tasks are covered. Building a cohesive project team in the initiation phase sets the stage for effective collaboration and lays the groundwork for successful project execution.

By effectively initiating a project, project managers establish a solid foundation for success. This chapter has explored the critical aspects of project initiation, including defining project objectives and scope, conducting feasibility studies, identifying stakeholders and their requirements, developing a project charter, and establishing the project team and roles. Through careful planning and consideration in the initiation phase, project managers can position their projects for smooth execution and set the stage for achieving the desired project outcomes.

This has been a preview of our eBook, “Project Lifecycle Management (PrLM): A Comprehensive Guide.
Click HERE to download the entire guide.
Why Relying Solely on Documents Won’t Cut It in the World of Complex Product, Systems, and Software

In this blog, we’ll overview our recent eBook, “The Strategic Transition: From Word and Excel to Modern Requirements Management” – To read the entire thing, download it HERE

Why Relying Solely on Documents Won’t Cut It in the World of Complex Product, Systems, and Software

Unless your organization’s business model is built on a foundation of inefficiency, you should not be using disparate documents for managing requirements. Whether it’s Microsoft Word, Excel, or a combination of both, trying to wrangle your product’s requirements solely in documents carries a lot of risk and will gradually eat away at your company’s bottom line.

There was a time when using disparate documents wasn’t such a problem for managing requirements, but as products grow in complexity, those days are fading. Many companies no longer produce products that contain just hardware or software; today it’s likely a combination of both, increasing development complexity exponentially.

Integrating hardware and software means teams spanning various engineering disciplines all need to stay aligned throughout development, especially when things like safety standards and regulations are involved.

Using documents alone, will simply not be up to the task of meeting today’s complex products, systems, and software development. When you need precision, context, and accountability for your requirements, a modern requirements management solution is really the only answer.

In the blog post below, we recap our  “The Strategic Transition: From Word and Excel to Modern Requirements Management” eBook in which we detail some of the reasons why you’ll want to leave disparate documents for managing requirements in your rearview. You’ll also get an overview of the benefits you’ll gain by moving to a purpose-built software solution for requirements management.

Five Drawbacks of Documents

Microsoft Word and Excel serve many purposes, and have done so for decades. And, in terms of requirements, for early-phase documentation and coordinating simple projects, they still remain effective tools.

As the complexity of product and systems development grows, so does your list of requirements. And teams need solutions that provide simple and streamlined collaboration, not jumbled — often quickly outdated — comments and suggested edits.

Teams need to be able to instantly connect to globally distributed colleagues to facilitate real-time feedback and make smarter decisions with full context around requirements. Documents simply aren’t up to the challenge.

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

Here are some of the key limitations for a document-based approach for storing requirements:

1. Documents are tedious to maintain

Anyone who has ever managed requirements with documents and several collaborators is familiar with the unique pains of this approach. Whether it’s Word documents that are hundreds of pages long or Excel spreadsheets with thousands of lines, keeping them fresh with updates and free of errors is extremely cumbersome and time-consuming.

2. Versioning difficulties

Collaborating on any kind of important documentation can be painstaking, especially when there’s an enormous amount of requirements involved. For instance, when reviewing requirements, it’s incredibly easy for two people to be looking at different versions of the same set of requirements, and not even know it. And even if it’s a cloud-based version of requirements, there are still plenty of opportunities for someone to unintentionally change something without getting prior approval, and that adjustment not being accounted for in future versions. Plus, online/cloud-based documents do not automatically create different IDs and versions for each requirement or highlight the changes between versions.

3. No traceability

There’s so much room for error through email chains and undisclosed updates. It’s incredibly simple, for example, to miss a tiny change that could have critical ramifications upstream or downstream.

4. Reviews are time consuming

Without traceability, review cycles with an enormous document of requirements are extremely long. You’re likely looking at scheduling lengthy meetings or passing around version after version, pulling team members away from other priorities, which is not ideal when you’re focused on getting to market quickly. And if you’re trying to manage reviews asynchronously, collaboration becomes tricky and timelines are likely to get pushed as people’s schedules shift.

5. Exhausting collaboration between teams

Sharing constantly evolving requirements files among multiple stakeholders and different teams throughout the development and testing process is risky, frustrating, and time-consuming. And with your customer demanding a perfect product, system, or software delivered ASAP, you can no longer afford that kind of inefficiency.

Seven Benefits of Using a Requirements Management Solution

Despite rising product complexity and regulation, most development teams do not have a sophisticated requirement management system in place. In fact, according to a recent survey, almost one-third of teams have no system in place and rely on formal processes with email, documents, and shared spreadsheets.

Another 52% manage their requirements with a system which is not meant for managing requirements, like Application Lifecycle Management (ALM) or Product Lifecycle Management (PLM) systems. And only 15% have chosen to invest in a formal dedicated requirement management solution.

Using a dedicated requirements management solution allows teams to stop getting bogged down on processes and start innovating. For example, MediSync, reports that investing in Jama Connect® has saved 80% of the time that would have otherwise been spent on meetings, sorting through versions of Word documents and emails, and consolidating feedback in review cycles.

Grifols saved around 80 hours per project in medical device development when using the Jama Connect Review Center. And RBC Medical saved around $150,000 per project by improving team collaboration and workflow efficiencies using Jama Connect.

RELATED: The Jama Software® Guide to Requirements Traceability

Here are some of the benefits you’ll get from investing in a solid requirements management solution:

1. Version and change management

A solid requirements management solution will maintain a history of each change made to every requirement. You’ll also be able to record the rationale behind each change, and refer back to a previous version of a requirement if necessary. Some solutions contain a change proposal system that links change requests directly to requirements. And, with a formal requirements management solution, you’ll always know you’re looking at the most recent version of the requirements.

2. Requirements attributes

With a strong requirements management solution, you should be able to record several descriptive attributes for each requirement. The right requirements management software should generate several system-defined attributes such as the date the requirement was created, its current version number, and the person on the requirements should be able to view these attributes, even if only a couple of individuals are allowed to update the attributes’ values.

3. Facilitate impact analysis

A requirements management solution enables requirements tracing by letting you define links between different types of requirements, requirements and different subsystems, and individual requirements and related system components (designs, modules, tests, and user documentation). These links help you analyze the impact that the proposed change will have on a specific requirement. It’s also very helpful to have the ability to trace each functional requirement back to its origin or parent so that you know exactly where every requirement came from. And some solutions use a traceability link to raise suspect flags to a linked item whenever a change is made, so you know exactly what needs to be reviewed after a change.

4. Track requirements status

Collecting requirements in a database lets you know how many discrete requirements you’ve specified for the product. And tracking the status of each requirement during development helps communicate how things are coming along to those across the organization. So, a project manager has good insights into prior states if he or she knows that, for example, 55% of the requirements committed to the next release have been verified, 28% have been implemented but not verified, and 70% have not yet been fully implemented. This type of information gives the project manager information to anticipate the project’s progress, and relay the message to stakeholders accordingly.

5. Control access

A requirements management solution should let you bring as many people into the system as possible, and grant them permission to access the specific parts they’re working on. This helps teams across the organization feel more invested in the product being developed and its progress.

6. Facilitating communication with stakeholders

A requirements management solution should allow team members to discuss requirements issues electronically through a threaded conversation, in one central location, as opposed to having communication spread out across various platforms. It will automatically trigger email messages and notify effective individuals when a new discussion entry is made or when a specific requirement is modified. And it should allow team members to reach out to each other, but also contact non-project members and external users.

7. Recycling/reusing requirements

Storing requirements in a central database facilitates the reuse of them in multiple projects or sub-projects. And requirements that logically fit into multiple parts of the same product can be stored once and referenced whenever necessary to avoid duplicates. This saves a lot of time and reduces the chance of making errors.

TO READ THE ENTIRE EBOOK, CLICK HERE:
 The Strategic Transition: From Word and Excel to Modern Requirements Management


How to Integrate Jama Connect® with Microsoft Excel Using the Jama Connect Interchange™ (JCI)-Excel Functions Module

How to Integrate Jama Connect® with Microsoft Excel Using the Jama Connect Interchange™ (JCI)-Excel Functions Module

Everyday, the world’s most innovative companies use Jama Connect® to build life-changing products, software, and services. Jama Connect includes powerful requirements traceability, risk management, and test management capabilities to help our customers get their products to market faster.

Jama Connect also includes numerous configuration settings — which our customers use to adapt the tool to their organization’s engineering practices and achieve compliance to industry-specific standards and regulations.

On top of this wide range of options, though, many of our users still require an additional level of customization to really make Jama Connect their own – this just usually requires an adjustment to the workflow logic here, or an additional calculation there.

Other requirements management tools achieve this extra level of configuration using JavaScript extensions or complex propriety scripting languages that can take literally years to master (with the frustrations taking years off your life in the process!)

Jama Software® has solved this same problem using the much more accessible, universal language of Microsoft® Excel formulas. Our powerful Excel Functions add-on module can be purchased with our integration platform, Jama Connect Interchange™ (JCI).

RELATED DEMO: Jama Connect® Features in Five: Jama Connect Interchange™

How does the JCI-Excel Functions module work?

Imagine your average Excel workbook, where formulas are applied to certain cells to perform calculations or logically transform data. Now, imagine if you could apply those same formulas directly to fields in Jama Connect. Pretty powerful, right?

You can think of the JCI-Excel Functions as a calculator that runs in the background while you work in Jama Connect. As you enter fields in Jama Connect, field values are automatically sent to an Excel template where formulas are set up. Formulas are run instantly, and the resulting values are sent back to Jama Connect. Your Jama Connect users don’t ever need to open an Excel workbook or even have a license to Excel to benefit from this automation.

Sample JCI-Excel Functions workstreams

Last month we shared our most popular workstreams for streamlined software development using Jama Connect and Jira.

In today’s blog, I’d like to do the same for JCI-Excel Functions. As the Product Manager for JCI, I’ve heard from numerous customers who have used this module to achieve time-saving workflow automation, streamline manual data entry, and automate complex calculations.

Keep in mind that this is not an exhaustive list! If your team has another workstream they’re loving, I’d encourage you to post about it in the JCI Sub-Community for others to see.

RELATED: How to Use Requirements Management as an Anchor to Establish Live Traceability in Systems Engineering

Example #1 – Complex Calculations (Defect Prioritization Scenario)

Many projects incorporate complex and proprietary formulas or calculations that take years for a company to perfect. Rather than perform these calculations offline and input the results in Jama Connect manually, you can use JCI to map Jama Connect fields directly to an Excel workbook and watch the same calculations run automatically.

In this simple risk calculation, a Defect’s overall Risk Priority Number (RPN) is calculated using the following formula:
RPN = (A+B)*(C+D+E), where each variable is taken from a field in the item.

With JCI, fields A through E are mapped to the Excel template, where the formula is run. The resulting RPN is then automatically populated in the Calculated RPN field.

Example #2 – Field Inheritance Across Items (Library Scenario)

This flexible workstream allows you to share fields or values across related items. For example, you could maintain a standard or approved “library” of items in one part of the system, and automatically populate values from that library to other items as needed.

With this workstream, users no longer need to copy values across items manually. Instead, values flow automatically, and any time a field in the “source” item is updated, the “target” items automatically receive the update as well.

In this risk analysis example, values from a standard library of hazards and harms are automatically populated to an individual risk analysis item.

Example #3 – Logical Transformations (Software Development Scenario)

Use this example to update fields automatically when certain conditions are met. In the following software development scenario, we’ve set up a rule stating that when all downstream user stories have a status of Development Done, the upstream software requirement in Jama Connect should also be marked as Done. This workstream simplifies life for the product manager by allowing them to see at a glance when a feature is complete.

Conclusion

Jama Connect Interchange is an integration platform that seamlessly connects Jama Connect with other best-of-breed tools, like Microsoft Excel, and Atlassian Jira.

JCI is built, supported, and continuously enhanced by dedicated teams at Jama Software. This means that JCI is deeply integrated with Jama Connect configurations and workflows, providing you with a smart and seamless sync.

JCI supports both cloud-based and self-hosted instances of Jama Connect. If you’d like to learn more about Jama Connect in general or start a free trial of our #1-rated requirements management platform, please click here. If you’re already a Jama Connect customer and would like to find out whether JCI would be a good fit for your organization, please contact your Customer Success Manager.

FREE DEMO: Click Here to Request a Demo of Jama Connect Interchange™


Digital Engineering Between Government and Contractors

Digital Engineering Between Government and Contractors

How does a digital thread work when tool ecosystems are disconnected from each other? For the defense contracting world, THIS is the elephant in the room. The DoD (Department of Defense) wants its Digital Engineering (DE) vision to become a reality and they do realize it cannot happen overnight, so how is this being addressed today?

The short answer is that the DoD wants their contractors to set up their own DE ecosystems and then exchange deliverables. This is no different than what they have done for the past 50 years but the types of deliverables are changing. Namely, they want DE content to be delivered as models which means SysML, UAF (an enterprise architecture format), Computer Aided Design (CAD) I– if the government purchased the technical data for this during contracting – models. The DOD still requires deliverables in Word/PDF/Excel/MS Project for various project management deliverables and engineering analysis that is only representable in textural form as well.

“Within the new Digital Engineering Ecosystem, there are three possible scenarios for information access between customer and contractor. The scenarios are: 1. Provide access to controlled baselines in contractor environment. This is considered a low IP (Intellectual Property) and data rights loss risk option two. Provide access to controlled baselines in the contractor environment and provide selected models and data in accordance with contract data requirements. This is considered a medium IP and data rights loss risk option 3. Provide all required baseline models and data in accordance with contract data requirements. This is considered a medium-high IP and data rights loss risk option.” – (AIA Aerospace whitepaper)

Nightly Check-in Technique:

PLM tools are deemed the center of the ecosystem since these already have the digital twin information (hardware CAD, configuration management, and product management backbone) in place. Nightly check-ins of files (SysML model, CAD, requirements, Ansys, etc.) are thought to be timely enough to keep things in sync. With this model, both the government and contractors would utilize a shared or their own PLM systems.

SAIC ReadyOne – a ready-made DE ecosystem of tools that can be purchased and installed in one click. It is managed on AWS GovCloud and is available up to CUI level four today. It is meant to answer the call for an easy to deploy, cost effective, and powerful integrated environment that delivers Digital Transformation – SAIC created Ready 1. ReadyOne is comprised of two main components

  • The infrastructure which includes the servers, application stacks, and build automation
  • And the Digital thread platform with a custom data model – which you can think of as the plumbing that defines the available connections between the various data artifacts – like system models, parts, and simulations – within the ecosystem

ReadyOne is Built on a model based, low code, platform supporting openness, flexibility, and customization. OOTB applications allow domain specific content to be mapped to Items and artifacts as well as customization – ensuring uniqueness of process, instead of forcing synthetic commonality.

Developers use familiar domain specific applications for System Modeling, CAD, and simulation to author content. Domain tools utilize pre-configured connectors with business rules to ensure all data is connected and the single source of truth remains persistent. Enterprise configuration management is a foundational component ensuring each domain is utilizing the proper data and relationships to remove opportunity for errors.

Digital Thread

SAIC Proprietary

INCOSE Digital Engineering Information Exchange Working Group (DEIX-WG)

Group Goal = “The DEIX WG primary goal is to establish a finite set of digital artifacts that acquiring organizations and their global supply chains should use to request an exchange with each other as well as internally between teams/organizational elements.”

Product Descriptions:

  • DEIXPedia: Micropedia of digital engineering topics to explain relevant DEIX topics. STATUS = In place and updating
  • Primer: A Narrative that describes the concepts and interrelationships between digital artifacts, enabling systems and exchange transactions. STATUS = DRAFT
  • Digital Engineering Information Exchange Mode (DEIXM): A prescriptive system model for exchanging digital artifacts in an engineering ecosystem. STATUS = DRAFT
  • DEIX Standards Framework (DEIX-SF): A framework for official standards related to MBSE (Model Based Systems Engineering) Information Exchanges. STATUS = DRAFT

Digital Thread Chart

RELATED: Traceability Score™ – An Empirical Way to Reduce the Risk of Late Requirements

Defense Systems Integrator – Digital Engineering Use Case and Lessons Learned

At the NDIA 25th Annual Systems and Mission Engineering Conference one large defense contractor presented their working tool ecosystem and explained their use case and lessons learned.

Use Case:

  • Provide system stakeholders with visibility into the system
  • For Example:
    • Determine impact of a Change to the System (e.g., requirement, model, part.)
    • Determine impact of Simulation to the System (e.g., validate or invalidate a requirement.)
  • To do this, I will need a digital engineering ecosystem that:
    • Enables the integration of repositories, i.e., requirements database, SysML models, PLM system.
    • Provides a framework for creating digital threads across data repositories.
    • Provides a mechanism for querying / visualizing digital threads.
    • Provides a way to compare/sync data repositories.
    • Can perform model/data transformations, e.g., DNG requirement → SysML requirement.

Dassault Cameo Systems Modeler is being used as the main user interface to coordinate with other models in other engineering domains, e.g., Creo, DNG etc.

Intercax’s Syndeia Cloud and Cameo plugin is good at connecting artifacts across different engineering repositories (DNG, Teamcenter, etc.) This group felt that Syndeia was the easiest to use and offered the most connections to their various tools. (Cameo, Teamwork Cloud, DNG, Teamcenter, Creo, Jira, GitHub, MySQL, Volta, Matlab/Simulink, Excel) They felt that in most cases Reference Connections were ideal and that reporting and analysis of the digital thread in the Syndeia Cloud webapp was more robust than anything other tool in the marketplace. They felt that Syndeia Cloud’s export of digital threads relationships into Excel to give to government customers was satisfactory.

Their Lessons Learned:

  • Define the Process for creating “reference connections”:
    • Who creates and manages the links.
    • Directionality of the link are consistent. Note: SysML element should always be identified as the source of the link.
  • Identify what types of links (digital threads) you want to create, for example:
    • Create reference connections from DNG functional requirement(s) to its SysML <<functional>> block to show a <<satisfy>> relationship.
    • Create reference connections from a Teamcenter part/item/assembly to a <<physical>> SysML block to show a <<satisfy>> relationship.
  • Establish operational and QA environments for Syndeia:
    • For testing out new patches and upgrades.
    • QA environment for training/experimentation.
  • Use caution of using “Local Repositories” (because they are local!)
  • Configuration manage your data repositories:
    • Teamwork Cloud for Cameo.
    • Global Configuration Management (GCM) for DNG.

RELATED: Write Better Requirements with Jama Connect Advisor™

Model-Based Acquisition (MBAcq)

An increasing number of RFPs are not only requiring MBSE but RFPs themselves are now starting to be created as SysML models and responses are expected to be returned in a SysML model file. Yes, there are SysML tool vendors (PTC, Spec Innovations) and even contractors (L3Harris) asking the DoD to drop its language so that the file format is compatible with Cameo. These vendors are trying to ensure they can export and import tool-agnostic SysML that is interoperable with each other.

The challenge to both the supplier and provider is the lack of standardization in the approach, resulting in a learning curve for every proposal as well as response. To address this concern, the OMG UAF MBAcq Working Group was formed to survey the current landscape with participation from government, industry, FFRDC’s, tool vendors, NDIA, and OMG standards org. The goal is to come up with process guidance and a SE (Systems Engineering) and architecture guidance.

Planned Deliverables:

  • ARM template and guidance (how to specify model-based DIDs, CDRLs.)
  • GRM template and guidance (includes guidance for how NOT to over-specify a system.)
  • Sample model (as part of UAF sample model.)
  • UAF Process Guide for Acquisition will:
    • Define the CONOPS for how a program office will use all the models they will receive over the lifetime or a system.
    • Demonstrate how to make models available for reuse for other/new systems.
    • Provide portfolio management for the models/programs.
    • Provide process and guidance that describes how to integrate MBSE approaches into pre-acquisition (before request for proposal release), request for proposal, contract award, and contract execution steps.
  • Impact to existing policy with recommendations for change.
  • Descriptions of what Sections K, L, and M could look like for model delivery.
  • Taxonomies with precise definitions for concepts and terms.
MBSE Digital Thread Chart

NDIA 2021 Systems & Mission Engineering Conference

Digital Engineering Tool Suites

According to SBE Vision, digital engineering tools are a mixed bag of silos:

  • Not all tools lend themselves to remote linking data at rest.
  • Some tools don’t have a web server.
  • Many detail design tools require a “local” model data as a basis for initial processing.
  • Sometimes a transformative capability of some kind is needed.
  • Certain use cases require a mashup of three or more systems.

Two Worlds Apart

SBE Vision is also developing techniques for both OLSC and synced data approaches. Complications can arise from linking vs syncing, such as company product, use case dependent, and can change over time.

OSCLS – Linked Data:
  • Remote linking of data
  • Peer-to-peer
  • Human oriented
  • Benefits:
    • Data stays at rest
    • Clean paradigm
    • Standards
  • Challenges:
    • Semantics (relational)
    • Configuration management
    • Change management
    • Consistency of standards implementation
Synchronization
  • Creating (temporary) copies of data
  • Hub-and-spoke
  • Human & machine Oriented
  • Benefits:
    • Enables many use cases
    • Simple, easy to use
    • Rich transformation when needed
  • Challenges:
    • Semantics (relational & transformative)
    • Configuration management
    • Change management
    • Managing correlation/sync state

Conclusion

Jama Connect enables real-time team collaboration through traceability and digital threads. To learn more about achieving Live Traceability™ on your projects, please reach out for a consultation.


What is a Scaled Agile Framework (SAFe) and How Does it Help with Complex Software Development?

What is a Scaled Agile Framework (SAFe) and How Does it Help with Complex Software Development?

What is a Scaled Agile Framework?

Scaled Agile Framework, or SAFe for short, is a robust framework for managing significant software development projects. It provides guidance on how to organize tasks, manage risk, improve predictability, and maintain the benefits of Agile development.

The SAFe methodology can be used to organize and coordinate large-scale software development projects and is a comprehensive structure that provides guidelines for scaling Agile development methods — from modest, single-team projects to larger, multi-team ones.

SAFe offers a scalable and adaptable approach to task planning and management that reduces risk, boosts predictability, and takes advantage of Agile development’s benefits. The SAFe techniques, roles, and artifacts provide guidance on how to manage dependencies, align teams, and consistently deliver value while enabling teams to work together under a shared framework and language.

SAFe’s essential elements include:

  • Agile Teams: SAFe describes how Agile teams should function as well as the tasks and responsibilities of each team member.
  • Program Backlog: A prioritized list of work that serves as a guide for value delivery.
  • Program Increment: Refers to the time-boxed period of time where teams produce value.
  • Solution Train: The task of coming up with a solution falls under the purview of a multidisciplinary group known as the “Solution Train.”
  • Agile Release Trains (ARTs): A collection of Agile teams working together to create a solution.
  • Value Streams: A series of steps that the organization uses for delivering value to customers.
  • Program Increment (PI) Planning: A regularly scheduled, joint planning session that brings teams in the ART come together to organize and plan tasks, and align on vision, roadmap, and cross-team dependencies.

RELATED: The Easiest Ways to Reduce Product Development Expenses in 2023

What kinds of businesses employ a Scaled Agile Framework?

Organizations that create and deliver complex goods, such as software, often employ the Scaled Agile Framework (SAFe) — particularly in settings where there are many teams, large-scale projects, and numerous stakeholders. SAFe is especially helpful for enterprises that need to manage dependencies, coordinate work across various teams, and consistently deliver value. Organizations across a range of sectors, including technology, finance, healthcare, government, and more, use SAFe.

Due to the fact that SAFe offers a flexible and scalable approach to Agile development, it is employed by both large corporations and smaller companies. The framework is a popular option for firms looking for a complete approach to managing large-scale software development projects, since it can be customized to match the unique demands of each organization.

Do companies have access to software platforms and technologies that facilitate the use of a Scaled Agile Framework in development?

Yes, there are several software platforms and solutions that support Scaled Agile Framework development for businesses. These technologies offer support for a number of SAFe-related features, including as backlog management, value stream mapping, continuous delivery, Agile planning and tracking, and more.

Two popular platforms that support SAFe include:

  •  Jira Software: This popular Agile project management tool offers features like backlog management and Agile boards.
  • Azure DevOps (formerly Visual Studio Team Services): A Microsoft solution that offers support for Agile project management, continuous delivery, and more.

These are only a couple of the many tools that businesses using SAFe have access to. The best tool for a company depends on its individual requirements and preferences, and many companies decide to utilize a variety of tools to support various SAFe implementation components.

RELATED: Research Notes: Traceability Score™

How Can Jama Connect® Help Organizations Adopt a Scaled Agile Framework?

Jama Connect® is a product, systems, and software development platform that can help organizations adopt and implement a Scaled Agile Framework (SAFe), and provides support for various aspects of SAFe, including:

  • Requirements Management: Jama Connect provides a centralized repository for managing requirements and product backlogs, helping organizations align work with their product strategy and vision.
  • Traceability: Jama Connect manages requirements with Live Traceability™ across the end-to-end development process — from requirements to design and implementation — helping organizations manage dependencies and ensure that work is aligned with their goals.
  • Collaboration: Jama Connect provides a platform for teams to collaborate on product development, improving communication and reducing risk.
  • Quality Assurance: Jama Connect offers a platform for managing quality assurance operations, including as test case management, test execution, and defect tracking, to assist businesses make sure that their products fulfill consumer needs.
  • Reporting: Jama Connect offers analytics and reporting tools that help businesses assess their progress, spot potential dangers, and make wise decisions.

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

Jama Connect integrates with other tools like Jira and Azure DevOps to offer a complete SAFe solution for businesses. Additionally, due to the platform’s adaptability and configuration options, companies can tailor Jama Connect to their organization’s unique needs and operational procedures.

Jama Connect is the #1 Industry-leading software for requirements management and Live Traceability™. This robust, but easy-to-use platform enables collaboration, quality assurance, and reporting for enterprises looking to build a Scaled Agile Framework (SAFe) and can help businesses boost productivity, generate better products more quickly, and optimize their product development processes.

In conclusion, large-scale software development projects can be managed and coordinated using the Scaled Agile Framework (SAFe) approach. It is a thorough framework that offers instructions on how to scale Agile development processes from small, single-team projects to big, multi-team ones. While maintaining the advantages of Agile development, it offers a scalable and adaptable way to plan and manage work, lowering risk and raising predictability.

To learn how Jama Connect can help your organization adopt a Scaled Agile Framework, contact us to speak with one of our experts!

Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Karrie Sundbom and Josh Turpen.

2023 Predictions for Aerospace & Defense Product Development

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.

2023 Predictions for Product & Systems Development Teams

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?

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 (now known as Vantage Medtech), 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.

https://resources.jamasoftware.com/blog/a-guide-to-good-systems-engineering-practices-the-basics-and-beyond

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.