At first glance, product development may seem like the most complex component of the product life cycle. However, everything developed from the silicon, circuit boards, and software have features, options, and derivatives that need to be identified, productized, and maintained. Managing the myriad of variations within a product line is often called product line engineering (PLE). In this column, we’ll explore PLE in more detail and look at a company with a unique paradigm and solution for lowering complexity and increasing reliability within product lines.

In order to be competitive in today’s environment, companies must deliver a product line, not just a single product with a mentality that “one size fits all.”

What is product line engineering?

In general, product line engineering (PLE) refers to the practice of creating an underlying architecture (both hardware and software) that describes the base platform. The architecture describes the base commonality across the product line as well as planned variations. PLE focuses on the process of engineering new products so it is possible to reuse product assets and flexibly apply a subset of variations for a specific product with minimal cost and time spent.

A Carnegie Mellon SEI study in 2003, among many others, has shown that PLE can have several benefits including higher productivity within the organization, higher quality products, faster time-to-market, and lower labor requirements.

Challenges implementing efficient PLE

PLE is not something a “brute force” process can solve. For example, a rather simplistic embedded system with a circuit board that can be purchased with two CPU options and software with three add-on features yields six possible product variations. With each feature addition, two additional product variations are created. Adding connectivity variations to this example creates an “M x N x O” variations problem. With each additional variable, the product variations can quickly grow out of control, causing duplication, increased development and test time, and even less reliable products.

There is significant complexity to managing all these variations. The example above was simple. Applying the same principles to autonomous vehicles that have a variety of options for radars, cameras, sensors, and electronic steering makes this a tremendous challenge.

The theory behind PLE

Systems and software PLE creates and maintains a portfolio of related products using a shared set of engineering assets and an efficient means of production.

I talked with Dr. Charles Krueger, CEO of BigLever Software about their approach to PLE. Dr. Krueger says their PLE solutions take a “factory view” of the engineering process.

“Think of an analogy of a factory,” Dr. Krueger says. “Assembling and producing requirements and specifications is one dimension. Think about the things coming into the factory: the traditional artifacts like technical specifications, subsystem designed, bills of material, software, user documentation, calibration data, test cases, certifications… The list is long. We want to get really good at reusing these artifacts.”

Dr. Krueger cites a familiar example of the user’s manual in the glove box of an automobile.

“Open [the manual] up and it’s full of things that say ‘if you have this kind of option, do this; otherwise do that.’” Dr. Krueger says. “Most of the time I have no idea if that option is on my car. If PLE can customize the product [auto] down to the user’s manual in the glove box so we don’t have to guess at these if/then statements, things are cleaner and easier.”

Two key abstractions

BigLever uses two key abstractions in their PLE solution: a feature catalog and a bill of features.

These abstractions are key to corporate success in managing the PLE process. The key to success here is, at a corporate level, everyone in the organization buys into the utilization and management of the feature catalog for a product line and a bill of features must exist for each unique product within the product line.

The feature catalog is a corporate-wide asset that lists the available features for the product line. Features describe things that are optional within the product family. Product managers can choose to include or exclude any feature in the feature catalog for a given product within the product family.

The “bill of features” is a description the product manager puts together that details exactly what features go into the making of a specific product within the product line.

The BigLever “Gears product configurator” takes the bill of features description and takes the asset descriptions that come from the supply chain to output a specific product asset subset for a specific version of the product. This includes the product bill of materials, test cases, feature specifications, documentation, and anything else relevant to the included features for this specific product. The Gears configurator differentiates between assets needed for internal production and those that are included in the end product. For example, software source code and test cases are identified as assets needed to build the features included in the product, but only the executable binary and no test cases are included in the final product delivery.

Applying factory point of view to PLE

Figure 1 illustrates the factory-based PLE approach as applied to the V-model product life cycle. The V-model demonstrates the relationships between each phase of the development cycle and its associated testing phase.

The diagram shows a feature catalog that informs a collection of assets that can be managed according to the features of the product line. These may be a long list of engineering artifacts – bill-of-materials, descriptions, software, system requirements, test cases, and wiring harness instructions are some of the common artifacts in an automotive product.

The feature descriptions go into the PLE process and are used to engineer the feature profiles that cause the products to come out. You’ll notice in the diagram the comprehensive nature of the feature catalog as it feeds into both the development engineering and testing phases of the V-model.

