Tag Archive for: product teams

 

Adopting MBSE

This blog contains excerpts from a whitepaper titled, The Comprehensive Guide to Successfully Adopting MBSE, written by Lou Wheatcraft. 

Adopting MBSE: Challenging the Status Quo in Product Development

For product development teams to successfully implement a practice such as model-based systems engineering (MBSE), it requires the willingness of an organization to perhaps change processes and even tooling. Often, companies choose to stay with the status quo, but at what cost? Here’s a look at how adopting MBSE might help your teams, and the cost of not adopting MBSE. 

Understand the Need to Move for Change 

What is the Risk of Staying with the Status Quo? 

For the MBSE Implementation Project Team to be successful, management must recognize the need to change. How can management be convinced? Three words – RETURN ON INVESTMENT (ROI)!  

Think about these questions: 

  •  What has been the impact of the current, poorly executed product development efforts? 
  • What is the overhead associated with the current document-based approach?  
  • What are the current quality issues facing the organization that is catering it to profits: Failures, recalls, returns, warranty costs, lawsuits, negative reviews on social media, decreasing market share?  

The ROI argument usually works with management especially when they can be convinced that by investing in a data-centric practice of SE tailored to the organization’s needs, the overall product development process, product quality, time to market, and profitability can be improved as discussed previously. 

What is the ROI of Adopting MBSE? 

To entice anyone — especially an entire organization — to make a change, proving ROI on the resource investment is key. Here are some key points to consider: 

  • The more effective the Systems Engineer (SE) processes, the less rework and fewer cost and schedule overruns.  
  • By moving to a data-centric practice of SE, the probability of achieving a competitive advantage can be improved by removing obstacles to being able to deliver products on time, on budget, and that meet or exceed customer and quality expectations. 
  • From a cultural perspective, the personnel responsible for product development and will be most affected by the change must be shown, and how the change will benefit them.  

Visit our interactive content page for ROI Calculators and more! 

Combating Opposition to Change

A good process is not one that is something people have to do in addition to their job, rather it is one that helps people do their job more effectively. – LOU WHEATCRAFT

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

Get Team Buy-In

To get buy in from the product development teams, the MBSE Implementation Project Team must: 

  • Understand what problems the product development teams are having and show them how moving to a more data-centric practice of SE will address those problems and make their job easier than the current document-centric approach. If the change results in more work or makes communication harder, the battle will be lost. For example, the lead engineer or project manager may already be over their head and working 50–60-hour weeks. Requiring them to learn how to use a new tool or set of tools and implement a new process may be too much of a load for them to bear! However, if they are provided with a dedicated person that has the training, knowledge, and experience in the new processes and tools to help implement the changes and train other team members, they will be much more receptive. They will also be much more receptive if this results in them having to work fewer hours and having fewer crises to deal with each day! 
  • Be convinced of the utility of the changes, how the changes result in a better product and result in less rework for them. Frequently the reason project team members are working long hours is because they are always fighting fires, going from one crisis to another, which resulted from the lack of the proper SE tools, processes, data, and information in the first place! The culture needs to be changed from one of firefighting to one of fire prevention. As time passes, they will become advocates for the changes that have been made and welcome further change. 

The MBSE Implementation Project Team’s mission statement will be something like: “Improve our product development processes by adopting MBSE within the organization by moving from a document-centric to a data-centric practice of systems engineering.” Along with this mission statement, they will need to define a set of specific goals and objectives along with measures of success. Once defined, they will need to get agreement from management on these goals, objectives, and measures. 

RELATED POST: Systems Engineers Career Path – How to Elevate

Get Management Buy-In 

Project success is dependent on having a high-level, C-suite project champion and getting management buy in. A major challenge for the project will be convincing management and other key stakeholders that it is time for adopting MBSE and moving from a document-centric to a data-centric practice of SE and knocking down the walls of resistance. Some common reasons for them not wanting to move to a data-centric practice of SE include: 

  • “We have been doing product development using our current processes for years, why should we change?” 
  • “Implementing SE from a data-centric perspective may work for others, but not for us.” 
  • “This all seems very complicated, we don’t have the knowledge, experience, or tools.” 
  • “Our current SE work products, like requirements, are managed in an RMT. FFBDs, and other diagrams we are currently using are models, so aren’t we already adopting MBSE?” 
  • “It is too expensive to procure the needed SE toolset, maintain the tools, and train our people to use those tools.” 
  • “We don’t have the budget to incorporate SE from a data-centric perspective at this time.” 
  • “The expense and associated process to get new SE toolset installed on organizational computers is too great.” 
  • “We would have to make signification IT infrastructure upgrades to accommodate the additional volume of data and performance requirements of the new SE tools.” 
  • “We deal with the development of classified systems; controlling access and maintaining security will be too difficult.” 

