Tag Archive for: systems engineering Page 2

Tag Archive for: systems engineering

Incorporating Risk Traceability into Manufacturing Production Software and Preparing for the Transition from CSV to CSA

Incorporating Risk Traceability into Manufacturing Production Software and Preparing for the Transition from CSV to CSA

Intro

Over the years, the burden of Computer Systems Validation (CSV) has resulted in medical device manufacturers avoiding implementation of automated manufacturing production systems or upgrading long-outdated versions of software. As part of the FDA’s ‘Case for Quality’ initiative in 2011 to study quality best practice in medical device manufacturing, the FDA found that the burden of compliance, such what is expected for Computer Systems Validation (CSV), deterred technology investments and as a result, inhibited quality best-practice.

As an outcome, the FDA is expected to release a draft guidance in 2022 that outlines their new approach of Computer Software Assurance (CSA) for Production and Quality System Software. The goal is to improve software quality by focusing on the software’s impact to patient safety, impact to product quality, and impact to quality system integrity. Using a risk-based approach, manufacturers can spend more time testing to ensure software meets its intended use, instead of ensuring test protocols and reports are fully scripted are error free.

As the key to right-sizing CSA activities is based on risk, managing risk, and risk traceability and incorporating is a key activity. And there’s no need to wait for the publication of the FDA CSA draft guidance, medical device manufacturers can incorporate these risk management and traceability practices now in their CSV activities.

Keep reading below for best practices on how to extend risk management and risk traceability from the medical device development to your manufacturing production software used to manufacture your devices.

Main Points for How

Consider the product risks and hazards

Even though we are discussing manufacturing production software and the software used on manufacturing equipment, the first step is to consider the product risks and hazards. Start with your master list of hazards, hazardous situations, and associated harms developed during medical device development and determine where and how failures in the manufacturing production software and production equipment can result in those risks and hazards. These are the areas to consider as the highest risks to control, mitigate, and validate.

Next, perform additional risk analysis from the lens of the environment and manufacturing personnel that will operate said equipment and software. It is important to also protect the environment and prevent injury and harm to those interacting with the equipment. You don’t want the unintended release of hazardous chemical reagents or equipment fires that could have been prevented with built-in high temperature shut-down feature.

RELATED: Managing Complexity in Systems Engineering for Product Development with Live Traceability

Create manufacturing production software intended uses and requirements

Just as one determines the intended use and design input requirements of a medical device, the same is to be done for the manufacturing production software and equipment. Incorporate the necessary features as manufacturing requirements (analogous to the design inputs of your medical device) that address the risks identified in the previous step.

One example is based on risk of the product and demonstrates how risk traces from the development of the medical device. Consider the design of a semi-automated assembly machine for a drug-delivery device. The machine aligns and press-fits together two plastic injection-molded halves of the delivery sub-assembly. One of the main product associated risks is ensuring proper flow efficiency to ensure the proper amount of drug is delivered correctly and to the proper anatomical location.

In this case the risk traceability and translation to the assembly machine design inputs is:

RELATED: Application of Risk Analysis Techniques in Jama Connect® to Satisfy ISO 14971

Perform software testing and equipment validation based on risk

Once ready to test the production equipment software and perform equipment validation, incorporate, you guessed it, risk. All manufacturing requirements then need to be verified, however, scale the amount and type of testing for each manufacturing requirement based on the risk. Aspects of the software and equipment that are of high risk, such as preventing severe harm to operators, or the end users and patients of the medical device will have more testing and documentation than those of lower risk.

Document risk traceability of testing and equipment validation

Just as documenting risk traceability for medical device is important, it’s also important for manufacturing production software and equipment. Using a tool like Jama Connect® makes it easy to link your master list of hazards, hazardous situations, and harms to your manufacturing requirements for manufacturing production software and equipment. This increases consistency and efficiency in the risk analysis and prioritizing efforts on where it matters for patient and operator safety. The interface of Jama Connect® also makes the traceability and documentation of the associated testing and validation easy to visualize, alerting teams to gaps and incomplete testing.

Closing

Extending risk traceability from your medical device development to your manufacturing production software and equipment brings focus to what can impact patient safety and scales the testing and validation work appropriately. Incorporate risk and you’ll also be well on your way for the upcoming FDA transition from CSV to CSA.


Managing Complexity in Systems Engineering for Product Development with Live Traceability

Editor’s Note: This blog was originally published through IEEE Innovation at Work, “Managing Complexity in Systems Engineering for Product Development with Live Traceability,” by author Nikhil Rai, IEEE Senior Member, Senior Director of Product and Solutions Marketing at Jama Software.

Systems Engineering for Product Development with Live Traceability

Complexity of Product Development is Exploding

In today’s world, technological innovations across embedded systems, the Internet of Things (IoT), and artificial intelligence (AI) are aggressively pushing the envelope on product complexity and accelerating digital transformation. The next generation of autonomous cars, electric vehicles, robots, and space shuttles are all complex systems that need to seamlessly interact with multiple layers of software, hardware, and humans across different environments.

Because complex technology products require intricate interfaces with various systems or sub systems, there is an inherent challenge of coordinating the multiple development teams, who are often geographically spread across the world. Furthermore, large teams typically work on different stages of product development within their own silos. The different development tools, architecture, and IT environments used across various teams and organizations can significantly add to the challenges of developing new technologies.

Manufacturing sectors will reap the AI technology benefits of enhanced monitoring and supply chain optimization. In financial institutions, AI techniques can be used to identify which transactions are likely to be fraudulent. Through AI, the industry could also adopt fast and accurate credit scoring while automating manually intense data management tasks. Disruptions in the transport and logistics realm could include autonomous trucking and delivery on the roads and automated picking in warehouses.

RELATED: Systems Engineers Career Path – How to Elevate

Reality of Today’s Complex Systems Development

Most complex system development starts with defining user needs and requirements, which involves design, software, and hardware teams developing deliverables that ultimately get tested and integrated for delivering the product. Given the disparate nature of these teams, there is an inherent need to optimize and continuously keep track of systems information from concept to development and delivery. However, there is often a gap in terms of how information is consumed across engineering departments, as well as its availability and traceability. The digital thread in engineering today is still a collection of different tools, which means traceability is usually accomplished in a cumbersome and manual fashion via time-consuming meetings and disconnected documents.

Challenges in Traceability

Traceability is a key both to product development and software engineering for tracking the systems development lifecycle. Helpful in achieving regulatory compliance, traceability can also be used within software engineering for running test cases and gaining valuable insights.

