The Auto Industry Struggles With Systems Engineering; Reinventing The Wheel

In 2013, Forbes reported that “developing a new car can cost as high as $6 billion,” but that estimate pre-dated the explosion of software from ten million (10M) lines of code in a 2011 Chevy Volt to an estimated billion (1B) lines of code in an autonomous vehicle. It also predated post-Covid inflation and The Great Resignation (e.g., which have exacerbated the skyrocketing costs of designing, coordinating, coding, prototyping and building a new vehicle). All of this would suggest that manufacturers and suppliers alike would be actively searching for ways to minimize the costs of system development, especially to maximize reuse across vehicles, customers and projects.

Ironically, the market has mostly tended in the opposite direction: customer-specific designs with little reuse, thereby increasing costs while decreasing quality and maximizing risk. “It is common for us to find a lot of misunderstanding,” states Deniz Culha-Booher, a Principal Assessor for Kugler Maag Cie. “We frequently find product requirements that are copied exactly from customer-provided information without consideration of all of the stakeholders’ needs for the product.”

The baffling trend has mostly been caused by a few factors – quoting processes, architecture underspending and systems confusion – with only a few savvy executives successfully navigating the impediment-laden path.

Quoting Processes

The normal Statement of Work (SOW) from an automotive manufacturer contains thousands of detailed requirements, which must be synthesized in weeks to provide quotations for millions upon millions in revenue. Ingestion and decisions must be quickly formulated within these short periods of time without great allowance for availability of product experts, software architects and systems engineers. Even if said experts are freed-up from other, critical projects, the short duration allows little brainstorming and technical negotiations between customer and supplier to avoid accidentally-included constraints within the requirements that were over-stipulated by the customer or carryover from a previous SOW and unnecessary for the desired features.

Recommended Solution

Extending the time or having a stable of idle experts are unreasonable changes, so probably the only possible solution is for the manufacturers to better understand systems engineering and how to better specify “what” the product is supposed to achieve as opposed to “how” will it accomplish it. Leaving out unnecessary constraints would allow suppliers to merge the best of requirements amongst all stakeholders and avoid one-off solutions. Not to mention, it might enable “ineffable projects” where less-detailed statements of work permit the better, creative solution amongst competing suppliers to win a greater percentage of the market share.

Architecture Underspending

Be it confusion over the value of architects, the difficulty in training and retaining such talent or the inexplicable trend towards low-cost, offshore staff augmentation for such critical roles, Forbes noted in 2021 that the industry is experiencing a dearth of trained architects. Without such key personnel, it becomes much tougher to create logical abstractions of designs, identify critical elements that might be reusable and design for extensibility. Even if corporations have measured and attained the needed headcount to meet the projects underway, there’s typically a staffing lag on newly-won projects and those early months are critical for designing the system.

Recommended Solution

Recognize the billions being lost by not sufficiently staffing, training and retaining architects and error on the side of overstaffing and over-training these magi of the engineering world. A word of caution, though: they cannot be hired via a staffing company or brought-in by external postings. They must be internally grown with domain knowledge through organic experience. That requires a long-term plan, great understanding of the skills required and focused attention on nurturing the talent.

Systems Confusion

Because of detailed requirements coming from customers, companies are perplexed about the role of systems engineers. Instead of product-level designing and high-level qualification of a product, they end-up acting as quasi-project managers to coordinate the dissemination of details, to track emergent defects with customers and liaise with management about approximations on progress to the desired feature-by-phase plans. “These engineers become seemingly redundant and don’t understand their possible, valuable contribution,” states Culha-Booher. “Too often, the majority of design work — both high level and detailed — is completed before the team has reached a sufficient definition of and agreement upon the feature requirements. This undermines any value of performing a true analysis in the proper order, which may have prevented a failure to deliver the desired content. And since so much is already ‘done,’ the team deplores going backwards. So instead, they eventually must fix a ‘bug’ that was really just a design implemented without a clear understanding of the requirement.”

Recommended Solution

Get the systems engineering team trained on what constitutes better requirements to enable the desired reuse across customers and projects. Thereafter, ask the architect which shall be the critical, base design for a future product and staff a crew to establish a better foundation.

Author’s Note

Maybe the cliché is “pennywise and dollar stupid” since project leaders are attempting to skip steps to supposedly reduce cost and time. Or maybe the root cause is a poor understanding of how to measure the number of resources needed and provide sufficient training.

Whatever the reason, take the time and energy to figure it out upfront. It’ll pay off quickly.