Sound familiar? Often the pushback can be attributed to a lack of understanding the risks associated with the current state of the organization, understanding the benefits of moving toward a more data-centric practice of SE, and what level of SE capability is appropriate for the organization.

RELATED POST: Whitepaper: A Path to Model Based Engineering (MBSE) with Jama Connect

Adopting MBSE: The Road to Success 

To inspire a shift from a document-centric to a data-centric practice of SE in your organization, it’s vital to show both teams and management the value and expected ROI in doing so. Moving away from a current way of doing things isn’t always an easy road, but the risks of staying with the status quo are often great—and the rewards for changing processes and culture are often even greater.  

An organization will be successful in practicing SE from a data-centric perspective when it is considered to be the “gold standard” for system development within the organization. However, the road to success is long — it takes very strong, unwavering leadership and experience to get this done right. It is human nature to try to push back and say that it isn’t possible, but it is.   

 


This is Part 3 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 II, and Part IV.

Developing a roadmap to successfully adopting MBSE within your organization

In this section, we provide a general approach or roadmap to be used in your company’s journey in successfully adopting MBSE within your organization. We say “journey” because that is what it is. Transforming an organization doesn’t happen overnight. There are a lot of pieces of the puzzle to address so it is important to take small steps and not try to do everything at once. Success includes addressing the key factors of success discussed earlier and define a roadmap. This journey could take several years depending on the size of your organization.

As stated earlier, the organization should form a dedicated MBSE Implementation Project Team with membership from each of the key organizational elements that have a stake and role in the adoption of MBSE within the organization. A general roadmap the project team can follow is shown in Figure 1:

Figure 1: Roadmap to Successful Adoption of MBSE

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

01: Get Management Buy-In

As discussed earlier, project success is dependent on having a high-level, C-suite project champion and getting management buy in. A major challenge for the project will be convincing management and other key stakeholders that it is time to adopt MBSE and move from a document-centric to a data-centric practice of SE and knocking down the walls of resistance. Some common reasons for them not wanting to move to a data-centric practice of SE include:

  • “We have been doing product development using our current processes for years, why should we change?”
  • “Implementing SE from a data-centric perspective may work for others, but not for us.”
  • “This all seems very complicated, we don’t have the knowledge, experience, or tools.”
  • “Our current SE work products, like requirements, are managed in an RMT. FFBDs, and other diagrams we are currently using are models, so aren’t we already doing MBSE?”
  • “It is too expensive to procure the needed SE toolset, maintain the tools, and train our people to use those tools.”
  • “We don’t have the budget to incorporate SE from a data-centric perspective at this time.”
  • “The expense and associated process to get new SE toolset installed on organizational computers is too great.”
  • “We would have to make signification IT infrastructure upgrades to accommodate the additional volume of data and performance requirements of the new SE tools.”
  • “We deal with the development of classified systems; controlling access and maintaining security will be too difficult.”

Sound familiar? Often the pushback can be attributed to a lack of understanding the risks associated with the current state of the organization, understanding the benefits of moving toward a more data-centric practice of SE, and what level of SE capability is appropriate for the organization (Goldilocks principle discussed earlier).

02: Understand the Need to Move Toward a Data-Centric Practice of SE

For the MBSE Implementation Project Team to be successful, management must recognize the need to change. How can management be convinced? Three words – RETURN ON INVESTMENT (ROI)! Think about it… what has been the impact of the current, poorly executed product development efforts? What is the overhead associated with the current document-based approach? What are the current quality issues facing the organization that is catering it to profits: Failures, recalls, returns, warranty costs, lawsuits, negative reviews on social media, decreasing market share? The ROI argument usually works with management especially when they can be convinced that by investing in a data-centric practice of SE tailored to the organization’s needs, the overall product development process, product quality, time to market, and profitability can be improved as discussed previously.

