another attempt at a (knowingly!) overblown “literary” telling of a small event from 2015

The planet cast a long, dark shadow into the stream of light from the system’s star: it was in this occlusion that he travelled, his face lit only by the dim glow of information panels as he sat in warm isolation, snug in the metal and fabric embrace of his cabin. Others were travelling on similar trajectories: this was a well-used if minor conduit between two minor habitations. Interaction was not desired by any traveller, each ensconced in their own, almost foetal, form of high-speed tranquility.

With a silent boom! a photon energy beam burst around him: the surrounding vegetation appeared as a clear, deathly grey-white ghost of itself. He knew: the Blindness was upon him. Then - puzzlement rather than dazzlement: he could still see. His retinas were not seared, the cockpit around him was not melting into an unbearable reaction chamber of light followed by unfathomable patterns on his visual cortex and new depths of darkness. Instead - he was comfortable, and confused.

He checked his rear-view optical sensors, and saw: dim lights. Their coruscating beams danced and glanced in the trees around him, but kept their most piercing lances shielded from his eyes.

Then he recognised the signature shape and form of those lights: they came from a BMW - and could only have been their adaptive LED headlamp system.

He smiled to himself. Our species is just so inventive, he realised, and just doesn’t know when to stop tinkering, even with the most traditional of technologies. Headlights today, interplanetary mood lighting tomorrow, each component and subsystem being developed by whirling and evolving teams of scientists, engineers, manufacturers and - yes - sales people and buyers. Cultural systems enmeshing imperfectly with imperfect electromechanical systems - causing clashes and jolts aplenty - leading to the evolution of the normal. He was glad to be part of it.