While some organizations make it a point to map product development stages and improve traceability to gain these benefits, traceability is often considered after-the-fact by others. This means that once an issue is identified, there is effort required to trace back where the error originally occurred to prevent that same failure from occurring in the future. This approach can cause multiple cost overruns, product delays, and inefficient management of change impacts. Think of addressing a car recall or fixing a complex medical device or industrial equipment— the costs can be enormous. By emphasizing the importance of traceability from the start, organizations can avoid the extra effort and cost associated with implementing it after an error has been made.

RELATED: Requirements Traceability – How to Go Live

Live Traceability™

The solution lies in bringing a practical approach of Live Traceability™ to the systems engineering world. Optimizing and measuring the systems development process with Live Traceability is a crucial competitive advantage that companies can leverage. For any complex product, systems, or software development, the requirements and user needs form the first level of abstraction. Live Traceability can be measured and monitored by using systems requirements as an anchor to manage information used in different stages of the systems development lifecycle.

At Jama Software, we define live requirements traceability as the ability for any engineer at any time to see the most up-to-date and complete upstream and downstream information for any requirement— no matter the stage of systems development or how many siloed tools and teams it spans. Live Traceability of system requirements is required by industry standards to ensure product safety and forms the foundation for digital engineering and model-based systems engineering. This enables the engineering process to be managed through data and its performance improved in real time.

Through better requirements management and a focus on traceability, companies can improve their systems development performance with higher quality products and improved cycle times. The industry is now embracing the idea that to improve engineering efficiency within the systems development process, we need to continuously monitor and measure traceability.


Systems Engineers Career Path – How to Elevate

Systems Engineers Career Path

Most Systems Engineers we speak with have a common perspective on their role within their organization. Systems engineering as a concept is understood and supported by leadership. And, if systems engineering best practices are followed across all engineering disciplines, leadership also acknowledges the benefits the organization can realize. However, leadership will not force change on engineering disciplines (software, hardware, electrical, risk, verification, and validation) to remove barriers to systems engineering best practice adoption. This leaves most Systems Engineers in the challenging position of possessing responsibility for achieving systems engineering benefits without the authority to ensure engineers adopt best practices. 

The good news is that there is a way out of this situation. The first step to elevating your career is to realize that managing the product engineering process through data is the key and that the Systems Engineering role is the natural role to lead this. For most organizations, the product engineering process is the only process in the company that is not managed through data. No one can go to a system and see the status of all product requirements and where development, integration, risk, and testing stand at any point in time. There is no way to manage by exception. There are no alerts that requirements are not covered, test cases are missed or that hardware made a change that now impacts software. Most organizations have come to accept this state of affairs and try to manage the process through endless meetings, emails, and Slack messages.   

Until the product engineering process is manageable through data, Systems Engineers will be stuck in their current trap — endlessly trying to address issues after the fact, holding unwanted meetings, and the uphill battle of trying to persuade changes in behavior. Below is a 3-step approach that Systems Engineers we work with have used to solve this organizational challenge and have thereby elevated their careers. As with any process change, it is best to do it in stages. You can start with the following steps. 

  1. Baseline current process performance 
  2. Build the business case for change to gain support 
  3. Deliver quick wins

RELATED POST: How to Overcome Organizational Barriers to Live Requirements Traceability

Step One | Baseline Current Traceability Performance 

The first step towards moving the organization to manage the product engineering process through data is to baseline current process performance.  The best place to focus the baseline effort is on traceability since it spans the entire product development process, is a data management concept that is understood, enables systems engineering benefits, and is required by industry standards. To ease the baselining effort, we’ve developed a Traceability Diagnostic that you can use to assess your current situation. The Diagnostic inventories traceable data, the systems in which they reside, and your current Traceability Score™. This is a few-hour effort and forms the basis of the business case in step two.

In this no-cost, guided process, we’ll help you:

  • Understand the monetary risk of your current Traceability Debt™
  • Uncover the quantifiable ROI of moving to Live Traceability
  • Develop a clear plan of action, cost, and timing to achieve Live Traceability

To Get Started With Your Free Traceability Diagnostic,  CLICK HERE

Step Two | Build Business Case for Live Traceability™ 

Once you have established a baseline, it is now possible to build a business case for change that will resonate with leadership. Based on your baseline, the Traceability Diagnostic determines the probability of negative product outcomes (defects, delays, rework, cost overruns, etc.) and the magnitude of these events. This quantifies the risk of maintaining the status quo and doing nothing. In addition to the risk reduction potential of Live Traceability, the Diagnostic also calculates the engineering productivity gains from eliminating the need for time-consuming, manual, after-the-fact traceability efforts. 

Step Three | Start with Quick Wins 

Once you have secured support to move forward, it is common to be able to deliver some quick wins to the organization shortly after project kick-off.  The typical place to start is the painful and time-consuming after-the-fact traceability efforts.  For example, continuous syncing between requirements and software development task management in Jira or Azure DevOps can be set up quickly to automate traceability from requirements to user stories, eliminating a large source of risk and manual, after-the-fact traceability effort. Once quick wins are shown, organizational momentum increases even further and puts you on the success path to begin managing the product engineering process through data.     

Clients of ours that have taken this approach have received significant recognition, been promoted into roles with greater leadership, and have increased their external visibility through speaking engagements. Live Traceability is a unique opportunity to elevate one’s career. Don’t miss the chance. 

    


Adopting MBSE Part II: What Does It Mean to Practice SE From a Data-Centric Perspective?

This is Part 2 of a blog series covering a whitepaper titled,The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit these links for the rest of this series: Part I, Part III, and Part IV.

Adopting MBSE

What does it mean to practice SE from a data-centric perspective?

Successfully adopting MBSE and moving toward a data-centric practice of SE is much more than just acquiring and using a specific tool, set of tools, or focusing on the use of a specific type of model. As stated previously, MBSE is not just about the development of SysML or other language-based models nor just practicing model-based design. MBSE is itself made up of puzzle pieces, all of which contribute to the successful adoption of MBSE. To be successful, the following ten areas of capability associated with data-centricity must be addressed.

01: Holistic Product Development

A key tenet of data-centricity is taking a holistic view of product development and managing data and information within an integrated/federated environment. The focus is on multidiscipline, collaborative, project teams (e.g., integrated product teams). Many organizations still operate in organizational silos, with team members’ loyalty toward their specific silo rather than to the project team. When issues occur, the tendency is to blame those in other silos. Each silo often has its own processes, specific toolsets, data, and artifacts. Often the data and information are generated independently from those in other silos and are not in a form to enable sharing. This can result in inconsistencies, correctness, completeness, and currency issues of the data maintained in these artifacts. When moving toward data-centricity, organizations must have a holistic view of product development, minimizing the silos, encouraging collaboration, and improving communications not only between team members but between different tools used to generate and maintain data and information. Rather than treating Systems Engineering separate from Project Management (PM), projects must integrate both sets of functions such that there is a single project team that does both functions.