The more effective the SE processes, the less rework and fewer cost and schedule overruns. By moving to a data-centric practice of SE, the probability of achieving a competitive advantage can be improved by removing obstacles to being able to deliver products on time, on budget, and that meet or exceed customer and quality expectations.

From a cultural perspective, the personnel responsible for product development and will be most affected by the change, must be shown how the change will benefit them. Changing culture is often met with opposition and existing stovepipes/silos often resist change.

To combat this opposition, determine which stakeholders are for and against the change and why. For each individual or group, identify their concerns and devise a strategy to get the change adversaries to become change advocates. Start with those stakeholders that have the most influence and convince them by addressing their concerns. The aid of other stakeholders may need to be obtained to help influence those that oppose the change.

A good process is not one that is something people have to do in addition to their job, rather it is one that helps people do their job more effectively. – LOU WHEATCRAFT

To get buy in from the product development teams, the MBSE Implementation Project Team must understand what problems the product development teams are having and show them how moving to a more data-centric practice of SE will address those problems and make their job easier than the current document-centric approach. If the change results in more work or makes communication harder, the battle will be lost. For example, the lead engineer or project manager may already be over their head and working 50–60-hour weeks. Requiring them to learn how to use a new tool or set of tools and implement a new process may be too much of a load for them to bear! However, if they are provided with a dedicated person that has the training, knowledge, and experience in the new processes and tools to help implement the changes and train other team members, they will be much more receptive. They will also be much more receptive if this results in them having to work fewer hours and having fewer crises to deal with each day!

People at all levels must be convinced of the utility of the changes, how the changes result in a better product and result in less rework for them. Frequently the reason project team members are working long hours is because they are always fighting fires, going from one crisis to another, which resulted from the lack of the proper SE tools, processes, data, and information in the first place! The culture needs to be changed from one of firefighting to one of fire prevention. As time passes, they will become advocates for the changes that have been made and welcome further change.

The MBSE Implementation Project Team’s mission statement will be something like: “Improve our product development processes by adopting MBSE within the organization by moving from a document-centric to a data-centric practice of systems engineering.” Along with this mission statement, they will need to define a set of specific goals and objectives along with measures of success. Once defined, they will need to get agreement from management on these goals, objectives, and measures.

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

03: Access the Organization’s Current Practice of SE

To do this, they need to first assess the organization’s current state of practice of SE in terms of the ten areas of capability associated with data-centricity discussed previously. Table 1 shows an example of what the results may look like for organizations that are firmly rooted in a document-centric practice of SE. Sadly, this is the state of many of today’s organizations!

 

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

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


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



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


Requirements Management Plan 

Product success depends upon the successful project management of the product’s requirements. Effective requirements management, in turn, requires thoughtful planning. 

 A requirements management plan describes how you will gather, analyze, document and manage the requirements of the project. It should describe how you intend to gather the high-level project and product requirements from project stakeholders, industry standards and governmental regulations, as well as the more detailed product requirements you will collect and develop over the project lifecycle. Your requirements management plan should also specify how you will manage changes to requirements after they have been approved. 

Your requirements management plan is a tool for communication. It provides all your project’s stakeholders with a common understanding of how the product’s requirements will be managed to ensure success. 

In this article, we’ll describe the requirements management planning and the recommended components of a requirements management plan. 

What is Requirements Management Planning 

Requirements Management Planning is the process of documenting how you will gather, analyze, document and manage the requirements of a project, manage changes to requirements once they have been approved, manage the configuration of the requirements documentation, and track verification of the project’s requirements. 

Components of a requirements management plan 

A solid requirements management plan will be composed of several components. Here, we’ll describe our recommended sections. Depending upon your industry and organization, not all of these sections may be applicable to your situation. 

Project overview 

Briefly describe the purpose of the project. Explain the need the product will fill for the customer or target market and how its development will benefit your company. Mention important goals for the project and any notable constraints that may have been imposed upon it.  

Roles and responsibilities 

This section lists the roles of those who will be involved with managing the requirements through the rest of the project lifecycle, along with the responsibilities of each role. 

Typical roles include: 

  • Project manager 
  • Lead analyst / lead requirements engineer 
  • Analyst / requirements engineer 
  • Stakeholder 

The project manager typically has overall responsibility for managing the scope of the requirements for the project.  

The lead analyst / lead requirements engineer may also be a lead systems engineer or lead developer. This role is generally given overall responsibility for requirements development and integrity.  

