Effectively applying a systems-view to business and technology enables the delivery of a product or system on schedule, within budget, and without latent defects. However, an absent or incapacitated systems engineering role leads to a series of problems with delivering competitive products, especially when product complexity and specialization increase. 

In this article we will discuss how featuring systems engineering as a central discipline is a major step in improving effectiveness in your product development efforts.

Symptoms of Product Development without Systems Engineering

A prevailing view of systems engineering is that it is a peripheral, advisory role whose function is to epoxy the cracks in the product development process. We’ve found that effective systems engineering frequently is the single most important factor in product success, and is often the most overlooked. Below are a number of different ways that a peripheral (or absentee) approach to systems engineering can fail.

Technology companies often find their R&D communities dominated by one technical discipline. Over time, product architecture decisions from the dominant engineering discipline become assumptions that are deeply embedded throughout the product and organization. 

When the product’s market shifts toward other engineering disciplines problems arise, as new capabilities are hamstrung by organizational culture and embedded assumptions. Consider the automotive industry’s evolution from mechanical, to electrical, to software-driven processes.

For many products, markets are fairly well defined and homogeneous. Once a firm releases a competitive product, subsequent versions offer add-on features and improved attributes like usability, reliability, and throughput. Difficulties arise when market needs undergo a shift, or there is a major discontinuity in the solution space. 

The main determinant of a firm’s ability to respond to these changes is the quality of the system architecture in its products. A patchwork design with tightly-coupled components, poor separation of concerns and functions, and inconsistent patterns of control will be more difficult to change and much more costly to test than a system whose architecture has principles of organization and operation that are well-aligned with the underlying problem.

Many times, markets aren’t so well defined and homogeneous. Customers use the same products in different ways and demand varying sets of capabilities. Consider how many ways people use cell phones. Competitive products offer attractive features that threaten to erode market share if new product introductions are late. Often product managers underestimate the complexities of features, are caught unaware by unexpected conflicts, or fail to see critical tradeoffs.

Our experience shows that 60 percent or more of the total cost of ownership of even the best software-intensive products comes after the initial market release. When development teams make excessive compromises, or create a product with a poor system design, this percentage escalates.

Frequently, market requirements are rife with risks, obstacles, and poorly defined assumptions. Requirements essential to one set of customers often conflict with requirements from others. Others pose safety hazards, conflict with physical constraints, infringe on patents, or have unrealistic time frames. 

In organizations without effective systems engineering groups, these tradeoff decisions often fall to the project (or program) manager. People in these roles have backgrounds that are best-suited to manage budget or schedule issues, and may not fully comprehend tradeoffs and risks which span across several areas of technical expertise.

Every system architecture must change over time as new problems are uncovered and new technologies acquired. Whenever a new version of a product is planned, a fundamental choice must be made: build on top of the existing architecture, or reorganize the existing architecture to provide a more suitable platform.

In product development, this is the ultimate “pay me now, or pay me later” challenge. In the short run, system reorganization takes some additional time and cost, but in the long run, a more suitable architecture can pay huge dividends. 

In contrast, building on top of the existing architecture is more expedient, but it incurs technical debt. The amount of debt and its interest rate vary according to how suitable the original architecture is to support the new features.

Increasing Effectiveness with Systems Engineering

The previous section discusses a number of common scenarios to highlight how problems can develop without a balanced systems view. Next, several ways to improve product development effectiveness through systems engineering will be described.

Systems Engineering & Product Development Process

In order to obtain successful, repeatable product development results, systems engineering must have a central role, from concept through deployment. This can be a difficult transition for many companies. As previously described many companies evolve with a single dominate technical discipline. Altering the relative importance of technical trade-offs and decision making often becomes personal.  

Product development success means creating the right product, with the right quality, for the right cost, at the right time. This means making effective product-wide tradeoff decisions, managing risks, and overcoming challenges. 

This process must be led by someone with customer insight, business acumen and broad technical experience. System-wide objectives must be clearly communicated and translated for all stakeholders.

Identify True Sources of Value

Product success is only partly about creating a great product. Customers typically strive to solve their own business problems. Buying a company’s products is only a means to an end. Creating value in a customer’s environment requires understanding the structure, interrelationships and dynamics of value chains. 

In addition, for any product that has multiple uses, a complex network of interconnected value chains emerges. Making the most of complex and evolving systems is a central objective of systems engineering. 

Address Cross-Functional Obstacles & Risks

Modern products require integration of many disciplines, such as electrical, chemical, mechanical and software engineering, manufacturing, supply chain management, distribution channels, and service and support. The time and effort required to become an expert in any of these areas precludes people from becoming expert in multiple areas. 

Frequently, experts in one discipline understand the complexities and risks in their own disciplines, but undervalue those in related areas.

Good systems engineers communicate with domain experts and understand how things work. They construct models of complex structures, interactions and dynamics, which enable them to understand key relationships, anticipate potential problems and continuously evaluate contingencies.

Derive Requirements & System Architecture from Customer Values

In less effective organizations, customer value is translated into requirements by product marketing then handed off to engineering to design and implement. When customer needs are translated directly into requirements, decisions often unintentionally limit the solution, sacrifice leverage, or reduce value.

Organizations that use systems engineering effectively involve systems engineers early in the product planning process. They meet with customers and seek to understand the root problem. When solutions are presented, they drill beneath the surface to better understand the reasons why that solution is preferred. They also examine what will be required, in terms of investment, cost, time and risk mitigation to deliver this value.

Maintain System Requirements Alignment

Good requirements need to be clear, concise, consistent, and complete. Clear and concise requirements are relatively easy to verify atomically. However, consistency and completeness are systemic properties, and much harder to verify without a reference architecture.

Similarly, when the systems engineer allocates system requirements to functional areas, each functional area develops its own more detailed requirements, tracing each back to the system requirements which motivate it. If conflicts occur at the design level, the traceability between requirements and systems architecture decisions highlight the constraints, risks and tradeoffs, which must be considered to resolve these conflicts.

Prepare For Surprises

The value of the systems engineer does not stop at initial design. Surprises often occur when system components don’t work as planned. For example, a key part from an external supplier doesn’t meet specification, or a competitor introduces a major new product.

The system engineer’s breadth of knowledge about the system’s theory of operation is supplemented by the requirements-systems architecture traces to frame the evaluation of alternative solutions. Good systems engineers use this understanding to anticipate unintended side effects.

Conclusion

Systems engineering is a powerful capability that frequently is underutilized by product development organizations. Some companies are suffering delays, cost overruns, and cancellations that can be attributed to a lack of systems engineering. Other companies have temporarily avoided these consequences, often by having a product that is dominated by one engineering discipline.

Going forward, it is quite likely that underlying technologies will become more complex, software will become an increasingly important contributor to product value, and product interoperability and integration will become more critical. Each of these changes will only increase the need for effective systems engineering.