posted in 2015, this text was I think an attempt at capturing the solitude and darker thoughts of a sleepless business traveller - and, boy, did I sleep poorly on most business trips (mostly, I now realise, to my FODMAP intolerance to onions and garlic. I clearly wasn’t on a business trip on the 27th of December, but remembering one - probably brought to mind by a similar poor night following a celebratory meal

Disorientated. Where? Dim pre-dawn - or streetlamp - light crept lethargically, reluctantly, unenergetically through a gap between blackout curtains. Energy aplenty thundered in audio form through the window and into the room: sound waves, but not homely. A hotel room. A truck, or a tractor. Almost military. No, not that - but east European. One east European truck or tractor followed by another: agricultural. A church or town hall bell, three simple rings. What in God’s time is it? Yes, three quarters past - quarter to - what?

Where, a hotel room in Romania. When, a quarter to. Who? And why?

Hand stopped half way to reaching smartphone and dropped back onto the bed. Time was unimportant now, as was place. This was him: a family man. This was him: a company man. This was him: an engineer. Half awake, three quarters not there.

So - a company man. Could that be a defining characteristic? If so, then he had changed. If not himself, then at least his company. He didn’t feel that different after all, even if he was now working for the competition. So - not defining. It was a new start, let that be sufficient for now (not this short now - a long now). Fresh perspectives and new beginnings had brought fresh motivation and impetus - surely to fade - but why not enjoy making new connections and revisiting old challenges with fresh eyes?

A company engineer and a family man: plenty of work to be getting on with. Reason enough not to be lying unasleep in a foreign bed, awaiting meetings, reviews, discussions, coffees and presentations with a whole new group of people. For what? Oh, don’t let’s go there now: there is no what for. Especially when the real question is: for whom?

I am why. They are why. You are why I read specifications line by line - especially the ones I have written; why I go through drawings item by item, FMEAs cause by cause, assign component attributes like a librarian, consider new developments like a patent lawyer; test parts, write reports, write emails, write presentations, travel to stranger places than this - and, from time to time, to write about it all here. For the company: your company.

Four more simple rings, followed by four sonorous ones. Two and a half hours to wait for the smartphone to ring, hopefully until then oblivious to time…

I’m writing this between lectures and dinner on the first of a 2-day FMEA forum in Osnabrück and I’m trying to figure out what to make of it all. If that opening sentence fails to give the impression that I’m bubbling with enthusiasm or energy from the day, it’s because - well, I’m not. Of course, sitting around being talked at isn’t the most energising of inactivities itself, but the content shown so far hasn’t fired me up in any significant way.

The theme of the forum is “FMEA success stories” - but those stories have been in fact pretty sparse thus far. Two of today’s main presentations were about their respective companies' efforts and struggles to implement strong FMEA systems and culture into their workflows. One company gave an update on its mission (now into its fifth year of ‘x: unknown’) to implement an FMEA software system and methodology into the group. The other gave a shorter overview of how they’re getting on (or not) as they make a start on the challenge. The takeaway from these presentations was the obvious: yes, it’s difficult to move away from scattered, ineffective but audit-tick-boxable Excel files to a centralised monolith. And, yes, you need executive and management support for such an undertaking. But not even from the company that is so far along the road did I hear a story about benefits. They have basically arrived, but where, and why? I didn’t hear any anecdotes about finding otherwise hidden potential failures, about reducing potential quality issues by humungous amounts, anything like that

One presenter plucked up the courage to show his efforts to convince a director to invest in FMEA via the means of monetary value (another key theme of this forum). Our presenter’s take was that robust and reusable FMEAs help to prevent project overruns - (on the basis that you won’t be validating things too late, and when validated, then with the expectation of OK results), so the most convincing financial metric was in fact time - a shaky assumption if ever there was one, and one that nobody could pluck up the heartlessness to destroy in the Q&A afterwards.

There is a close-knit group of FMEA gurus in Germany, who attend each and every one of these forums. They consult for others, and many of their clients were here, too - so there is certainly a self-appreciative air to the proceedings, of their being a natural and self-explanatory part of the engineering world. Data is less available. But one guru at least mentioned that his research team studied around 500 FMEAs before and after switching to more robust software and methods: the robuster methods rooted out around 30% more potential failure causes than the older versions. He did proceed to weaken his argument somewhat by stating that most of these were repeat or piffling items, and there was no factoring of the “novelty” problem (would these new causes have been arrived at had the systems been analysed with fresh eyes, albeit using older methodologies?) but at least a couple of the new ones could be treated as being noteworthy.

So - these success stories we’re talking about. They are where, exactly?

There was a presentation on making FMEA meetings more effective by trying to eliminate discussions on rating causes (occurrence and detection ratings), and by highlighting the financial aspect of potential risk - but that’s still a very inward-looking process improvement.

A further presentation from two “big” Americans (in the sense of being FMEA-gurus from America) tried to show the differences between the AIAG and the VDA-described methodologies - but that was a thoroughly overblown observation. When I asked if anyone had “raced” AIAG against VDA on the basis of one common design, to test the theory, or even to try and see if one method favoured one type of result over another, the answer I received was an at least nicely succinct “no.”

That discussion all boiled down to “it doesn’t matter which method you use, as long as you use it properly.”

To turn the focus back on success in FMEAs: how can it be measured? Of course, it’s the nature of the FMEA that potential failures are thought up, thought out and minimised - and those thoughts involve (or should involve) a lot of internal company knowledge and evidence. So nobody wants to (or is permitted to) talk about specifics - but with the forum having been so entitled, I’d have thought that the organisers would have found a way to try to tell the stories in a stronger way.

Perhaps, though, in the context of such a forum, they felt they were preaching to the converted, anyway, so didn’t need to do much “selling”.

Click ‘Go’ to start

Generally what an FMEA is trying to do with a mechanical system is to bug-check its logic. Perhaps we could consider a better tool from software development (How Google Tests Software, for example), where a model is created that through a multitude of test runs can quickly highlight the potential week points. That would be even more difficult than manually thinking things through - but cleverer. Perhaps that’s simply where we stand right now: we’re chipping away with post stone-age but pre-steam tools - and doing a pretty decent job of it, we think.

I know, let’s look in the FMEA

A common selling point of the FMEA is its potential (that word again!) to capture a company’s knowledge through lessons learned, updates and actions, linking to evidence and reports, etc. I was also sold on that for a while, but right now I’m less confident about it. After the “5 year-mission to explore new worlds” presentation, I asked how many of that company’s development engineers use the FMEA software. The answer was: none. Of course expert systems can be difficult to drive, but it seems strange to me to have to rely on external moderators to create the FMEAs, and then on searching through pdf documents to find key lessons learned and design considerations.

Where does FMEA belong?

Many of the FMEA colleagues I met so far came from Quality Management - which I feel should be the parking spot for completed FMEAs. But FMEAs that are still themselves under development (theoretically in parallel with the ahem new product that is gestating) should reside with the product- or process-development teams.

I raised this point later over beers and dinner: others countered that engineering students don’t learn about FMEAs in any meaningful way, so they can’t be expected to maintain one as part of their jobs in the same way that quality engineers do: but that’s more of a comment on engineering education than on any philosophical decision to shield development engineers from such shudderingly plodding work as FMEAs (to put a negative twist on it).

Go on, have another beer and lighten up

The key to these FMEA forums is, of course, the networking. Everybody in the field, regardless of product, industry or division (quality or development) has basically the same problems with FMEAs. But few really try to come to terms with what it means, and what benefits the system has. So it was good to meet a few skeptics among the herd who saw the presentations as well-meaning but non-value-add guff, and who also saw the principal value of such forums in the people themselves.

The evening dinner of local Grünkohl and Pinkel sausages in a local Osnabrück brewery (Rampendahl) made for fascinating conversation, especially as I ended up sitting amongst three of the world’s key FMEA software developers.

But now, after some noticeable time-hopping, it’s time to upload this post, grab some breakfast, and get ready for the onslaught of the second day…

It is fair – and not in the slightest bit unusual – to say that we have been struggling to apply our resources properly of late.  My office is nominally dedicated to product development - but, with our well-appointed laboratories on site and our general level of expertise and “seen it all” experience, we’ve ended up having a whole pile of test and validation work to plough through, which, as I’ve pointed out in the past, I personally don’t view as one of this engineering life’s great driving forces.

{An aside: ensuring that your development team is focussing on its job is a perennial battle: a recent article in the Economist on the future of work points out a study done by Pfizer in 2008 which showed that its most highly skilled employees were spending around 20 - 40% of their time on routine work. Now, if I could even get up to 20% development work, I’d be happy…}

Roll up! Roll up! Become a validation engineer!

So - I want to be less involved in validation. This means I need somebody else to do it for me. I’m not a marketing type by any means, so enthusing about something that I despise doesn’t come naturally - but I still need to think through how to “sell” validation to someone else. I need to think things through, which is the general point of a blog, unless I’m very much mistaken - so here goes:

• There are plenty of people who like little more than running around organising things - defining who needs to send what to whom and by when, then chasing up on all those leads.
• There are others who have the ability to create, track, update and check off tasks in lists.
• There are still others who enjoy the mechanical challenge of getting parts to fit into unnatural environments (we don’t necessarily design parts to fit into test chambers)
• There are plenty of people who feel important when they get to put a “pass” or “fail” stamp on things.
• There are engineers who can lose themselves in reading and understanding specifications,
• And there are those who are happiest with the prospect of endless work without much in the line of variation.

A validation engineer needs to combine all of those attributes.

That’s me in the mirror

So which of these attributes don’t I have? Well - to point out the obvious first: I can work on validation (successfully, too, it would appear, as I keep on getting more of it to do!) - I’ve done it for year upon grinding year. I fail dismally at routine and at repetition (validation often requires testing the same set of combinations over and over, from different production locations or tooling sets, for example) and I really have to force myself into ordering precise numbers of components, counterparts, etc, force myself into counting the parts that arrived, and figuring out how to fit them into test equipment.

But it’s largely a condition that borders on the philosophical - validation is at the wrong end of the engineering spectrum for me: it should be the crowning “dumb” step at the end of all the concept, specification, definition, understanding and testing work that constitute the development of a product into something produceable in series. It is validation as in rubber-stamping: this is a valid product; it does what it was expected to do, namely – meet specifications.

Meeting specification is the go gate for product in the “physical” world – not release into the market. We can’t iterate as quickly as app writers can, but also smartphone apps don’t generally have the potential to kill people if they go awry. So the biggest task for an engineer in the traditional industries is to write a cogent, coherent, consistent – and legible – specification that can act as a realistic hurdle and as a decider between good and not good product.

Then, other engineers need to read those specifications. Alas, the percentage of humans who have actually read through, understood and organised test work according to specifications is as vanishingly small as the number of people who actually wrote those specifications still being in that role.

Let’s validate - something - quickly!

As soon as someone, somehow (often based on arcane and mysterious procedures – or company lore – or on a whim) decides that validation testing is required other than as the natural end of a development programme, chaos ensues.

Emails are sent expressing urgency, whilst tacitly acknowledging cluelessness regarding how actually to proceed; priorities are dumped on the already overloaded yet ever-helpful testing team – and above all, the sense of the emails is one of desperate hope. Hope that responsibility can be abdicated, that no further questions will be asked, that no sample parts need to be organised, that timing will be according to promises already made.

Of course validation is urgent, and of course it’s important – in our world you’re simply not permitted to deliver (or be paid for) parts that have not satisfactorily completed validation. It’s just that, for a development engineer, validation (as opposed to development testing) is dull, dull, dull.

There, I said it.

Finally, though, we managed to get some outside help, and we hired a student – more about which in the next post…