Analysts and requirements engineers assist the lead analyst / lead requirements engineer and are typically tasked with following the specified procedures for managing the subset of the project’s requirements for which they have been given responsibility. 

Other project stakeholders who provide input to the requirements base are generally given responsibility for reviewing the requirements at specified milestones. 

Tools 

In this section of your plan, describe any automated tools that will be used to manage the requirements. Provide a brief overview of how those tools will be used during the requirements management process, and reference any documented procedures governing the use of the tools.  

More detailed descriptions of how the tools shall be used in the various steps of the process should be provided in the sections of the plan that describe those steps. 

Requirements gathering 

Describe the process that you will use to elicit, analyze and document the requirements. Then, describe the requirements gathering techniques you will use and with what groups you will use them. 

RELATED POST: 11 Requirements Gathering Techniques for Agile Product Teams

Categorization and assignment 

Here, you will describe your process and procedures for dealing with various types of requirements. 

Describe how requirements will be categorized within your requirements management system. Typical categories include:  

  • Functional 
  • Non-functional 
  • Internal 
  • External 
  • Regulatory 
  • Performance 
  • Quality 
  • Training 
  • Support 
  • Maintenance 

 The difference between functional and non-functional requirements—what the product must do versus any constraints on how the product must be constructed—normally impacts how the requirement will be verified. For more information on non-functional requirements and their impact on product development, click here. 

Internal requirements will generally be driven by the needs of stakeholders within your organization. External requirements will include those driven by customers, market forces, government regulations industry standards, etc. 

A requirement’s category will dictate, in part, how it is assigned for development, implementation and verification. Your plan should describe your policies and procedures for assigning requirements to subsystems or components or by work breakdown structure (WBS). 

Prioritization 

Companies will prioritize the fulfillment of some requirements over others. Reasons for high prioritization may include market demand, regulatory compliance, contractual obligation, or internal stakeholder need. 

That’s why it’s important to plan and document how you will prioritize requirements for development and release. Keep in mind that you will likely describe in detail your rules for prioritizing requirements in your Product Requirements Document. 

Traceability 

Describe your overall process for tracing requirements throughout the product lifecycle: from gathering, through decomposition, development, implementation and verification. Mention the tools to be used to accomplish the traceability process. 

Requirements and their attributes need to be tracked throughout the project lifecycle to ensure fulfillment. Attributes to be tracked may include: 

  • Name
  • Type 
  • Project unique identifier 
  • Source (stakeholder, document, parent requirement, etc.) 
  • Children (lower level requirements derived from the requirement) 
  • Assigned element of the WBS where it will be addressed 
  • Verification method (if your project requires a variety of methods) 
  • Verification reference (to the procedure that will verify the requirement) 
  • Compliance reference (applicable regulations/paragraphs) 

RELATED POST: What Is Requirements Traceability and Why Does It Matter for Product Teams

Change management 

As a project evolves, requirements will need to be added or modified. Therefore, your requirements management plan should include a section that describes your policies and procedures for change control. 

Change management (or change control) generally involves documenting each proposed requirements change in a change request. Once written, the change request is analyzed by affected stakeholders for any possible impact on project objectives or other requirements. The change request then goes before a change control board where it is either accepted (to be implemented) or rejected (and either revised or dropped). Your procedures for change control (raising, reviewing, tracking and approving change requests) should be described or referenced in this section. 

Configuration management 

Describe how you will monitor and control changes to your requirements documentation. Configuration management deals primarily with how documents will be revised and released during a project. 

For many projects, depending upon your organization, this section may be combined with the Change Management section just described. For very large projects, you may want a separate Configuration Management section. If you have a separate Configuration Management Plan you’ll probably want to reference it and keep this section brief. 

Verification 

Finally, describe the methods and metrics you will use to verify requirements. Specify how their achievement will be measured, tested, etc.  

If you use a variety of verification methods to verify different types of requirements, you will likely want to give a brief explanation of the procedures for each and how each type of verification is documented.  

Benefits of requirements management planning 

As mentioned earlier, your requirements management plan is a tool for communication. It helps your analysts, systems engineers and developers get up to speed and stay on the same page when it comes to managing your project’s requirements. Plus, it gives higher-level stakeholders a warm, fuzzy feeling that your product’s requirements will be properly managed to ensure your product’s success. 

For more in-depth information… 