02: Manage Product Development Across the Lifecycle

Rather than having tools that are specific to a given organizational silo, a key characteristic of data centricity it that related data and information that represents lifecycle activities and associated artifacts can be linked resulting in “digital threads” that link related information together across the product lifecycle. This linkage enables project team members to work collaboratively and establish traceability between needs, design input requirements, system analysis artifacts, diagrams, models, architecture, design, system verification artifacts, and system validation artifacts. Traceability aids in change impact assessment across the product lifecycle helping ensure completeness, correctness, consistency, and currency of the data and information and resulting artifacts.

03: Enterprise Level Data and Governance Policy, Processes, & Procedures

Because of the dependence of not just the project teams, but the overall organization on electronic forms of data and information and increasing threats associated with the security of this data and information; enterprise-level policies, processes, and procedures concerning data governance and information management must be defined, implemented, and enforced.

04: Project Level Data and Information Management

Within the context of the enterprise-level data governance and information policies, each project must include their specific implementation of these policies within their Project Management Plan (PMP) and Systems Engineering Management Plan (SEMP). Because of the importance of managing the project’s data and information, the project is encouraged to develop and enforce a project-level Information Management Plan (IMP). Other supporting plans (e.g., requirements management plan) need to comply with the data management policies within the higher-level plans for both the project and enterprise.

RELATED POST: The Real Intent of Model-Based Systems Engineering

05: Master Ontology

Terminology and language are key to successful communications not only between team members but between tools. For a given enterprise, an enterprise-level ontology (data dictionary and glossary) must be developed to clearly define specific terminology and relationships of various terms used within the organization and the project. This is critical when there are product lines, multiple project teams, and the need to share data and information between current projects as well as reuse data and information for future projects. Within the enterprise-level ontology, individual project teams can define their project-specific ontology consistent with the enterprise-level ontology.

06: Master Schema

Here the word “schema” is used to describe how the data and information are organized and managed within individual tools and associated databases. It includes the naming of individual data and information items, defining relationships between data items, and the import and export of data and information. From both an enterprise and project perspective it is important to define a master schema that the SE and PM tools within their toolset are compliant in order to enable data integration, shareability, and reuse.

07: Use of Attributes and Associated Measures

Data centricity enables the project to define and use attributes that can be used to manage project activities across all system life cycle stages. For needs and requirements, attributes can include rationale, priority, criticality, source, owner, traceability, risk, maturity of needs definition, needs and requirements definition status, design implementation, system verification, and system validation. Attributes can be defined to aid in reusability and product line management. Attributes can also be associated with key measures defined by stakeholders within their goals and objectives. These measures include key performance indicators (KPI), measures of suitability (MOS), measures of effectiveness (MOE), measures of performance (MOP), key performance measures KPP), technical performance measures (TPM), and leading indicators (LI). Data representing these measures and attributes can be used within the SE and PM tools to generate reports, dashboards, etc. which are used to better manage the project and system engineering processes providing managers near real-time status information and enabling them to identify and correct possible issues before they become problems.

08: Configuration Management

Adopting data-centricity, the project’s artifacts and underlying data and information are developed, analyzed, and managed holistically within the data and information model. Because the data and information are managed within the project’s data and information model, this model represents a single source of truth (SSoT) for the project. Rather than configuration control of each individual artifact represented by the data and information in the model, the project team can configuration control the model which represents the baseline state of the artifacts represented by the data and information in the model at any given time. “Visualizations” of the data and information in the form of the various artifacts represent the baseline version of that artifact. Even when these visualizations are extracted as reports, the SSoT is still the data and information model from which they were generated.

Note: for many organizations, this is often their biggest challenge in that it requires the organization to redefine its concept of configuration management. However, as stated previously, configuration management of individual artifacts requires significant overhead in both cost and time to individually configuration manage individual documents as compared to managing the data and information model that is representative of moving towards a data-centric practice of SE and PM.

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

09: Systems Engineering (SE) Tool Set

Data centricity requires projects to move beyond the use of common office applications: word processing, spreadsheets, presentations, basic drawing and diagraming tools, and requirement only management tools to define, analyze, record, and manage needs and requirements and other SE artifacts. Rather, projects must transform their SE process such that SE artifacts are developed using SE tools that are fully compliant with interoperability and data sharing standards, are consistent with the enterprise and project ontology, stores the data and information consistent with the project’s master schema, and allows linking of data and information across lifecycle activities and resulting artifacts. This data and information must be managed in a form that is shareable between the SE tools within the project’s toolset as well as shareable with the project’s PM tools. When selecting specific SE tools to be included in the project’s toolset, it is important that the project determine the types of information and methods of analysis that are needed based on their specific product line, culture, and workforce.

10: Project Management (PM) Tool Set

Data centricity also requires projects to move beyond the use of common office applications for project management e.g., budgeting, scheduling, cost management, risk management). Rather, projects must transform their PM process such that most of the PM artifacts are being developed using PM tools that are fully compliant with interoperability and data sharing standards, are consistent with the enterprise and project ontology, stores the data and information consistent with the project’s master schema, and allows linking of data and information across lifecycle activities and resulting artifacts. This data and information must be managed in a form that is shareable between the PM tools within the project’s toolset as well as shareable with the project’s SE tools. For example, Work Breakdown Structures (WBS) can be linked to Product Breakdown Structures (PBS) and physical architectures to enable management of budgets, schedules, resources, and risks associated with each system and system element within the product physical architecture.

Visit these links for the rest of this series: Part I, Part III, and Part IV.

To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE

Adopting MBSE Part I: Key Factors Associated with Successful MBSE Adoption
This is Part I of a blog series covering a whitepaper titled, The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit these links for the rest of this series: Part II, Part III, and Part IV.

Introduction 

In a previous paper, we discussed key questions concerning Model-based Systems Engineering (MBSE) including what MBSE is, its true intent, why organizations should adopt MBSE, and the benefits. If you haven’t read that paper, it’s worth taking a look. 

We made the point that the goal of an organization when adopting MBSE, is to move from a document-centric to a data-centric practice of Systems Engineering (SE) to realize the real intent of MBSE which is to develop, maintain, and manage a data and information model of the system being developed — along with a model of all the system life cycle process activities, resulting in artifacts, and their underlying data and information. 

