Is Digital Our Opportunity to Reset the Perception of Systems Engineering?

Those intimately familiar with systems engineering recognize the value it brings to projects and organizations. The 2012 study, The Business Case for Systems Engineering, quantified the connection between the application of systems engineering best practices and project performance. Even without this study, systems engineers intuitively understand the law of conservation of systems engineering. It’s simply a question of whether we do it early when it is most effective or at integration and test when things don’t work. But others have a much different perception of systems engineering and those who perform it: “Systems engineering is just a bunch of processes and overhead … systems engineers only produce paper (or drawings) … it’s best to keep them out of the way so that they don’t slow down the program.”

Perceptions are hard to argue with and even harder to change. But perhaps there is an opportunity before us. Perhaps digital engineering and model-based systems engineering done well are our opportunity to reset perceptions for systems engineering and all those who practice it.

First, understand the as-is

To change perception, we should first understand the roots of the current mindset. While systems engineering can be a somewhat abstract concept that is difficult to frame and explain, the reality is that systems engineering as a profession has largely earned the reputation of being burdensome. There are great examples of systems engineering which deliver tremendous value, and there are examples of systems engineering performed poorly or in name only – but this can be said of many different practices.

So what is different about systems engineering? Often, we retreat into jargon and hide behind complexity rather than explaining systems engineering in a manner accessible to executives, stakeholders, and society at large. We often place process execution – rather than value, outcome, or other contribution – front and center. This even includes the International Council on Systems Engineering’s definition, which states, “Systems Engineering is an engineering discipline whose responsibility is creating and executing an interdisciplinary process …” Unlike other engineers, our efforts do not directly yield tangible products such as mechanical assemblies, circuit boards, wings, bridges, or even running software. Instead, our primary tangible output is often stacks of specifications or drawings. So when viewed from the perspective of anyone but a systems engineer, it’s easy to see how our language, emphasis, and outputs contribute to the perception of systems engineers as process police and paper producers.

What is our response?

So what can we do about this?

• Argue that the perception is uninformed and unfair. Many have argued this subjectively for decades, and we now have objective data to bolster the argument. Unfortunately, arguing on facts alone rarely changes minds. As Ben Franklin once said, “A man convinced against his will, is of the same opinion still.”
• Adopt new language in the way we talk about systems engineering. This is something we absolutely must do, and yet – it is necessary, but not sufficient. While we can continue to use technical language with other practitioners, we should not hide behind jargon when explaining the practice, outcomes, and value to others. In making this shift, we should also seek to educate and include rather than obscure and exclude so that we increase the overall level of systems literacy, understanding, and ownership. Rather than reveling in complexity, we should embrace Einstein’s guidance that “Everything should be made as simple as possible, but not simpler.” A good starting point is Stanley McChrystal’s framing of systems and systems engineering in Team of Teams. (I wrote about General McChrystal’s book some in my November post, The Quest for Shared Cognition.)
• Reposition what we do and the value we bring. The risk in repositioning is that others may perceive it simply as rebranding – all the same challenges and lack of value simply dressed differently to make it more presentable. It is here that the digital transformation offers an opportunity. As a society, we are conditioned to expect changes when “digital” is introduced, and as purveyors and practitioners of systems engineering, we should leverage this expectation to reposition the practice and the corresponding value to create new perceptions of systems engineering.

But isn’t this what we have been doing for more than a decade? After all, we have been focusing on model-based systems engineering and transforming systems engineering through model-based approaches. The problem is our language and positioning falls into many of the same traps that contribute to the existing perception issues.

Semantics and our choices going forward

While perhaps it is clear to some, “model-based” is a phrase that evokes confusion for many. (To be fair, my experience is that the varied interpretations and understanding of model-based within the systems engineering community reflects great confusion as well.) “Digital,” however, evokes at least the impression of understanding and therefore provides a starting point for clarification. More than that, model-based is inward looking, focused on how we do our job as systems engineers. Digital engineering and digital thread are outward looking, focused on how our organizations execute the product lifecycle to deliver value. That may seem like a semantic game with little factual relevance. The reality is that the difference in word choice and orientation makes all the difference.

Moving from model-based to digital may be a beginning, but there is far more we must do if we want to use this unique opportunity to change perceptions. Rather than emphasizing processes, methods, and tools, we must pivot and frame our contributions in the language of our businesses and of society at large.

Specific steps we can take

Rather than speaking of a generic practice and toolkit that can be applied to any problem of requisite complication or complexity, we must speak of the business problem and our ability to address it, by:

• Addressing complexity through an enhanced understanding of the problem and solution, seeking shared cognition and appreciation of the relationships and interactions which drive product capabilities
• Providing a disciplined basis for projecting system performance, integrating analysis with architecture from first concept through detailed design, understanding Nth-order impacts of changes
• Accelerating time to market through streamlined workflow and increased use of simulation and virtual prototyping for product verification and validation
• Enabling the effective management of product configurations and product line engineering, supporting multiple requirement sets and multiple market segments
• Managing evolution of a deployed product throughout its lifetime with confidence that upgrades and enhancements deliver new value, not new problems
• Providing security (in particular, cybersecurity), safety, system health, and resilience in the changing environment of today’s interconnected world

These are just a subset of possible framings within a given business. While it’s appealing to look to generic faster, better, cheaper benefits or pursue all the potential benefits of systems engineering, our messaging is far more concrete and impactful if we do so within the context of our given business.

While messaging is key to perception, aligning to the business need is key to the pivot in execution. If quality truly is job one, the journey to digital engineering (and the systems engineering that supports it) will take one path. If it’s all about variant management, the journey and the outcome are different.

Next-level changes

At the next level, there are specific expectations for how digital can transform engineering. Drawing from Digital Model-Based Engineering: Expectations, Prerequisites, and Challenges of Infusion (July 2017), these include:

• Informed decision-making through increased transparency and greater insight
• Enhanced communication
• Increased understanding for greater flexibility / adaptability in design
• Increased performance that the capability will perform as expected
• Increased efficiency

All of these represent benefits that systems engineering can offer subject matter experts, design engineers, and other colleagues in the engineering enterprise as we seek to deliver new capabilities. The key, however, is that the focus must be enabling the greater scope, workflow, and enterprise through digital engineering rather than simply systems engineering through model-based.

This is a pivot in language, but even more, it is a change in mindset. It emphasizes connecting to the needs and workflow of the enterprise, serving it in a high value and high fidelity manner. It’s a very different perspective and perception than systems engineering as process police and paper producers!

The megatrend of digitization is transforming our world. If we embrace and leverage this appropriately, digital offers systems engineering a unique opportunity to transform perceptions. It won’t happen automatically – we must be deliberate. We can’t just be executing processes, managing requirements, or drawing pictures. We can enable digital engineering to better serve our project teams and better meet our business objectives. And we can engineer the journey to achieve the desired outcomes, both new enterprise capabilities and new, high-value perceptions of systems engineering. Both are transformations worth achieving.