Requirements management and requirements management planning can be greatly simplified through the use of a state-of-the-art requirements management tool like Jama Connect. For a deeper dive, visit our Essential Guide to Requirements Management! 

requirements-management-hub


Top-Signs-Your-Design-Review-Process-is-Hurting-Your-Business

Design review processes and their impact on product development.

Development organizations typically have a predefined set of formal design reviews that are held throughout the development process. A design review usually includes assessing design input requirements for adequacy, assessing the adequacy of a design to fulfill design input requirements, and verification/validation-related reviews. When done correctly, design reviews are an important part of a robust product development process because they help identify design issues early when they cost less to fix.  When not done correctly, design reviews can be detrimental to the success of a development organization. So what are the top signs that design reviews are hurting your business and not helping you develop better products on time and within budget? 

  1. Not planning design reviews appropriately. 
  2. Performing design reviews that are not effective or efficient. 
  3. Not following up on review action items. 

RELATED POST: Five Key Design Control Practices that Improve Compliance and Help Develop Better Products

Not planning appropriately for design reviews involves not performing design reviews at the correct time and not sending out review material with sufficient time that reviewers can adequately prepare for the review. Often, formal reviews involve reviewing deliverables associated with a milestone or a certain phase of the development process. Because these reviews are required by procedure, they are generally performed but often end up as a status marker of where the project is at, instead of a design review intended to identify issues. Additionally, design reviews can be performed at any time in the development process, when a review of some element of the design is beneficial in identifying potential issues. These technical reviews can be invaluable in identifying design issues early in development and should be performed on an as necessary basis. Development organizations are sometimes hesitant to hold additional reviews, other than the required formal reviews, because of the time required to prepare, perform, and document the review, thus passing up opportunities to improve the design while it is still less expensive to make changes.   

Unfortunately, oftentimes, design reviews are just performed to meet the regulatory requirement, but not with the goal of identifying issues. The check-the-box mentality, prioritizes project schedule over product quality, as it passes upon opportunities to significantly impact and improve on the quality of the design before the design is frozen. In order for design reviews to be efficient and effective: 

  • Reviewers should be provided sufficient time to review the material prior to the review meetings. 
  • An independent reviewer, a person with no responsibility for the design being reviewed, should be invited to the review.  
  • All participants should come prepared for the review, having reviewed the material beforehand. 
  • An experienced facilitator/moderator shall be utilized, the role of the facilitator is to keep the meeting on track, ensure the agenda is followed.  
  • Utilize a scribe to record the meeting minutes, this will free the design owner to fully focus and participate in the review.  It will also allow the meeting to progress more efficiently. 
  • Ideally, utilize a requirements tool, like Jama Software, to automate and centralize the above activities. 

RELATED POST: A Guide to Requirements Elicitation for Product Teams

Gathering metrics on the number of issues found during reviews, the types of issues found, and the amount of time spent in reviews can help determine the effectiveness of your design review process.   

When a review is performed appropriate documentation should be generated. First, a design review agenda should be prepared to detail the date and time of the review, the location of the review, the review objective, the review participants and their roles along with the materials to be reviewed. During the review, the list of attendees should be documented, along with items discussed, decisions agreed to, conclusions reached and any action items generated, along with the person responsible and due date of the action items. Review minutes should be published containing all this information.   

When action items are generated as a result of a design review, a requirements tool, like Jama Software, should be used to track review action items to completion. Ideally, action items should be completed prior to the next project milestone or major review. Not following through on review action items is not only a regulatory liability but can give the impression to reviewers that the time spent in reviews is wasteful, causing them to treat design reviews as a check-the-box activity. 

In summary, design reviews can be a very helpful tool in identifying design issues early, when they are less costly to fix. However, in order for design reviews to be helpful, they need to be planned and held at the appropriate times during the development process, following guidelines for effective design reviews, documenting design reviews appropriately, and following up and tracking design review action items to completion. If you are going to spend the time in design review, let the time be well spent, let reviews serve their purpose, and gain the benefits from the time and resource investment in this activity. 


a-guide-to-requirements-elicitation-for-product-teams

 

The success of a development project relies on understanding the business need and defining the correct list of requirements. Requirement elicitation is the process of communicating and collaborating with key stakeholders to assemble the insight and identify the project’s needs.

This article will provide an overview of why requirements elicitation is important for product teams, discuss different elicitation techniques, and outline the steps involved in eliciting requirements.