This paper will go into more detail as to key factors associated with successfully adopting MBSE, what it means to practice SE from a data-centric perspective, and provide a methodology to define a road map tailored to your organization resulting in the successful adoption of MBSE. 

RELATED POST: The Real Intent of Model-Based Systems Engineering

Key factors associated with successfully adopting MBSE 

Sadly, the attempts of many organizations to successfully adopt MBSE often end in failure. The process of adopting innovative technology like MBSE and moving toward a data-centric practice of SE can be considered to be a project in its own right. There have been numerous studies and reports concerning factors of why projects fail, and factors associated with projects that succeed. When adopting MBSE, these factors must be considered. Organizations that are able to successfully adopt MBSE and move to a data-centric practice of SE address the following key factors: 

01 – Getting Corporate Level Management Buy-In and Support – Success Starts at the Top! 

In an earlier paper, we discussed issues associated with a document-centric approach to product development of today’s increasingly complex, software-centric products along with the benefits of adopting MBSE from a data-centric perspective to address these issues. There must be a project champion that can clearly communicate these issues and benefits at the corporate level in order to get buy-in across the organization. 

A key consideration when getting this buy-in is how these issues and benefits are communicated. The adage “know your audience” is important. A common mistake when approaching higher-level management is using terminology that does not address their needs in a language they understand. When getting buy-in concerning the company adopting MBSE, you must clearly communicate to them what MBSE is and how the organization will benefit in terms of outcomes they can relate to. Giving them a demonstration of a specific tool using a lot of technical jargon can result in them quickly losing interest. They are interested intangible outcomes of a proposed solution that addresses business-related issues (problems): less overhead, decreased time to market, higher quality, decreases in post-launch issues, fewer issues associated with a product being approved for use, increased profits, rising stock prices, and a growing company. They want to understand how adopting MBSE will result in these types of outcomes. 

02 – Forming a Dedicated Project Team 

Rather than leaving it up to individual project teams to each attempt to adopt MBSE, a corporate level dedicated MBSE Implementation Project Team (IPT) is needed. For smaller organizations and startups this IPT might be a single person. MBSE is just one puzzle piece in the larger set of organizational puzzle pieces. To be successful, the larger, integrated puzzle must be considered to ensure the MBSE puzzle piece will fit. Other puzzle pieces include data governance policies, information management plan procedures and work instructions, information technology (IT) infrastructure (networks, internet, clouds, applications, computing devices, etc.), the product line, product development processes, procurement processes, company culture, workforce, etc. A dedicated project team can deal with possible issues in all these areas from a corporate, holistic perspective across organizational silos enabling a successful adoption of MBSE, helping to ensure the MBSE puzzle piece can be integrated within the overall corporate puzzle. 

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

03 – Involving Key Stakeholders 

The various stakeholders involved in adopting MBSE must be included. These stakeholders must not only include the users, but other stakeholders that will be affected by the adoption of MBSE including those that will benefit, those involved in the activities required to adopt MBSE, and those from enabling and supporting organizations. Referring back to the puzzle analogy, stakeholders must be included that represent each of the above-listed puzzle pieces. Each stakeholder has expectations that must be addressed by the project team along with key drivers and constraints a successful project must consider in order to achieve a successful outcome. 

04 – Defining The Problem, Opportunity, Outcomes, Needs, and Requirements at the Beginning of the Project 

The project team and stakeholders at all levels of the organization must be aligned to a common understanding of the problem/opportunity that is driving the adoption of MBSE, to a common mission statement, goals, objectives, clear outcomes, needs, and requirements. Like any other project, these must be defined and agreed to from the beginning so that there is a clear roadmap to success and well-defined outcomes against which success can be measured. 

05 – Understanding the “Goldilocks Principle” 

The Goldilocks principle is about doing what is “just right” – not too little, not too much. When adopting MBSE and moving towards a data-centric practice of SE, the project team must understand the needs of the organization, what it means to practice SE from a data-centric perspective, and develop a practical and feasible roadmap. Delivering an MBSE capability that is too little can result in stakeholder expectations not being met, disappointment, and a failure of project teams to successfully adopt MBSE. Going overboard and implementing more than is needed can be overwhelming, turning people off to the concept and again a failure of project teams to adopt MBSE. 

This last point is especially important. “Just right” must be defined from a user perspective. The users are the product development project team members who will be conducting their project based on the processes and tools provided that will enable them to adopt MBSE for their project and move to developing their products from a data-centric perspective. They have expectations concerning being able to be more productive and effective. Meaning the processes and tools provided should not be viewed as things they have to do and use in addition to their job – resulting in more work; rather processes and tools they can follow and use that are an integral part of how they do their job – resulting in less work, a higher quality product with a shorter time to market. The new processes and tools enable them to deliver winning products: those that meet the needs of their customers, within budget and schedule, with the required quality. 

From a user perspective the following attributes must be addressed within the processes defined and tools selected for use: 

  • Full functionality; does what is needed, nor more, no less
  • Intuitive; easy to learn and use
  • Easy and fast to implement
  • Enable collaboration between team members, no matter their geolocation
  • Enable traceability of data, information, and artifacts across the system lifecycle
  • Enable change impact assessment across the system lifecycle
  • Reduces the time to define and manage needs and requirements
  • Supports verification and validation planning and execution
  • Tailorable to the organization’s product line, work instructions, and workflow
  • Helps ensure compliance with standards and regulations
  • Helps manage risk across the lifecycle
  • Enables management to track project status across the lifecycle 

Visit these links for the rest of this series: Part II, Part III, and Part IV.

To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE


MBSE is Not SysMLWith the trend of organizations practicing Systems Engineering to move towards what is referred to as “Model-based Systems Engineering” (MBSE), there are various perspectives as to just what is meant by MBSE. Similar to the old story of the blind men and the elephant, MBSE cannot be effectively practiced when viewed from just one perspective (requirements, models, patterns, standards, industry specific application, etc.). To successfully practice MBSE, wise systems engineers recognize and use each perspective as appropriate to their specific needs. Based on these needs, they choose the appropriate capabilities, tools, and visualizations that will meet their needs. One size doesn’t fit all.

The degree to which the data and information is captured and managed is driven by the needs of the organization and projects from a business and technical perspective based on the size and complexity of their systems, their product line, culture, processes, workforce, their diversity and complexity of supply chains, and types of engineering information that comprises a technical baseline for their system of interest.

SysML and other language-based modeling tools

MBSE is a concept that is maturing and means different things to different people.  To some practitioners, MBSE is equated to the use of SysML and other language-based modeling tools. With these tools, practitioners can develop detailed analytical, behavior, and architectural models of a system, with a primary focus of functionality, performance, and interactions between various entities defined to be part of the system being modeled. These types of models are useful tools for system analysis, developing simulations, and creating what is referred to as a “digital twin”.

