Systems Engineering Appreciation - CPD

In the UK, everyone who is registered with the Engineering Council – and therefore one of the Engineering Institutions such as the IMechE, IET, ICE, etc. – make a commitment to maintain and enhance their competence. In practice, this means undertaking Continuing Professional Development (CPD).

As part of my CPD, I went on a Systems Engineering Appreciation course, run by Dr. Stuart Burge from Burge Hughs Walsh. (Thanks to Dr. Burge for allowing me to use his images).

Systems Engineering is about using different tools and techniques (systems) to solve problems/come up with designs – in a different way to traditional design approaches.

When given a problem, it is in our nature to immediately think of a solution. This not only applies to our work lives but also to everyday lives. Have you ever been told, "Please just listen, I don't need solutions, I need to rant"?

When we are required to come up with a solution, we think that we must come up with one quickly – and as soon as we have what we think may be viable, we stop thinking.

This Dr. Burge termed as "Solutioneering" and he gave some great examples of different types of approaches:

Photocopying
Take existing design and make it bigger/smaller etc. e.g. Tacoma Narrow Bridge.

Flower Arranging
Take previously used components and arrange them to build a "new thing". e.g. IT problems with Universal Credit.

Evolutionary
Successive modifications to an existing design. e.g. Porshe 911.

Pet Pony
Sinclair C5. Enough said.

Research conducted by Carnegie Mellon University [1] found that traditional “solutioneering” approaches have a 1 in 10 chance of getting it right. A Systems Approach to Design gives a 97% chance of getting it right.

The traditional engineering design approaches look like this – and invariably need a redesign:

Currently, we put a lot of effort in the wrong place.

We need to analyse BEFORE we design.

Many problems are obvious to see in hindsight – but were not foreseen. Take the French trains that were too wide for the platforms. Why was this not spotted earlier? Because assumptions were made? Because everyone thought someone else had checked? Other reasons?

The course covered some of the reasons why it is so difficult to spot these "obvious" errors early but also introduced some of the methods that can be used so we are more likely to see them.

The main points about Systems engineering are gathering the requirements – understanding the problem and understanding the functionality of the thing you're trying to design. Which is not how most of us think.

Clients only tell us what their expressed requirements are – which is typically only 20-30% of the full requirement specification. There are a lot of unspoken requirements – assumptions, such as "the new trains will fit in the platforms".

To help us (and our clients) see the full requirements, three steps are required:

1. Systems Thinking – applying the concept of a system to a situation to gain insight and understanding
2. Systems Approach – applying Systems Thinking in a systematic and repeatable way
3. Systems Engineering – taking a Systems Approach to the creation of a system.

Systems Thinking helps us to understand complex situations by:

• Simplifying and clarifying situations to understand the key aspects.
• Allowing different aspects and perceptions to be portrayed and considered at the same time.
• Looking for dependencies and influences between elements to understand and predict what their combined behaviour will be in the future.
• Examining the situation from different perspectives and viewpoints to understand and predict future behaviour.

What is a system?

An assembly of components connected together that as a consequence achieves something – a purpose. Each system is made up of a subsystem –  every time you break something down, it can again be broken down into smaller and smaller systems. And if you look outside of the system, you see it is part of a larger system. (Think 4 Privet Drive, Little Whinging, Surrey, England, UK, Europe, The Earth, The Solar System, The Universe, etc.)

All systems have a purpose, a context, and a structure.

Defining the purpose is not easy! Think of a pen. What's does it do? Put ink on a page? Make marks on paper? Or a method of transferring thoughts into marks on paper? In which case, would a printer and a computer be sufficient? Would a biro work in space? The context matters too. But context is more than just environment – recording something in your diary, on a flip chart or on a Birth Certificate *could* all be done with a Sharpie or a pencil. But sometimes the context requires a different solution.

The structure is often invisible. Imagine an accident blackspot. An accident (or event) happens in the same location time after time. There is a pattern. To work out why the pattern is happening, and therefore why the accidents happen, the structure around the event must be investigated. 

We can react to the event (by having emergency services parked nearby) but to make a real difference a change in the structure is required – maybe traffic lights, different speed limits or even just warning signs.

System Function

In the Figure below, the generic system function is to make toast. The implementation in each example is different.

One tool that can be used to help define the problem is the divergent-convergent thinking process. Each item in the generic system function could be solved differently. For example, "Generate Heat" could be from lasers, friction, fire, fusion energy, etc. By being creative and not making boundaries at the initial "thought" stages, we can have "divergent thinking – generating lots of ideas. Later we can select the best options – that do fit our boundaries, so our ideas converge on the most suitable.

Divergent thinking is concerned with generating ideas or information about a situation or problem.

The convergent thinking is concerned with organising and making sense of the ideas or information.

Confirmation

Confirming – by verification and validation that we are on the right track is also important. 

But to do the confirming, we need to know what the original requirements are!

Gathering Requirements is a very important activity. Usually though, we only gather the expressed needs and expectations and these are often at a detailed level and are full of ambiguity! They often though have enough detail to use the traditional approaches to design – we could “jump” to a solution! However, analysing, and confirming at this stage pays huge dividends later.

Systems engineering is a different way of looking at problems. One that spends more time finding out what is *actually* required and testing any requirements assumptions before actually getting on to detailed design. This goes against many of the traditional "Get me a solution NOW – show me you're working on it" types of management that I have seen. More time (and therefore money) is needed upfront. It's hard to convince optimistic managers that "this will save problems/firefighting/costs later" – when no-one expects their design to fail. But we have seen it time and again – Millenium Bridge, Airbus A380, and white goods and car product recalls. 

I think it's time to take a different approach – a more creative approach, and, having been on this course, I think a systems engineering approach would work well.

I asked Dr. Stuart Burge to explain in his own words what Systems Engineering is all about – here's a 1.5-minute video: 

[1] Elm J.P and Goldenson D.R “The Business Case for Systems Engineering Study: Results of the Systems Engineering Effectiveness Survey”  November 2012 SPECIAL REPORT, CMU/SEI-2012-SR-009, Carnegie Mellon University.