What is requirements elicitation?

Business analysts conduct requirements elicitation to identify the business need, scope, assumptions, and risks of a project based on data from key stakeholders. It’s an imperative part of requirements management as the outcome impacts the fundamental understanding of the project’s goal. Failure to clearly define business needs can lead to catastrophic results such as expensive mistakes or system failure.

The importance of requirements elicitation for product teams

Requirements elicitation is important for product teams because it is the main way product requirements are identified. The elicitation process unearths requirements insights from key stakeholders. By expertly asking the right questions of subject matter experts, enabling deep conversations, and recording findings, business analysts discover the true business needs to drive the project.

In the absence of properly identified business needs and requirements, development costs will be over budget due to rework, users/customers will not get what they want, and projects will be unsuccessful.

The requirement elicitation process

An effective elicitation process is important for product teams to realize the following benefits:

  • Lower project costs by catching requirements problems before development begins.
  • Increase the likelihood that users and customers get what they want.
  • Reduce the risk of project failure.

RELATED POST: Requirements Management Maturity Model – Empirical vs Theory

There are five main steps to the requirements elicitation process:

  1. Gathering requirements

You may be thinking, “How is requirements elicitation different from requirements gathering?” especially when the two terms are often used interchangeably. It is a good question, and it is acceptable to casually interchange them. However, there is a slight difference between gathering requirements and requirements elicitation that is worth pointing out when discussing the specifics of the requirements elicitation process.

By definition, “gathering” is the act of collecting from scattered sources, while “eliciting” is the act of drawing out information from a source. Both acts are essential to the overall process of requirements elicitation and take expertise to execute properly.

An effective way to prepare for requirements elicitation is for business analysts to gather all available requirements and study them for insights. A few techniques for requirements gathering include:

  • Document analysis, such as studying process models or researching regulations.
  • Analyzing system interfaces and business rules.
  • Reading available user feedback.

The findings from requirements gathering can help identify key stakeholders and inform which requirements elicitation techniques might best suit the project. Business analysts can then begin the work of drawing out the enlightening experiences that fill in the missing requirements. Therefore, requirements gathering is the perfect first step in the process of requirements elicitation.

  1. Identifying key stakeholders

As noted, requirements gathering can provide insight on relevant stakeholders. It is important to identify the right people up front so everyone can begin on the same page. Doing so eliminates the need to fill in missing requirements later that could potentially change the course of the project.

  1. Eliciting requirements from key stakeholders

In this part of the process, business analysts need to determine which requirement elicitation techniques will provide the best results given the project at hand and appropriate stakeholders.

There are a variety of requirement elicitation techniques, here are some of the most popular methods.

Brainstorming –

Use case: Current solutions may not be innovative enough to meet the project’s goal.

Designed to: Uncover new, innovative ideas and solutions.

How to: Assemble a mix of key stakeholders for an open conversation on innovative ideas and solutions. As facilitator, the business analyst ensures that the conversation stays on topic and records ideas discussed.

Focus groups –

Use case: Business analysts need more information about specific aspects of the project. Time is short.

Designed to: Help stakeholders be more forthcoming and articulate solutions. Get a lot of information at once.

How to: Gather representatives from stakeholder groups. The facilitator asks questions to get team members to discuss specific areas of interest and records ideas discussed.

Interviews –

Use case: Get an in-depth perspective from a specific subject matter expert (SME).

Designed to: Obtain a stakeholder’s one-on-one insight on the business need or viability of given solutions.

How to: Create questions that will allow the SME to be open about the issues on the table. Questions can be shared in advance or be conducted as a conversation. The interviewer should take notes and share them with the SME to ensure he or she correctly understood the SME’s point of view.

Observation –

Use case: When the development project is an augmentation of a current work process.

Designed to: Provide a direct view of how a stakeholder performs a particular process.

How to: Observation can be conducted passively—the facilitator watches the stakeholder work without interrupting—or actively—the facilitator asks questions about the work as it is being performed. In both cases, the facilitator should take notes and get feedback from the stakeholder on the information collected.

Prototyping –

Use case: When stakeholders do not understand written technical requirements and would benefit from seeing a version of the product.

Designed to: Collect feedback from non-technical stakeholders by showing them an example with which they can physically interact.