To others, what they are calling MBSE is really Model-based Design (MBD). MBD design starts with a set of requirements and using various language-based modeling tools to architect and design a system, develop simulations to assess the behavior of the system, and then develop a set of design output specifications to which the system is built or coded. Often the MBD activities are completed in a silo separate from the other SE lifecycle process activities.

MBSE is much more than SysML!

The above language-based modeling approaches do not address the true intent of MBSE. While these capabilities can be useful, MBSE is much more than using language-based modeling tool to develop analytical, logical, behavioral, and architectural models.

The goal of an organization, when adopting MBSE, is to move from a document-centric to a data-centric practice of Systems Engineering (SE) so as to realize the real intent of MBSE which is to develop, maintain, and manage a data and information model of the system being developed along with a model of all the system life cycle process activities, resulting artifacts, and their underlying data and information.

MBSE is not really about any particular type of model or visualization of data and information – whether that be a model, diagram, report, document, sets of needs, or sets of requirements – but is about the underlying data and information model that enables consistency across the data and information that represents the various models and visualizations.

The data and information model that must be developed should represent SE artifacts generated during the product development process activities across all lifecycle stages. Information associated with the elicitation of stakeholder needs and requirements, lifecycle concepts definition, analysis, and maturation, deriving an integrated set of textual needs, transforming those needs into sets of textual design input requirements, verification the system meets those requirements, and validation that the system meets the needs must also be captured within the data and information model. In addition, relationships and dependencies of the individual data items must be captured (traceability) in order to help determine and ensure consistency across all lifecycle stages, prove compliance with standards and regulations, as well as help assess the impact of changes made to any of the data items across all lifecycle stages.

Can my organization adopt MBSE without using SysML or other language-based tools?

Sadly, there are many organizations that have a misconception concerning what the true intent of MBSE is – as a result they think that MBSE is not for them.

In a recent conversation with a system engineer, I was told that her organization was not going to adopt MBSE because they don’t see the utility of developing complex SysML models of their products. In addition, she noted that to do so would require a change in how their managers and engineers think based on the SysML standard as to how to construct models and the specific terminology used.  To them SysML modeling is not intuitive, has a large learning curve, and has little apparent utility and return on investment – for their organization, especially for their product line that has a minimum amount of software and complexity.

My response to her was: MBSE is not SysML!

I told her what the true intent of MBSE is to practice systems engineering with a data-centric perspective, establishing the capability to capture, manage, access data, and manage the interrelationships between SE work products can be accomplished through a variety of methodologies, which range from the establishment of a single relational database to a virtually integrated, but distributed, database by means of a federation (or data map/index) of disparate data sources.

The resulting data and information model can be captured using a variety of SE tools and applications. To effectively manage our ever increasing complex, systems there are benefits to managing this underlying data and information in such a way it can be shared across the system life cycle process activities, shared between the various SE tools used to create and manage this data and information, and shared between organizations involved in the development and operations of the system of interest. This sharing will help ensure correctness, consistency, and completeness of the data and information typical of our ever increasingly complex systems as well as enable collaboration between not only the project team members, but also external stakeholders involved in the development of the system.

Parting Thoughts

The answer to the question: “Can my organization adopt MBSE without using SysML or other language-based tools?” is YES!

Since one size doesn’t fit all, an organization must assess their needs and produce an MBSE solution that best fits its domain, product line (degree of complexity), and culture. As a minimum, they need to establish a capability to define and manage needs, requirements, verification, and validation across the system lifecycle.  These capabilities will allow the organization to build a data and information model of their products and systems engineering process activities and artifacts.

Based on these needs and desired capabilities, the organization can choose the appropriate SE toolset, update their processes, and train their people in these tools and processes.

Stay tuned for more to come from Lou Wheatcraft in the coming months. 


Getting Started with Model-Based Systems Engineering (MBSE)

For companies building complex systems whose stakeholders come from diverse engineering and business disciplines and need to have very precise and efficient communications, Jama Connect provides a collaborative, 100% web-based MBSE platform and a proven systems engineering approach to product development. Jama Connect provides a path to companies embracing MBSE where the application of collaboration, modeling, and methods reduces time and effort across the lifecycle. We call that path Jama Connect for Traceable MBSE™. 

Jama Connect for Traceable MBSE is a single platform that combines requirements, architectures, behaviors, and V&V into a single model of the system by applying structure for the data; rules for the data; and a consistent interface language between parts of the system. A Jama Connect model provides engineers, project managers, business analysts, or any stakeholder, an organized way to address all aspects of the system consistently with the assurance of completeness. 

MBSE Defined by Industry 

The International Council on Systems Engineering (INCOSE) describes MBSE as the “formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing through-out development and later lifecycle phases.”  

NASA says MBSE “involves applying software-based tools to capture systems engineering evidence—typically called “artifacts”—in a systematic, disciplined way that allows people to manage complexity while communicating effectively across the life cycle of a system. 

What is a model? Don’t be fooled. 

It is a myth that a system model can only be created in a UML or SysML tool. Models can be expressed texturally, mathematically, visually, or physically and are meant to assist in helping people look at problems from different directions. Jama Connect represents a model as a project containing textural data items, views, graphical diagrams, and collaboration content.  

NASA’s definition provides a good deal of information, but they don’t even use the word “model” in their description. Lenny Delligatti, one of the most respected MBSE experts in the world wrote that, “A modeling method is something like a road map; it’s a documented set of design tasks that a modeling team performs to create a system model. More precisely, it’s a documented set of design tasks that ensures that everyone on the team is building the system model consistently and working toward a common end point. Without such guidance, there will be wide variance in the breadth, depth, and fidelity that each member of the team builds into the system model.”  

For example, a switch in a system is expecting the command “On” but for some reason receives the command “Start.” The switch will not function. The “On” and “Start” is the communication language and must be consistent. 

What in simple terms is a model then? Wikipedia tells us that a “model is an informative representation of an object, person or system” and INCOSE defines a model as “a simplified version of a concept, phenomenon, relationship, structure or system.”  

Before the invention of SysML, we used to use a document called an “Interface Control Document (ICD)” to describe the syntax of interfaces between different parts of a system, often physical. While essential, the ICD lacked the ability to describe scenarios which the interfaces would be used for. While a SysML model allows for communication of scenarios to be documented, it often lacks the ability to communicate the depth of requirement needed to describe the core workings of each part. This puts a heavy onus on the verification needed to ensure a part on its own was working as intended.   

