Systems Engineering Product Innovation.
Dog-food uneaten...

Systems engineering is a kind of ‘engineering of engineering’ specialism. Grounded in Systems Thinking (the mother and father of Design Thinking), It uses deduction, iteration, evaluation and validation rather than post its and inspiration to solve complex engineering design problems. But the same principle applies : Don't rush to solution until a few options have been found and thought through.

​

I was asked by a systems engineering company to help them with a new product. A development team was building the systems engineering tool that the leadership was sure would be a game changer. But they couldn't describe it succinctly and weren't sure who it was for. A month into the build things were unravelling. There were red lights, the prototype was similar to the tool it was to replace; the design concept was only in the CEOs head and future users and customers were not involved in the design in any way....

 

I’ve worked with systems engineers, and I’m signed up to the systems ethos, but their requirements management tools are clunky and complex and need alot of expertise to use. There is a clear opportunity for better tools, but the incumbents are entrenched in the industry, and change will be costly. It also won’t occur without a great user-centred challenger-product delivered with strategic market thinking.

 

The company asked me to help get the project back on track and I spent a month understanding and clarifying the concept and it’s market, before proposing a re-start based on an understanding of intended user and customer requirements - strong medicine, but imo the only solution was to learn the lessons that could be learned and start again.

​

But the sunk costs bias trapped the client, and they were also fearful that user involvement in tool-design might risk their intellectual property. A reluctance to rewind was linked to a hope that a magic bullet could be found to let them continue the build.

​

Out of magic bullets, I stepped away and reflected on the bear traps that lie in wait for companies for whom faith is the driving force in their product thinking; who believe that great ideas are just a step away from great products and who don’t engage customers and user in the concept designs, perhaps because the quality and utility of their solution seems self-evident to them.

 

REFLECTIONS ON THE SYSTEMS ENGINEER'S ROLE & THEIR TOOLS

 

Identifying, understanding and managing abstractions in system specification is the bread and butter of systems engineering. When design/building any system - a car, a sound system, a railway, an aircraft, a ship, a road network, a vaccine - systems engineering will, at it’s most pure, start with an abstract solution-agnostic requirement that can be met in anyway as long as it respects known and ‘to be known’ design constraints.

 

Imagine I create a top level requirement for something I want such as “let me enjoy the {my favourite band} back catalogue whenever and wherever I want to”. This requirement can be met in many ways. It doesn’t have to involve a technology -  I could for example hire the band to follow me round and play whenever I fancy it. This meets my requirement but it’s probably going to get knocked out pretty early in the process because my budget of £150 won’t cut it or or inexplicably, the band may not want the gig.

 

The systems engineer sets out to decompose my requirement into smaller manageable elements by breaking it into packages of sub-ordinate requirements, that are in turn evaluated/ tested for feasibility and then rejected or further considered -  spawning more levels of analysis.

 

Level by level the process proceeds through obvious and not so obvious options to meet my requirement, generating and eliminating solutions that might work - until we (presumably) end up with some kind of portable music playing technology a bit like the original iPod with a pre-loaded catalogue (an idea that was current in the mobile handset industry around 2006, just before the iPhone emerged).

 

At each stage, other relevant engineering specialisms such as materials, risk, hazard, electronics, mechanical, human factors etc are brought in to review the system options for feasibility and implications and so it proceeds.

 

An apparently simple requirement to listen to some music anywhere could quickly cascade into hundreds of requirements and form a large pyramid of requirement/review/feasibility cycles - and ‘tests’ to determine if the requirement is truly met. This latter stage of test goes ‘up’ the other side of the ‘V’ in the systems engineering requirements validation process and is pretty similar to a stage in the double-diamond design process (which was developed later).

 

Done properly, the systems engineer identifies, considers, weights and integrates *all* the potential components of a system. Like geological strata, layer upon layer of requirements are laid down - each one decomposing from a more abstracted upper level downwards towards more tangible levels. Calling on other engineering specialisms to do the hands on engineering-design-heavy-lifting when necessary.

 

A JOB MADE HARDER BY ARCANE AND ARCHAIC TOOLSETS

 

On paper, system engineers have relatively straightforward jobs that requires a way of way of thinking about things (systems thinking) and the ability to build, track and manage large requirements and solution sets. But complexity exists because for the management of these requirements sets, systems engineers use horrendously clunky labyrinthine tools that haven’t really changed in 25 years - tools that may have been developed for other functions that have since morphed into patchwork leviathans that seems to have taken the concept of ‘work-around’ as a central design tenet in their own specification. The tools are not designed with the task of the systems engineer in mind (which is ironic), and the work that goes into managing the tools makes their jobs much much more complicated.  One such system is called DOORS, it characterises all of these drawbacks, but others similar systems also exist.

 

What systems engineers clearly need are tools designed around their needs, in other words User-Centric Product Design.