[Webinar Recap] Best Practices for Simplifying Variant Management
|
In this blog, we recap our recent webinar, “Best Practices for Simplifying Variant Management.”
[Webinar Recap] Best Practices for Simplifying Variant Management
Effective variant management is essential for organizations navigating diverse and competitive markets, regulatory requirements, and evolving customer needs. By adopting best practices, teams can efficiently tailor requirements while maintaining alignment and traceability across complex product lines.
Jama Connect® offers flexible strategies to simplify the creation, adaptation, and tracking of multiple variants. These approaches facilitate efficient reuse, reduce complexity, and maintain traceability across complicated product lines.
In this insightful session, requirements management expert Matt Mickle, Director of Solutions & Consulting at Jama Software, will lead attendees through common variant management use cases and proven strategies.
Key takeaways include:
- Identify and adapt variants to meet shifting market, regulatory, and customer demands.
- Streamline variant creation through smart reuse and cross-team alignment.
- Use structured feature models to manage options and complexity.
- Ensure compliance while evolving product variants.
- Optimize product line strategy with better visibility into variation.
VIDEO TRANSCRIPT:
Matt Mickle: Welcome, everyone. We have a fun topic today, walking through variant management use cases with the goal of simplifying this sometimes complicated topic. I will start off by walking through some of the common use cases that we often hear, followed by some concrete examples of how we would see these within the industry. I’ll talk a little bit about how we’ll solve these within Jama Connect and then have some demonstration of this directly in the tool. I’ll do this for each use case as we proceed, and then we’ll move on to some Q&A and I’ll answer some of your questions.
So, what do I mean when I say variant management? Well, simply, I would describe variant management as any process or technique that is used to manage variability and assets within a project. This could be in the form of certain techniques, such as feature-based product line engineering, which we’ll talk a little bit more about later. Configuration management, product derivation or branch and merge. A product can vary in many ways, such as different features, material or components, premium services or levels of performance. Here are some examples you might recognize. Models of home appliances with different sizes or capabilities, like these refrigerators. Microcontrollers with a configuration of reusable IP blocks. Medical devices, such as insulin pumps or digital thermometers having an array of features based on setting, method of application or type of consumer. As well as everyday devices, such as smartphones or smartwatches with different uses or consumer profiles.
Nearly every product you could think of has some amount of variation. And the process of managing those variants extends from the conception of the products, all the way into their description at the point of sale, and maintenance thereafter. So, one of these methods, which we will mention in the discussion today, is product line engineering or PLE for short. And for this, we’ll use the simple definition, a focus on engineering for a family of products with similar features, components or modules as a single product line to leverage commonality and variability, minimize the duplication of effort and maximize reusability.
Now, a couple of definitions that go along with that from the standards for product line engineering, from ISO 26550, the definition of a feature would be an abstract functional characteristic of a system of interest that end users and other stakeholders can understand. And from the product line engineering for feature-based product line engineering standard, ISO 26580, a product line would be a family of similar products with variations in features. So, product line engineering could be considered as the next step in maturity. Single system engineering. And as the ISO standard on software and system engineering for product line engineering and management states, product companies utilizing single system engineering and management approaches may end up with highly complex and low quality products. Low productivity, high employee turnover, and less than expected customer satisfaction.
RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution
Mickle: So, let’s instead talk about the benefits of moving from single system engineering into product line engineering. Product line engineering enables organizations to create product line architecture that allows for the systematic reuse of components, modules, and assets across different products within a product line. This promotes efficiency by reducing redundancy in the need to recreate similar functionalities for each product. By reusing existing components and assets, organizations can significantly reduce development costs. Product line engineering allows for economies of scale, as the investment in creating a core set of assets can be spread across multiple products, leading to cost savings in the long run.
With product line engineering, organizations can streamline the development process by leveraging existing components and architectures. Faster time to market for new products, since development efforts are focused on creating unique features, rather than rebuilding common functionalities. Product line engineering helps ensure consistency in products across the product line. By reusing well-tested and validated components, the likelihood of introducing defects or inconsistencies is reduced. And this will lead to higher overall product quality. As market demands change or new technologies emerge, product line engineering provides a framework that allows organizations to adapt and evolve their product line more easily. This enables the addition of new features or modification of existing ones without starting the development from scratch.
Product line engineering supports efficient configuration management, allowing organizations to define and manage variations and products through configuration, rather than by creating separated versions or desynchronized copies of content. This simplifies the task of handling different customer requirements or market-specific adaptations. Product line engineering makes maintenance and upgrades more manageable. Changes or bug fixes can be applied to common components, and then the updates can be propagated to all of the products within the line, ensuring that each product benefits from the improvements without having to undergo individual modifications.
And finally, product line engineering helps mitigate the risks associated with product development by relying on well-established and proven components. Since these components have been used and tested across multiple products, the likelihood of critical issues arising is reduced. Now, of course, there are many benefits for product line engineering, but there are a lot of challenges that a company goes through in order to try and move towards product line engineering. For example, let’s say a company starts out with a single product and then begins to build variants on that product, turning it into a product line. As the number of variants and variation between them grows, the ability to manage them becomes more and more challenging.
When a change is made, it’s important to assess not only the impact of that change within the product, where the change is made, but also in any products that are part of the same product line. If the change is against common requirements, then the decision is needed on whether they need variation. New versions or configurations of components of a system will need to be thoroughly reviewed with regards to how they interconnect. This becomes even more challenging and complex when considered as the product development data moves from one development application to the next. Throughout the supply chain, information about progress and change needs to flow and be collected in order to see overall status.
It’s very difficult to collect and understand this with only a single complex product and increases exponentially with variation. Now, within the context of the content included in Jama, the task of managing variants begins once there is any notion of more than one product being developed which has common requirements to another product. The question then arises of how to maximize reusability, and still understand the impact across multiple variants in the most efficient and effective way. Let’s go over a few ways that this presents itself and what the desired outcomes are. The first case is related to high-level requirements. And in this case, I’ll call it, the use case custom requirements.
RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries
Mickle: Those high-level requirements need to change for a given project. These input requirements could be things like specific market support for different markets that your product is in. It could also be different regulations for different regions, where your product is located and they have to go by different standards. Could also be that your customers are requesting your core product, but they want some customization to that core product. It could also be that you have different consumer profiles that you’re trying to match that product with, or it could be just an evolution from a previous year’s model that’s still in production.
In these circumstances, we may want to just be able to understand what the high-level requirements have as an impact on derived requirements design and test. So, we may need to filter out and keep track of what content stems from these input requirements. And we may need to test and produce documentation specifically related to that filter content. So, let’s imagine that our product team has been working through the lifecycle of creating an initial version of a product, and has developed many of the requirements and design, as well as written the tests against those requirements.
Now they have just received word that there is a new customer that has invested the product and would like the same product the team is already developing, but with some customizations and their own custom branding. This customer would like to also introduce the product into a new market which has a different power and connectivity standard. Technically, the scope of the change is going to total about 10% of the overall content, but the needs need to be tested independently and the documentation needs to be specific to each variant. So, you could copy the content and make the changes in each product independently, but perhaps you would still prefer to just indicate the differences and otherwise make use of the content that currently exists.
Also, you might still be able to make use of much of the testing that is in place for anything that is not interfaced with the components that have changes. For this reason, our strategy would be to keep those products together in a single super-set project, and use a mechanism within Jama called categories to indicate the variation. As you can see from the diagram here, we have the category tree which references a product line with different variants. Those variants would then be applied to the top-level requirements within your project, and then derived appropriately throughout the traceability within that project to ensure that everything has a category for the variant in which it lives.
For those items that are common to multiple variants, those would also contain the category for each variant in which they apply. Let’s go ahead and take a look at how that looks within Jama. So, for this example, I’m going to use a project which we call 48 volt power assist here. And this is our product. And basically, within here we’re going to look at the different variants that this 48 volt power assist has. So, first of all, I can go over to this categories tab, and I can click on that and see the different variants associated with the different categories. These have been added within the organization admin section.
And within each of those categories, you’ll see that I have requirements associated with the category. I just have to see those by clicking on the category itself and then I’ll see throughout the tree what categories apply to which requirements, or vice versa, which requirements apply to those categories in this case. I can also create a filter based on anything that applies to that category. So, here I’ve got those same items, but now I’ve got the structure associated with it when I look at the reading view associated with this. That gives me the ability to, of course, do things like export it as a document and include those different heading structures.
WATCH THE ENTIRE WEBINAR HERE:
Eliminate Gaps and Risks with Proven Traceability Best Practices
Director, Automotive Solutions at Jama Software
Matt has over 10 years of experience working as a requirements engineering consultant for Jama Software. In this position he have worked with hundreds of Jama Software customers to transform their process and transition to working within the application. He has experience working within the guidelines of standards across multiple industries and has assisted in the creation of frameworks adapted to these industries. He also has extensive experience working with integrations between tools.
Latest posts by Matt Mickle (see all)