While SysML is a wonderful language to represent abstractions and there are some fine tools out there that let you do some powerful things (I want to say something different here); it is still immature in the core aspects of systems engineering as it relates to communication, cross-domain collaboration, project management including cost and schedule, and oversight of verification and validation activities to name a few.  

RELATED: MBSE Made Easy – Overcoming the Organizational Challenges 

Jama Connect for Traceable MBSE™ – The Nuts and Bolts 

Jama Connect for Traceable MBSE™MBSE in simplest terms is a framework for problem solving and system expression. In traditional systems engineering the domains of requirements, architectures, V&V and behavior are recorded and analyzed in a series of documents or data structures with loosely connected affiliations. Our Traceable MBSE combines these four domains into a single model of the system by applying: structure for the data; rules for the data; and a consistent interface language between parts of the system, which in combination we at Jama Software call a “framework.” The framework provides engineers, project managers, business analysts, or any stakeholder, an organized way to address all aspects of the system consistently with the assurance of completeness. 

The Jama Connect for Traceable MBSE framework takes requirements, architectures, behaviors, and V&V and forms their data into a query-able mesh. As development progresses the mesh becomes more stitched together. A built-in ruleset that uses a consistent language, constrains users to create the correct associations between the data elements. The framework’s ruleset eliminates risk that manual methods or tools lacking these constraints introduce. Jama Connect for Traceable MBSE also supports leveling – representation of system decomposition within a model. Each successive level will follow the same consistent ruleset. 

Visualization is an important part of Jama Connect for Traceable MBSE and plays a major role in communication of information and ideas. Data is easily visualized in an easy to navigate hierarchal tree view. This view not only displays the content of the data but also how the elements are tied to each other. These structures can be represented visually as a series of diagrams within the model.  

Requirements 

Requirements are typically the first data elements to be worked on in the model. Jama Connect for Traceable MBSE’s flexibility gives users the ability to define unlimited levels of requirements – even those considered outside the “system” level. A Need Requirement which is an input to the systems engineering process, might consist of multiple types such as: user needs, ConOPS, business requirements, mission objectives, goals, regulatory requirements, or even constraints to name a few. A needs analysis is performed to flesh out those requirements which are human-centric. Systems engineers will analyze all the broad and at times abstract needs and then refine them into system level requirements that are representative of the system and might describe all the functions that the system shall deliver as well as non-functional characteristics such as performance or reliability of the system.  

In Jama Connect each need and system requirement is captured as a unique entity with its own ID. As a single entity it can then be managed, version controlled, and linked to other entities. When using Jama Connect for Traceable MBSE framework, it provides mechanisms that keep needs and system requirements appropriately leveled and describe how they are linked to each other. This link itself also has a name and is called “derivedReq” which is similar terminology used in the SysML language. 

Behaviors 

Behaviors assist the systems engineer in identifying the functions, sub-functions, and interactions that the system performs. Behaviors can be elicited from needs and requirements through techniques such as use cases, activities, states, interactions, sequences and more. Behaviors are most often in the form of a verb (ex: regulate voltage, make deposit, heat water, charge controller, brake…). Capturing behaviors adds value because they help explain how the system will work and sometimes more importantly, what could go wrong. Behavior can assist in establishing the cost and complexity of the system. Functions can be analyzed and become a deciding factor for which requirements are then used to build the system.  

Jama Connect for Traceable MBSE

In Jama Connect behaviors can be richly annotated so one can capture the full reasoning. This is extremely useful to stakeholders that are not necessarily modelers yet need this information to make informed decisions.  

Architecture 

Application of MBSE is not complete without tying in architectures and making them be a central point of data. Architectures can be defined to conceptually represent functions of the system, structure of the system to subsystems, physical components of the system, or even behaviors of the system. An architecture is organized so that its own structure conveys meaning and relationships between its members. In Jama Connect, architecture objects can be managed as discrete elements where relationships to other data such as requirements can be made. It is also possible to create diagram to illustrate the relationships between the elements. 

Jama Connect for Traceable MBSE

V&V

The verification and validation of the model and its entities within it is the last major domain for MBSE. Any element defined within the model can be verified or validated through means of analysis alone, review, trace demonstration, or even by test execution collecting pass/fail status. An MBSE model  

Jama Connect for Traceable MBSE tests and validates system characteristics early with engineers and stakeholders for fast feedback on design decisions and phase it is believed that this will: 

  • Predict performance 
  • Verify design choices 
  • Meet stakeholder expectations 
  • Avoid failures 
  • Reduce risk 
Visualization 

Visualizing the model is an integral part of MBSE. As maturity of stakeholder’s fluency in MBSE increases, reliance on heavy text in some areas will decline. Jama Connect facilitates the best of both worlds by providing fully textural representations of data as well as diagrams that can easily be annotated to describe the purpose behind the “line” the connection between two objects.  

Jama Connect for Traceable MBSE

Why Jama Connect for Traceable MBSE? 

The inefficiency of non-integrated data leads to wrong decisions. When MBSE is done properly, the result is an overall reduction of development risks. Jama Connect for Traceable MBSE provides a flexible framework that is 100% web browser based for capturing and communicating the model to all stakeholders. The model can be queried programmatically to surface up gaps in the model, display progress information, and be validated against the rules of the framework. These rules enforce users to create and relate data in a consistent way. Jama Connect for Traceable MBSE gives users easy graphical and textural views of information in real time and is structurally SysML ready if mature organizations wish to integrate Jama with these specialized tools. Most importantly, users do not need lengthy indoctrination into the semantics of modeling which is required for modeling tools. Jama Connect as a data-centric tool, does not have this barrier and so is much easier for every stakeholder to adopt.  

MBSE Tool Maturity – Where does your organization stand?My initial intention for this blog was to talk about what I describe as MBSE tool maturity levels. And I will surely get around to those levels. But first I think it is important to draw attention to the definitions of MBSE that experts use and offer some observations that might be helpful to those who are beginning their own MBSE initiatives.

What is MBSE?

The International Council on Systems Engineering (INCOSE) describes MBSE as the “formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing through-out development and later lifecycle phases.” This is simple enough to digest and the only noticeable difference between it at their definition of systems engineering is the reference to “formalized application of modeling.” They do not however, define what “modeling” means.

NASA says MBSE “involves applying software-based tools to capture systems engineering evidence — typically called “artifacts” — in a systematic, disciplined way that allows people to manage complexity while communicating effectively across the life cycle of a system.

  • MBSE is to perform systems engineering – connects system relationships
  • Controlling system configurations
  • Communicates an overall system picture accessible to all
  • Makes it easier to integrate disparate material
  • Ensures everyone is working on the same up to date material at all times
  • Eliminates problems with version control

