The problem with Systems Engineering...

I should probably start by explaining that these are personal views only, and generated from over a decade's worth of experience, mostly in military engineering either working for, or with direct contact with Systems Engineering departments and engineers. There are a wealth of examples I have not included, most supporting but a few contradicting the below arguments and analysis; of course there are always exceptions to any rule and the below sums up the overwhelming majority of my experiences so far over a number of companies with a variety of approaches.

Systems Engineering is generally defined as an ‘interdisciplinary approach and means to enable the realization of successful systems’ and ‘focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem’ (as stated by INCOSE). It aims to consider engineering systems as a whole rather than to just concentrate on one particular component within them.

This approach has been wholeheartedly embraced by military and government companies and agencies and relatively large systems engineering departments have grown which are now central to most large projects. This approach isn’t quite so prevalent in other industrial sectors, however, which tend to rely on the more “traditional” mechanical, electrical and software core with additional specialists under a chief engineer or technical lead.

The key problem arises because in practice systems engineering doesn’t work like this. Most ‘systems engineers’ are not truly multi-disciplinary engineers and are more akin to project engineers or project managers in both form and function. There seems to be an ingrained belief that to run a successful project a company will use ‘robust processes’ (creating or borrowing any that do not already exist), apply ‘systems engineering principles’, crank the handle and out will plop a perfectly adequate product. And it generally does, but the price for this ‘low-risk’ approach is a bloated team structure, an extremely high project cost and a long development and production phase. The final product, due to the processes and checks performed along the way (refer to the systems engineering ‘V’ model below) ‘does what it says on the tin’ but nothing more, because the systems engineering ideal of multi-disciplinary operation which should pick up on the interactions between requirements hasn’t been properly implemented. In fact, it is not only not implemented, it is actively repressed. The term ‘scope creep’ is often mentioned alongside poorly performing projects and refers to changes in base requirements or functionality (usually but not always initiated by the customer) that have negative time, cost and resource implications on the project, and has led to a somewhat blinkered approach to requirement analysis and test. The segregation of requirements is further emphasised due to the content of military projects where specialist or security restricted components are utilised (biased away from multi-disciplinary engineering) leading to exponential increases in effort and documentation. Therefore requirement interactions aren’t addressed and the product is never or poorly optimised, a fact that is in part recognised by the industry and summed up with the statement that the product shouldn’t or won’t be ‘gold plated’. In non systems-engineering led companies (which to be fair generally have less complex systems/products) this doesn’t happen so much and is helped (especially in automotive and consumer electronics sectors) by an emphasis on cost reduction across all disciplines leading to cross-department communication and negotiation.

Diagram courtesy of "Clarus Concept of Operations", Publication No. FHWA-JPO-05-072, 

Federal Highway Administration (FHWA), 2005

A suitable but flippant analogy might be the rise of the modern pop industry where there are a set of well documented ‘processes’ involved in releasing a new song (usually involving a televised competition, a set of calculated press releases and stories, a generic and simplistic backing track, some nursery-rhyme lyrics and a revealing stage costume) which almost guarantee a high volume of sales for what is by any standard a low quality product (if strangely popular).

The advent of CAD, for example, has totally transformed the front end of mechanical engineering, but it has led to a reliance on technology in designing components. There are still occasions when a bit of cardboard and some tape to make a space model is quicker and more informative than computer modelling, but that is not what the process dictates and is shunned in favour of a computer screen.

Modelling, also, is now seriously considered as part of the process, probably reducing the prototyping phase of development, but is only really beneficial if models created are validated on actual hardware. This validation step can easily be skimmed over, with 'proof' of a component or subsystems requirement compliance shown on a computer screen or presentation media and another valuable link to actual hands-on engineering is diminished.

But none of this is to say that these processes should be removed. Far from it! What it does say is that common sense should be applied in the first instance, and these processes invoked where they are necessary or beneficial (and in no way should safety be bypassed). In general, the earlier in the lifecycle, the less that processes should be mandatory, and as a product progresses through design, modelling and prototype stages they should become more important, becoming mandatory in production and beyond. It should be down to the discretion of the engineers performing these tasks, and it inevitably comes back around to the original problem that there simply aren’t enough truly multi-disciplined engineers and too many project engineers (or however they prefer to call themselves). If we can solve this problem, it should drastically reduce product development times and optimise products (in terms of cost and functionality), which in turn will greatly benefit active military personnel and the taxpayer. It will, essentially, recover some of the flair and innovation that has been lost in engineering over the past years and recent projects. But as this will also increase risk and likely decrease profits for the companies involved, it is unlikely to happen without external intervention (although note that the product cost itself should be reduced which might explain why non-military sectors use more traditional methods in favour of a ‘systems engineering approach’).

I’ll (perhaps controversially) define a multi-disciplined engineer as one who has the base understanding of and ability to apply engineering first principles to understand and solve any engineering problem. These engineers will have applied this knowledge first-hand and are not afraid to try new things, assuming those things are well understood.