How to: At first prototyping can be executed via storyboard, interactive screen, virtual mock-up, navigation flow, etc. The exact method depends on the project, but it is usually an iterative process that is improved based on input. As more requirements come forward, more detailed prototypes are created to ensure they meet the expectations as recorded.

Requirements workshops –

Use case: When time is short, and the business need is not clear.

Designed to: Get the stakeholders together in a structured, time-based setting to elicit, refine, and edit requirements. Stakeholders can discuss and provide immediate input on identified business needs.

How to: Set a specific timeframe and agenda for the workshop. Include brainstorming, focus group, and prototyping (if applicable) opportunities within the schedule. Use these to guide the discussion and record input.

Surveys –

Use case: When business analysts need data from large groups of participants.

Designed to: Obtain objective feedback from large groups of customers or end-users.

How to: Choose participants wisely based on desired criteria. Create clear questions that do not lead the respondents. Questions can have a number of finite choices or be open-ended—for best results consider the goal of the question, as well as the number of respondents, to determine the best structure for proper analysis.

As is often the case, a variety of requirements elicitation methods can be employed to unearth the business needs of a project. For example, a business analyst may ask specific requirements questions in a focus group, in a brainstorming session, or during observation. A business analyst may also conduct surveys before a requirements workshop, or create a prototype to be used during observation. Knowing which elicitation techniques to use for a given project comes with experience.

  1. Documenting requirements

The next step in the requirement elicitation process is documenting the requirements elicited thus far. There are a variety of formats for documenting requirements: a home-grown product requirements document (PRD), a government-mandated system requirements specification, a requirements management tool like Jama Connect, a spreadsheet, etc. The best tool for documenting requirements depends on the project.

If the project has many stakeholders, complex development, or compliance or functional safety standards, it’s a best practice to choose a requirements management tool like Jama Connect. These are purpose-built to mitigate risks associated with complex systems and regulatory compliance. Assessing needs and researching functionality will help determine the best option for the project

  1. Confirming the findings

Once business analysts document the requirements, it is time to make sure they are recorded correctly. Requirements are sent to all stakeholders to review so there is a collective understanding of what’s being developed. Stakeholders are likely to make refinements. It is also possible that this step elicits further requirements, which will necessitate revisions before approval can take place.

RELATED POST: Requirements Management – Living NOT Static

Business analysts conduct the process of requirements elicitation at the beginning of a project, and the process is ongoing throughout the development process. This is because change is always occurring and it’s never possible to know all the questions to ask or have all the correct answers upfront.

Challenges of successful requirement elicitation

The elicitation process may seem easy: ask the stakeholders what they want. However, it’s a much more rigorous endeavor. Here are some of the most common challenges of the requirements elicitation process.

Finding the right stakeholders – Identifying the correct subject matter experts isn’t always easy. Hunt down “hidden” stakeholders who can be excellent sources of knowledge. Examples include customer-facing personnel like sales/support reps and maintenance techs.

Uncovering the best insights – Unfortunately, stakeholders don’t always know what they want. In the practice of requirements elicitation, multiple elicitation methods can be used concurrently to identify the business need and an optimal list of requirements. The expertise is in realizing the best combination of techniques to yield success for that development project.

Documenting the requirements – Using the wrong documentation tool for the job can be detrimental. Issues can arise with everything from reviews and approvals to managing change. Spreadsheets or home-grown PRDs may work for smaller, non-regulated projects. Complex products or those in regulated industries, on the other hand, greatly benefit from requirements management software that can streamline requirements elicitation and the overall process with features like live traceability and compliance management.

Planning for change – Priorities shift and problems arise—it’s best to plan for changes up front. Be sure to have a process in place that allows time to address problems, document changes, and add new requirements, and conduct additional reviews.

Again, in projects with fewer requirements, it won’t be so grueling to scour spreadsheets or PDRs to manage change. However, this kind of manual change management can still eat up many work hours and push projects off schedule and off budget. With complex and regulated products, however, the potential for waste of time and money is much larger. In these cases, a tool like Jama Connect can save precious time and budget in the face of change. Having the right tool for the job is critical.

Streamlining the requirements elicitation process

Requirements elicitation is a mixture of art and science for business analysts. They need to be adept at knowing which questions to ask and how to ask them. Additionally, business analysts must be able to clearly communicate and collaborate with key stakeholders during all phases of the elicitation process.