RELATED: MBSE Made Easy – Overcoming the Organizational Challenges 

What is a Model?

NASA’s definition certainly provides a good deal of information, but they don’t even use the word “model” in their description. Lenny Delligatti, one of the most respected MBSE experts in the world wrote that, “A modeling method is something like a road map; it’s a documented set of design tasks that a modeling team performs to create a system model. More precisely, it’s a documented set of design tasks that ensures that everyone on the team is building the system model consistently and working toward a common end point. Without such guidance, there will be wide variance in the breadth, depth, and fidelity that each member of the team builds into the system model.” What in simple terms is a model then? Wikipedia tells us that a “model is an informative representation of an object, person or system.” These definitions are super informative.

An observation I have is that organizations instantly equate MBSE with the use of a SysML tool. The experts tell us however, that MBSE is the combination of methods to create a representation. None of them say that to perform MBSE one must adopt a graphical modeling tool. There are many different methods to create models/representations. Some are graphical and some are textural. At the heart of MBSE is the drive to move from static documents (Word and Excel) into an information-based paradigm. The table below eloquently articulates the differences and standout benefits of using an MBSE approach.

MBSE table

Table source: Laura Hart, Lockheed Martin

MBSE Tool Maturity Levels

There are certainly many organizations that are still performing systems engineering only using documents. For the rest, there are a plethora of tools in the ecosystem used to create models including tools that support SysML. To begin the journey of MBSE, you don’t have to adopt a SysML tool right away. Maturity of MBSE is still young. Very few organizations do it for a program in an end-to-end manner. The learning curve is steep. Generally, a few engineers become the “scribe” and then end up translating to the extended team. And keep in mind a systems engineer is a “cat herder.” This person is the one who sees the big picture, understands the problem, and is the translator across engineering domains and the business. A SysML tool won’t be the only tool in their arsenal.

MBSE Maturity Levels

This finally brings me to describing MBSE tool maturity levels. Many organizations are already performing MBSE without even calling it MBSE just by the tools and processes they use in the organization. Level 0 is what I describe as only using documents and having no model representations at all. Level 1 is barely a step up from level 0 but the have a requirements tool in place or possibly a Kanban board that is capturing loosely coupled relationships between data. Level 2 is where teams are now combining the use of the RM tool with diagrams. Perhaps they are drawing diagrams in Visio or a UML tool. Level 3 is the combination of requirements, architectures, diagrams are used in conjunction with a defined methodology for how the information is defined, related, and analyzed. The tool will programmatically constrain the data in order to provide consistency as well as provide the mechanisms to define once and then reuse. Level 4 tool maturity is where organizations use a requirements tool and SysML tool.

Jama Connect aligns as Level 3 maturity. Customers who use Jama Connect experience their requirements becoming a source for strategic information during all stages of the system lifecycle. Requirements are turning into actionable data. The software world with its mass adoption of agile practices is trickling into the systems space and requirements now take different shapes. MBSE takes more than use of a language-based graphical modeling tool. Even for a Level 4 maturity, natural language is still the great common denominator. Not everyone will be an engineer and able to interpret models. Requirements and the structured architecture within Jama Connect provides the necessary context. Jama Software’s Traceable MBSE™ approach can be seen as the bridge one uses to leave behind documents and move towards Level 4 maturity.



[Webinar Recap] MBSE Made Easy: Overcoming the Organizational Challenges

Last month we held a webinar on model-based systems engineering titled, “MBSE Easy, Overcoming Organizational Challenges.”

This webinar was well received by our customers, and we wanted to make sure nobody missed out on this great content. Below, you’ll find a recording of the webinar and an abbreviated transcript.

Shifting to MBSE is an Organizational Paradigm Shift

An organizational paradigm shift from document-centric to model-based systems engineering (MBSE) can be daunting. The learning curve for systems engineers can be steep and the return on value is not often immediately apparent. In this webinar, I will explore some of the most common MBSE challenges and tactics to help teams eliminate the barriers to broader adoption. I will also illustrate how Jama Connect can be used to streamline a collaborative data-driven approach and provide more immediate systems engineering value to larger numbers of stakeholders. The agenda topics that we’re going to go over today are benefits of MBSE to the broader stakeholder community, best practices for cultural adoption, the expected return on value, keys to eliminating documents and then using Jama Connect to facilitate the implementation of MBSE.   

The Benefits of MBSE – Specifically Human Understanding

To help us understand the benefits of MBSE to a broader stakeholder community, let’s talk about what it is used for. MBSE in the words of industry leaders like INCOSE, NASA, or Gartner Research describe it as “facilitating understanding or providing aid to decision-making, connecting system relationships, controlling system configurations, providing communication of an overall system picture that’s accessible to all.”

It ensures everyone is working on the same up-to-date material at all times. I see a theme here. Many of these are very human-centric. MBSE is designed to take that complexity and allow it to be consumed and understandable by everyone. From a technical standpoint, configuration control, versioning, relationship management are some of the keys. Why MBSE? Human understanding, decision-making, relationship management, configuration and version complexity management are just not things you can easily achieve when you mire yourself in documents.   

RELATED: Strategies for Remote Engineering Teams

The Limitations of a Document-Centric Approach

In a document-based world, engineers might be manually searching documents, manually managing a section number heading scheme in the document, it might be creating siloed trace information and spreadsheets. They might not know where the latest version of a particular document is or who might have even changed the document last. They might be relying on a single person who is the tool guru because the tool is old and too hard to learn how to use. They might be spending hours or days cross-referencing many data sources just to determine an impact change or consider a trade-off. Here we are in 2021 and still, so many of us are kind of swimming in the sea of documents. Mechanical engineering, electrical engineering, and even software engineering, these disciplines have been using models for decades, right. Now, having the best information at the system level is critical. What we need is a paradigm shift away from documents and a shift in the way you think.  

The Benefits of MBSE for the Broader Stakeholder Community

The benefits of a paradigm shift from documents to data that MBSE brings is not merely for the systems engineer to reap. The new ways of thinking about the system being developed and the new structure of the data itself benefits everyone. I’d argue that the system view is the most important view of all. I think most of you are systems engineers out there and I think you tend to agree. MBSE allows engineers to work successfully at greater levels of complexity. It also improves the communication between the technical communities as well as the business and even the customer. It provides visibility of the gaps that you might have, errors, misalignments of the system design — those kinds of problems might result in defects in the system or cause design rework or cause missed requirements or even dropped requirements. Some of the MBSE challenges — there are challenges out there with adopting MBSE.  

