The Brexit FMEA

The Brexit pre-mortem: BFMEA

Of all the engineering tools that I have encountered, the one that spans the widest spectrum of respect and scorn, hope and despair is the FMEA, the Failure Mode and Effects Analysis.

Developed by the US military and NASA and gradually adopted by the automotive industry from the 1970s onwards, it is intended to highlight things that could go wrong before they do; it's also a way of collecting and tracking the evidence (models, test reports, etc) that shows that the nuts and bolts have been proven before putting them on a rocket - or, indeed, jettisoning a country out of the European Union.

At its heart, the FMEA is a "what if?" analysis. Other methods are available, like the Potential Problem Analysis from Kepner-Tregoe. But I'm automotive, and the FMEA is a requirement in our field, so I've sketched up how a BFMEA (Brexit Failure Mode and Effects Analysis) might have been constructed and eventually look like. Why? Because I simply don't get the impression that the British government perceived the need for any such thinking before diving in to the apparently urgent political necessity that was the Brexit referendum result. And also, because sketching one up isn't all that hard - with practice.

Building the structure

First of all, you need to define what your product or system is, perhaps by following what was defined in the project scope (ABQP). The FMEA might be for a full system, or it might be for an individual component that fits into that system: For our purposes now, it's Brexit. Brexit has a few functions and requirements that I cobbled together in five minutes (naturally with no little help from hindsight):

What could possibly go wrong (failures)?

With an FMEA, you focus on failures first and foremost (it can be a depressing trudge, initially, which is why engineers are always so miserable. Are we? We must be). Put yourself in Law-maker Murphy's shoes, maybe even his socks and underwear, too. The fresh ones.

Then "all" you need to do is to go through each of your functions, wishes, desires, needs, etc: and define all the ways they can fail (one more example here):

How could it come to this (causes)?

If failures are the symptoms, then causes are the bugs that deserve our attention. 

Again, with every failure having its very own potential cause, or causes, we need to repeat the trudge around the houses. I've kept it relatively simple here:

Somebody will have to do something about this (actions)!

The whole point of the FMEA is to discover potential failures and to cut them off at the source: we don't want those bugs getting in that resulted in us hollering into the toilet bowl. So the positive aspect of the FMEA is assigning to-dos to each cause, like "make sure you wash your hands before eating", with the intention of preventing those causes from occurring in the first place (absent a time machine):

So much to do! Where to start (Effects)?

There's one letter we haven't touched in the FMEA yet: the E. Effects. Determining what happens as a result of the failures can be useful in figuring out what actions should be prioritised. You might for example preferentially allocate work on avoiding failures that would otherwise result in conflict on the Irish border over events that would lead to slightly less curved cucumbers still landing on British shores.

But understanding where to prioritise political effects (disgruntlement amongst 48% of voters, for example) is beyond my realm of experience, and represents a clear disconnect between the "plodding reality" of engineering and the human rationality (in all its technical irrationality) that defines politics. Some things might not be "prioritisable" at all. At least until someone works out an official Happiness scale that would be able to balance lots of low-level general contentment (hey, being in the EU isn't actually all that bad most of the time) against intense doses of uproar (they're defining cucumbers again!). Do I digress? I believe I do.

Presenting the BFMEA

Typically, FMEAs aren't presented in the network style that I employed to build mine: the traditional method is the worksheet, which typically leads teams to try and build them in Excel or similar. This is what mine would look like in that format.

It's OK, but a bit sterile. Which is I suppose how it should be. Right? "Real" FMEAs have ratings numbers that help in the prioritisation of tasks, which I have omitted here.

Build and forget?

The FMEA is intended to be a so-called "living document". As new events occur and lessons are (ha!) learned; as new and fantastical failure modes with subtle, complex, causes are discovered, the FMEA grows: often becoming unmanageable, or at least rather unwelcoming in the process. Unless someone or some team is really "living" complex FMEAs as a role, they will bulk up, dry out and fossilise.

In one sense, that's not necessarily a bad thing: if at least in the act of setting it up important considerations were made in that emotionless setting, potentially resulting in actions being taken that avoided some grand faux pas or other, then it will have been useful without too much investment in resources.

Do they? Can they?

It would be fascinating to find out what methods the British Government has at its disposal (and which were used thus far): because, to all appearances, they weren't.

Perhaps they're saving them for the debates surrounding the re-entry into Europe, then.

BFMEA network and other points

Here's the network FMEA that I built up over the weekend. To those engineers reading this who are experienced in FMEA methods: I acknowledge the existence of Occurrence and Detection items. I didn't bother with ratings, as FMEAs can really get bogged down with them - but some sort of prioritisation is required, of course. To those outside of my industry: have you encountered similar "constricted thinking" methods? It would be fascinating to hear from you!