Power of Information

Systems Engineering is one of those things that can be hard to explain and even harder to justify. When it’s done well, no-one notices. When something goes wrong, Systems Engineers are often the first to be blamed.

We are there primarily to reduce risk. On most projects I've worked on, a 1% reduction in risk saves tens of millions of dollars. Simply put, a small improvement makes a big difference.

However, Systems Engineers don't make anything tangible; there is nothing obvious to show for our work – only a lot of documentation that most people don’t value until something goes wrong. However, all these documents contain information, and this is the only instrument available to us.

They say, ‘information is power’, particularly in this Information Age. But the real power of information is not in hoarding it, as Robin Morgan suggests, but to follow Kofi Annan and use it to liberate and educate, to share it with those who need it, when they need it, in a form that they can use.

These then are the core issues for Systems Engineering:

1. Capturing the right information for those who need it

2. Making that information available to them when they need it

3. Presenting the information in a way that is useful to those who need it.

The first challenge we face is the Systems Engineering Management Plan – the “SEMP”. The SEMP defines the process we will use to do these three things. It’s the 'User Manual' for Systems Engineering on a programme. And here lies our first issue: whoever heard of an engineer reading a user manual? At least not until something goes wrong!! The result is that the SEMP is a ‘write-only’ document which adds little value to the Systems Engineering output. It becomes ‘shelf-ware’ whose only purpose is to gather dust.

The bad news is that this is what most Managers think of most Systems Engineering output! It costs lots of money, fills the shelves and adds little value… that is until something goes wrong.

It’s difficult for Managers to see the value of it when, to quote one manager; it feels like you're merely "capturing the blindingly obvious". This chimes with many Systems Engineers I've taught who say it’s just ‘common sense’.

My response is along the lines of Voltaire, "Common sense is not that common", or it’s only obvious when you know. To be clear it’s not that capturing this information is pointless, rather the real challenge is that when Systems Engineering is done well, things don’t go wrong, and the Programme Manager takes the glory.

More practically, how do we make information work for us? How do we stop writing ‘write-only’ documents? One thing we must remember is that most information captured by Systems Engineering is NOT for the benefit of Systems Engineers. It’s for the use of every other discipline. It sets specifications for detail design, for manufacture, for test and anyone engaged in making the product. They do not talk ‘Systems Engineering’, expecting them to do so will always be an up-hill battle.

So what?

Communicate, communicate and communicate!!

Not something engineers are known for! Writing documents is only part of the communication problem – it’s passive. We need to engage people in ways that they can relate to, and make sure it’s two-way – listening first, speaking second. Two ears, one mouth: that's the proportion we need to apply.

Let's start with the SEMP: It's more than just a User Manual or a statement of process intent for the Systems Engineering. It sets the culture for all engineering on a programme: 'the way we do things around here'. It will normally try to break down barriers between disciplines and set the principles of communication between groups. But writing all this down is not sharing it, so the first thing a Systems Engineer must do is communicate the SEMP.

Try having a SEMP workshop across all disciplines: a SEMP Day! Somewhere everyone can discuss what it means to them, and how they will deliver its outputs. Then use the SEMP as part of the induction to the programme so that newcomers understand the way things are done around here.

After the SEMP, the most powerful tool we have for information management is Modelling. More specifically, Model Based Systems Engineering – “MBSE”.

Contrary to what many may think, MBSE is primarily an information management mechanism. The real power of MBSE is that I can capture information in a structured environment, in one place and then present it in different ways. The models (diagrams) are there to present the information to those who need it, in a way that they can understand. It lets me communicate system design concepts in ways that non Systems Engineers can understand.

However, there are three main ways that MBSE fails:

1. Focusing on semantics of a language rather than on consistency of information captured.

2. Focusing on words and labels rather than on shared understanding.

3. Focusing on iconography rather than on communicating.

Remember that the information you’re working with is for other to use. Most of them will have been modelling in their own languages for a lot longer than Systems Engineers have. Electrical Circuits Diagrams, State Diagrams, Logic Diagrams, Process Diagrams, Fault Trees, Bow Tie diagrams and many more, are all forms of modelling languages used by specialists. Some of them have found their way into Systems Engineering language, but they all pre-date MBSE, and they present information in forms familiar to the specialists who use them. There is considerable overlap in the information developed across these languages, and massive opportunity if we can share information more widely.

We cannot expect those who have spent their working lives learning their models suddenly to understand ours. If we spend time understanding their needs, and effort in presenting our MBSE output in a way they can use, then we can provide very good starting material from SE models to ‘seed’ these specialist models. This is communicating. It makes everyone’s life easier, makes the information flow less prone to error and can considerably reduce cost.

Here are some examples:

• Sub-system dependencies, presented and explained correctly, can seed a Fault Tree Analysis.

• Class Architecture and state can be used directly in logic design.

• With effort, object relationship diagrams can be made to look like an RF circuit diagram with appropriate attributes specifying component characteristics.

If you’re smart, then the information that these specialists capture will make your systems models more complete, more robust and more useful. Why not get those who have been doing modelling a lot longer than we have contribute to your models… and be prepared to integrate their language.

As Systems Engineers, all we have to work with is information. The real power of information is in sharing it: communicating. We cannot do that by dictating a new language for everyone else to learn. We can only really do this by making our information accessible to those who need it, in a way that they can use it. And integrate their information in return.