RELATED: MBSE and The Digital Thread

The Unique Challenges of MBSE – And Tips for How to Solve Them

The benefits that MBSE promises do present some of these unique challenges to those who are beginning their MBSE journey. The learning curve can be steep. Learning the language of SysML and maybe your chosen modeling tool takes a long time. This learning curve can’t be done in silos or via tutorials. The learnings need to be backed by your experience. Organizations need to adopt strategies for not just how their systems engineers are trained but how they will use MBSE and then how they need to adopt strategies for how the entire organization works and communicates in that paradigm.

Overcoming Organizational Resistance to Change

Organizational changes are often met with resistance to change. Change has to start at the executive sponsorship level. I think that goes without saying — any organization adopting any kind of change really needs an executive sponsor. That executive sponsor needs to demonstrate their leadership with their actions. MBSE lip service won’t work. They have to be involved and they have to demonstrate that they’re willing to make the changes themselves.  

MBSE isn’t necessarily a one-size-fits-all either. The method and extension of the methods needs to be adapted to the actual system of interest that’s being developed. Systems also need to be developed with modularity and reusability. 

RELATED: Jama Connect in the Digital Engineering Ecosystem

Misaligned Teams and Overcoming Boundaries

Many of the challenges to adoption are human factors and they might be the easiest to mitigate by perhaps simplifying your tools and your approach. Misaligned teams struggle to overcome those cultural boundaries to develop the services and products. MBSE is not something that just the systems engineering team does but it’s a technique. It’s similar to the Agile method, it’s something that the entire organization embodies. It requires that change in culture in order to adopt.

Moving from a documents-based approach to MBSE doesn’t have the be daunting. Start small. Put aside doing day-to-day work in the documents and have everyone across the team access data in your chosen MBSE solution. Even if you don’t have a dedicated SysML tools, you can perform MBSE by creating lists or drawings that capture architectures and behaviors.

In many cases, it takes time to fully adopt MBSE and engineers might feel insecure. Moreover, implementing MBSE is not about just using the tool, it’s about understanding what to model, why, and for which outputs. Again, that comes with experience. Don’t bite off more than you can chew. Don’t just roll out your SysML tool and expect to be doing MBSE. That just doesn’t work. Try to leverage web-based tools that provide more stakeholders a consumable view of the information that maybe they would regularly see in documents. 

If tools are becoming your focal point, make sure that they are usable and do provide value across the teams. Communicate the MBSE return on value to them. Communicate the return on the value back to your leadership team. Systems engineering, unlike software or electrical or mechanical engineering doesn’t have that output that’s tangible to the customer. Leaders need reminding of the value that MBSE is delivering.  

Download our new whitepaper, A Path to Model-Based Systems Engineering (MBSE) with Jama Connect, to learn more about digital engineering & MBSE benefits, obstacles, and success factors.

DOWNLOAD NOW

Optimize Product DevelopmentEditor’s Note: This post about how to optimize product development was originally published here on DevOps.com on July 31st, 2020, and was written by Josh Turpen, Jama Software’s Chief Product Officer. 

Systems engineers have faced complexity since the dawn of time. And while bringing complicated projects to market under old rules, methods and technologies was never a walk in the park, today’s highly competitive market presents new challenges to prove the old rules of product development are defunct. In fact, a recent report from Machina Research, now part of Gartner, estimates the number of connected machine-to-machine devices will increase to 27 billion by 2024, up from 5 billion in 2014. The sheer increase in machine devices alone provides a clear picture of the importance placed on systems engineers to stay the course when navigating product development’s complex nature.

Within the constantly evolving modern product development system comes an increasingly intricate development process. Today’s system engineers are fighting to fit a square peg into a round hole by using old tactics to solve new challenges. This includes an accelerated rate of innovation, increasingly complex end user asks, tighter deadlines and ever-changing regulations. Alongside these challenges, Forrester Consulting found that product development is facing five main obstacles in keeping teams from true optimization:

  • The confusing and constantly changing nature of requirements and a lack of quick development for solutions.
  • Stakeholders providing conflicting priorities, assumptions and unclear objectives.
  • Difficulty collaborating across globally distributed teams.
  • Unnecessary handoffs and delayed decisions.
  • The increased need for collaboration across diverse roles.

So what is the solution to these problems, you ask? One could argue strategic team collaboration is the best way to address both the challenges of the modern product development landscape and the obstacles systems engineers are facing. Let’s dig into that a bit deeper.

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

Team Collaboration: An Enabler of Innovation

Teams that are still operating with outdated strategies and systems find themselves unable to adapt and adjust quickly when the market changes. With rapid growth predicted to stay at a steady rate, strategic collaboration allows companies to build partnerships and seek solutions that are adaptable and specialized. This includes sharing data throughout your whole business, including distributed teams and partner organizations, which allows transparency to reach the entire supply chain. With the COVID-19 pandemic causing supply chain halts and the backup of product releases, it is now more important than ever to ensure communication throughout the entire development process.

With the country leaning on a remote workforce more heavily this year, virtual meetings and emails are not sufficient enough as communication tools for a team that has to coordinate across departments, roles, companies and geographic boundaries. As a first step to meet these demands, system engineers should consider the following strategies:

  1. Ask your team the question, what does success look like? If each member has a different end goal, you will end up wasting valuable time. By defining what success looks like, you can align your teams on what you are building and clarify expectations upfront. This saves time and allows for better communication across teams.
  2. Support better decision-making through situational awareness. When you have communication upfront about a team’s end goal, they are far more likely to make decisions that work toward achieving that. Without situational awareness, employees are unable to comprehend the impact of their decisions or clearly define their roles and responsibilities. This makes it difficult to settle on the right choice when faced with a bump in the road.
  3. Ensure you’re up-to-date with your traceability practices. Especially for those who need to adhere to regulations, traceability analysis allows you to ensure your system holds up under regulatory demands. Further, it meets contractual terms before you encounter a problem.
  4. Create collaboration with a purpose. Ensure relevant data is accessible to everyone to whom it may be relevant, and keep them in the loop on decisions that happen outside the process as much as possible. When you keep your teams in the know, they are able to work collaboratively and with greater situational analysis.

At the end of the day, your goal should be to empower your whole team through data sharing, transparency and a clear definition of success. When you are able to do this, your team will be better positioned to make decisions that benefit the project and work symbiotically across diverse roles.

We may not be able to predict exactly where the product development industry is going, but know that there will be rapid innovation. It’s best to prepare your teams now; otherwise, it will be a bumpy ride.

Download our eBook to learn how optimize product development with strategic team collaboration.

DOWNLOAD NOW