Business analysts working on complex or highly regulated projects cannot rely on home-grown PRDs or spreadsheets to document requirements. The level of sophistication in which they are working demands that they have the best requirements elicitation tools at their fingertips.

Jama Connect is a requirements management tool that can transform how business analysts perform requirement elicitation for complex projects. See how Jama can streamline requirements elicitation and management.


Requirements and Risk Management

Congratulations!  Your organization has gained regulatory approval and launched its medical device product.  The ‘History’ in Design History File may elicit impressions that all those design and development requirements are now done and considered part of the past.  However, several components of the DHF continue as a reference and evolve, including requirements and risk management.  Here are 3 ways active management of requirements and risk continues after commercialization:

1: Post-market surveillance

Once your medical device is on the market, post-market surveillance programs, including complaint management processes, must now be exercised.  That includes evaluating feedback, determining if it is a complaint, investigating complaints, and determining whether to initiate corrections or corrective actions.  As part of this process, requirements and risk management are being used in 2 ways, 1) as a resource to evaluate complaints and 2) a living document to be updated with the experience gained.

As a resource, it is important to reference risk management files to determine if the frequency of occurrence and types of failure modes documented during design and development matches the infield data being gathered.  A more frequently occurring failure or new failure mode indicates an investigation is warranted and re-evaluation of the risk.  Depending on the outcome, corrective action may be needed.

For example, during design and development, it was determined that a sensor failure leading to customer annoyance occurred rarely, leading to a low risk rating at the time of market launch.  The first year on the market, reports of this failure occurred rarely, matching the occurrence rates in the risk management file.  Given the low risk and lack of trend, further failure investigation and corrective action were not taken.  However, one year later, a change in supplier coincides with a change in occurrence from rarely to frequent, leading to a medium risk.  This increase in risk prompts an investigation to determine why the sensor failure rate is higher and to determine corrective actions and controls with the new supplier.

As a living document, the risk management files are to be updated with the observed occurrence rates, new cause(s) of the failure mode of the sensor, mitigations and controls put in place, resulting verifications, and revised risk rating.

2: New Products

Another reason requirements and risk management continue once a product is commercialized is to aid in the development of new products, including line extensions, new models, and next generation platforms and portfolios.

The existing product’s requirements and risk management, supplemented with what is learned from post-market surveillance and other feedback from the field, provide the foundation for new products.  A requirements and risk management tool like JAMA Connects® can simplify the management of requirements and risks shared between products to keep teams aligned and prevent requirements or risks being missed during the transfer from one product’s design history file to another.  Likewise, line extensions can be more easily incorporated into an existing design history file if requirements and risk management have been properly updated as needed and are accessible.

3: Change Control Evaluation

Change control evaluations is another way management of requirements and risks continue after commercialization.  Changes to a product and how it is manufactured occur for many reasons, including replacement of a component that has reached its end of life from a supplier, software upgrades to address bugs, duplication of a manufacturing line, and changes that address complaints.

Changes must be evaluated as to their impact on the form, fit and function of the product, and can have varying degrees of potential impact.  Well managed and active requirements and risk management, with traceability to design outputs and verification, become a strong tool for organizations to evaluate the potential impact more quickly.

For example, say a temperature sensor was added as mitigation to prevent overheating of a medical device; overheating that could result in burns to the patient.  The sensor, including the necessary accuracy, is listed as a control for the risk of overheating and burns.  There’s also a corresponding design requirement, and the sensor and its specification are linked as design outputs.  The supplier of the sensor has recently informed the medical device manufacturer that the sensor is reaching its end of life and will no longer be available in 6 months’ time.  A change owner is assigned to identify and evaluate a new sensor.  This person is most likely not the same engineer who originally designed and selected the first sensor.  And that the original engineer may or may not still be with the organization, and may not remember why that sensor was selected.  This is where having accessible and well managed requirements and risk management becomes important.  The change owner can reference and look up the sensor, see the design inputs and risk with which it’s associated, and understand more quickly the criticality of the sensor and ensure the proper selection and testing are performed on a new sensor.

While change post-commercialization is inevitable, difficult change control management is not.

RELATED POST: Product Development Process: How Confident Are You That You Are Not at Risk?

Beyond Commercialization

Management of requirements and risk extends through the entire life cycle of a medical device, including after a device has gained the necessary regulatory approvals and reached the market.  Thus, take care in selecting the tools and developing the processes your organization uses for requirements and risk management.