In order to create a specific product, we need a way to filter all these assets. How do we know what to do within the configurator? This is where the bill of features specifications come in. If the feature list includes a feature, the configurator will include that in the assets, based on the bill of features. The configurator uses the bill of features to associate the pieces within the feature profiles to know what to include/exclude from the assets. This drives every engineer working on their part of the system to think about how their assets get used on all the variants of these products within the family. Engineers become skilled at specifying these feature-based variations, and that results in efficiencies up and down the V-model.

“We want all the engineers to create features by accepting the single source of truth throughout the product family,” Dr. Krueger says. “Anywhere there is variability the organization needs to make sure there is a single, common understanding of what the varying features are.”

In order for the process to work, there must be an organizational view of PLE. Dr. Krueger mentions when they begin working with a company often, they are changing the fundamentals of how the organization does their engineering. The BigLever goal is to elevate the organization to this factory point of view. The new engineering mindset is they are creating artifacts that get put into the factory. But the training permeates across all disciplines of the organization in order to be effective.

The first level of decision involves the feature catalog – what features do the organization want to support? Orchestration between engineering, product management and executive management is critical here.

Once the feature catalog is set and the proper bill of features development is understood, engineers can be turned loose. The key concept here is to respect the feature catalog and develop accordingly. All experts are still doing their jobs, but they are doing so realizing there are different flavors defined by the feature catalog.

The second important discipline involves a portfolio team. This is the team that is deciding which specific features are to be included for a given product instance. These people are assembling according to the feature catalog and, in some cases, clustering by sub-families of these features.

The configurator operates on each of the bill of features and a unique V model pops out and pulls out the right assets automatically so every feature specified to be in the product will be included. Once this process has been followed, the automation of assembly and production enables additional efficiencies.

At the end of the day, the PLE process can bring an enormous increase in efficiencies. Resulting in competitive advantage from the process itself in addition to the feature set.

PLE and Agile development

The V-model example may cause the impression that PLE is only applicable to the waterfall mode, but Dr. Krueger says that PLE is development-agnostic.

“Agile processes still have assets [definition of done, user stories, sprint reviews], and these assets can be handled in the same way within the factory view of PLE,” Dr. Krueger says. “The development of each feature may be coming from a user story, but the asset result is the same.”

Real-world factory view PLE examples

The automotive market is finding a significant benefit with a factory view of PLE. General Motors faces one of the most complex PLE challenges in terms of product complexity, multiple options, and high reliability. They call this the “Megascale product line engineering” problem. GM produces on average one vehicle every three seconds somewhere around the world. Each one is considered a member or variant of one single big family of vehicles in the GM organization. They are adopting BigLever solutions to address the massive feature variants their product line entails.

In the military market, Lockheed Martin and Navy have adopted a “fix it once” initiative. They have 100 ships and it’s possible that a defect might go out and be found on a single ship. Once found, there is a cycle to fix it. Later, this same defect may pop up on another ship and the same effort happens. PLE can facilitate a paradigm where you find it once, fix it once, then apply the fix across the entire product line that includes the feature with the defect. This is an extremely valuable part of the solution.

The Lockheed Martin integrated weapons system is deployed in more than 100 ships. By managing a single “family of ships” with variants as defined by a bill of features, they can leverage the factory view of the PLE process. They reported a $47M cost avoidance per year using the BigLever PLE solution and dramatically increasing the productivity by using the Gears approach.

Sound PLE also results in competitive advantage. Lockheed bought in and got good at this solution, and as a result their productivity has increased dramatically. By leveraging the efficiencies in the process, they can deploy projects at lower cost and deliver the same or a superior feature set. In addition, they have capacity to continue advancing and upgrading their capabilities.

In another example, General Dynamics teamed with BigLever to create the winning proposal for the U.S. Army Live Training Transformation “Consolidated Product Line Management.” In this product line of training systems, each soldier has a personal area network connected to a larger network of up to 2,000 soldiers. This can be seen as an interesting Internet of Things (IoT) application. They are monitoring all these data points during maneuvers to detect patterns of activity of individuals and units that they can use as learning and training information to train soldiers on how to be effective and stay alive in the field. Using the BigLever PLE solution, the Army study produced audited numbers that project $600M in cost avoidance over 15 years.

What about small/medium businesses (SMBs)?

The examples cited were from very large organizations with big budgets, but Dr. Krueger claims the factory view of PLE can still be cost effective for start-ups and small businesses alike.

“The pricing scales by the number of people. And smaller organizations are typically faster to adopt the process because there is less to change and fewer existing blocks to overcome,” Dr. Krueger says. “In SMB organizations, saving time for a few key people can make a world of difference in the organizations’ growth potential.”