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

Click 'Go' to start

Where does FMEA belong?

Related articles

Please read this procedure

Fresh perspectives and fresh air in Detroit

Bridging the tumult and the oasis

Statistical data on global software development industry / market size

Sustaining and disruptive innovations

an attribute which this post could not be accused of posessing

Cycling back home from the industrial estate where I work in an otherwise romantic Heidelberg, I cross a bridge that soars over a main road with its gemütlich evening rush hour jams, and, in the same leap, over an idyllische railway line to Mannheim. The bridge, though acting here only as the scenery for the introduction to this post, would be worthy of a blog post itself in the hands of one more knowledgable and appreciative of its design. It is certainly more complex than normal, with a second cycle path spiralling up between road and rail to meet mine.

The thing is, when I'm cycling back from work, this tributary deposits riders cycling up it directly onto my side of the road. This isn't of itself a problem - I can move over to leave them room. But when I do this, we both end up cycling on the wrong side of the road, also known in England as the correct side of the road.

Over the years I have imagined myself commenting to the other riders: "Oh, you're English too?" Only I've never dared. Not only because I'm quite so brazen, but because the grammar of saying it in German is so tricky to get pithily right that we'll have crossed before I've had a chance to parse it, especially if the person on the other bike is a lady.

Yes, it is with a weary sigh that I note that German, like Latin and some others I could probably research for you, is a language that feels the need for three genders. Echoing our stereotypes of German structuredness, the language can be viewed as a series of matrices, with lattices of cases and word endings that can either be viewed as ladders to a higher plane of language, or linguistic snakes that will land you in grammatical trouble wherever you misstep.

Mark Twain certainly had great fun pointing out the bizarre logic of this supposedly highly logical language in his essay "The Awful German Language"

What this baroque structure does offer is an unusual form of efficiency. Word endings become signifiers to what action is being done by whom to what, if at all. So, in the name of efficiency, I could refer to an English lady as an "Engländerin" - two distinct words implicated by the ending of just one.

The flip side of that efficiency, however, is a certain fragility: if, after drafting a phrase, I want to change the subject noun to a word of a different gender (or, in the more likely scenario, I find that the gender I had assumed was wrong), I have to wade back through the whole sentence, changing and correcting word endings scattered throughout it to something different. If I was fed up with Eine kleine Nachtmusik  I could go for a small nightcap instead - Ein kleiner Schlummertrunk, meaning I have changed all three words in that sentence (and that's without the accusative case of me actively wanting one...)

So German and its relatives are efficient when things go right, but each error results in a cascade of compound grammatical catastrophes. I find English to be more robust to errors: a glitch in one portion of a sentence doesn't have to mean a complete rewrite. "The" is "the" whatever grammatical chaos is going on around it.

So this post is really all about efficiency and where it should be applied.

There seem to me to be three distinct strategies available:

1. Being highly efficient in one way
2. Being efficient enough in multiple ways
3. Enabling functionality in as many ways as possible

Mechanical components are generally efficient in one way, but if they go wrong, they are broken and need to be replaced. Highly-strung systems will also break with the loss of a first component, and may even result in losing a chain of components, as in a German sentence.

Systems can add robustness through redundancy. This is generally at the cost of efficiency, but usually can be said to be efficient enough.

Enabling functionality in multiple ways is reflective of the organic, of the free-form, of the gnarly - yes, of language, too. It's not often possible to attain this in mechanical engineering - I'm struggling to think of an example here, but perhaps sacrificial anti-corrosion coatings is one, where a scratch leads to corrosion of one material that results in the protection of another.

But when we're designing our product, irrespective of its apparent simplicity, we can always consider the efficiencies going on around it. We need to design for safety, for cost-efficiency, for energy efficiency - for a product's whole lifecycle. And if we can step away from the fragile and towards the organic in considering the world our product inhabits, we can perhaps go a long way towards attaining the maximal efficiency over the long term. Nature managed it, anyway!   Escaping from the semi-philosophical and going back to my bike problem; because of this ability in German to feminise words, either I could ask "sind Sie auch Engländerin?", which would be efficient, but would, through that word auch meaning also imply that I was also female, or I could ask "sind Sie such Engländer?" implying that she was male.   Mixing things up to avoid the problem ("kommen Sie such aus England?" - do you also come from England?) would be an option, but none of the alternatives is as concise as the original thought.

So I have never dared ask... And I expect that's fine by the good ladies of Heidelberg.

Engineers, like lawyers - hold on, I didn't just write that, did I? Well, it's a valid thought, so I'll press on. Engineers, like lawyers and other animals, can be classified into distinct genera and species, depending on the path we take within our chosen vocation.

As soon as I had, whilst at school, settled on engineering as the subject I wanted to study and practice, it was clear to me that I was much more of a "boffin" type than a "hacker". I was always uneasy about mending things, more confident about designing and working things out - so I opted for aerospace engineering. After graduation I went to Ford (emphatically not an aerospace company, despite its history and current CEO). There, I spent some time working in Manufacturing Engineering. I enjoyed the challenge, at times, but I wanted out, back to component and design engineering.

Who cares how it's made?

Now, my job is (should be) to develop and upgrade product so that it does what it is supposed to, when it is supposed to do it under all conceivable conditions. Whilst it sounds almost blasphemous to say it in these enlightened days of openness and collaboration, I don't necessarily care how it arrives at that point, as long as the how of its making doesn't affect the if of its functionality, or its cost too much.

Of course, this means that I do have to care about the process, as it more often than not does affect the product in clear or in subtle ways. So I talk to our process and manufacturing engineers.

Who are, of course, also design engineers.

I suppose we have all settled into a kind of shorthand for engineering titles, as the word "design" is redundant. There are those who design and develop product, those who design and develop the process, and those who design and develop the equipment to be used in the process to make the product designed at the outset (process product design, or something like that!).

By and large, from my experience, process and manufacturing engineers are cut from a different cloth to product engineers. They can work together, but rarely does one stay in the other's shoes for long. At the extremes, you could envisage the gnarly manufacturing engineer and the soft white-handed product engineer - of course, these types meld and merge, but the tendency is there, I feel.

And we talk.

Silos or troughs

Whether I "get to" talk to these colleagues, or "have to" depends on personalities - which, fortunately, engineers don't have - but where I work, we are distinct groups that need to be brought together on a project by project basis; we need to jump those famous silos to work together, rather than always being together, feeding from the same trough - perhaps "collaborating freely" would be a better turn of phrase.

Our means of communication is still principally email, alas. Our offices are close enough to walk to, but all too often, simply waltzing into each others' enclosures means a disruption of some sort. We're all busy people, who need to try and focus on some one thing at a time. Disturbances from outside, whilst of course important, mean a reshifting of focus from some other, hopefully equally important, activity. So to minimise the growling, we email or invite each other to short meetings, which is really the best method to have disparate minds alight on the one subject for a few quality minutes.

So, we have feasibility reviews, we cooperate on FMEAs (still too infrequently), we sketch, we negotiate (more often than not on tolerances), and we make, measure, test, update and approve our product.

We work together, in short.

Ideally, I should embed myself in their world so that my designs flow and interact as smoothly as possible with theirs, and their reflect the functions that the product needs to have. In small, dedicated teams, that could work, but currently it's all about snatching time to work on one thing rather than another: even were I to share a desk with them, all we'd be doing is shouting over each others' telephone calls.

So I'll stick to my "ivory tower" (as of course they call it), for the time being.

In praise of process

But from that tower, from behind this screen, I want to place on record my respect for my engineering cousins in process design. These are colleagues who get to play with robots, with sorting and sequencing machines, with presses and with tool designs; these are people who have a very rich and very different mind to my own.

I haven't the faintest clue how to design and specify a press or a hopper bowl that will position and place fitting after fitting into an assembly rig so that they are all applied - firstly at all, and secondly in the correct orientation.

In some many cases, it is the process people who give one company a slender advantage over another - either through holding dimensions and quality better than anybody else, or by bringing costs down to an attractive level for everybody concerned. In the automotive world that I know, most contracts involve a year-on-year price reduction clause. This assumes that as a product achieves maturity, scrap levels are reduced, efficiency in increased and waste is minimised. These are valid assumptions to make, but the work towards achieving those goals in an economic way is principally down to the process and manufacturing engineers.

So really this post is about acknowledging the diversity within our own world of Engineering and letting it be known that I have the utmost respect for the guys and gals who, much more than Getting Things Done, Get Things Made.

We're on the cusp of starting the migration of our CAD data into a full-fat PLM system (in our case Teamcenter from Siemens). It's now becoming clear what the task ahead of us entails - approximately one thousand 3D models and their associated prints need to be collated, tagged, parametrised, renamed, renumbered and transferred.

The tagging and parametrisation will take approximately 30 minutes per item, meaning (rumble, mumble, calculators, divide by the solar transit and carry the moon) around sixty working days, for somebody (most likely not me, thankfully) working at full tilt to the exclusion of everything else.

It'll be a big old resource hit, it'll cause lots of anguish, gnashing of teeth and grinding of coffee - but the results should be spectacular, even if we're "only" migrating the CAD data in this first step.

Once we start adding the life-cycle documents for each part, it will become a world unto itself. That's for another post.

Are you blind to detail? Source Wikipedia Ishihara diagram

"It's just a minor detail" is a commonly-enough heard phrase, with only two problems: the words "just" and "minor." Take those two belittling extraneous modifiers out and say it again: "It's a detail."

Often enough, putting a concept or even prototypes together is the easiest (and the most fun) part of a project. The main parameters are in place; detail is "the rest" required so that something that vaguely resembles a manufacturable, saleable product results. It's those unknowns that need pondering, the "not quite rights" that need purging.

Put romantically, not just devils but angels, cherubim, seraphim, orcs, gremlins and all sorts of other critters reside in detail. They battle continuously to make or break your product, whatever that might be. Wrong material or tempering grade? It'll deform too soon, or just snap - if you're lucky at the prototype stage. You got your tolerances wrong? They'll bite you within three months of start of production, on a Friday afternoon before Christmas. Overspecified things to be on the safe side? Your product might be unfeasible to make, or too expensive. When you get the details right, however, that product can go out there and do what it's supposed to do - satisfy customers and make money.
So, we "just" need to get them right.

The first thing to realise is that there are no "hero" details. Every item on a drawing or in a specification can lead to something going wrong, and every item that is not there can, too.
Picking your way through the thicket requires concentration, discipline and focus, namely the three things that are almost impossible to come by in a normal working environment.
So, alongside placing the spotlight on details, this post looks at how and when to work on details.
Without thinking, problems don't go away. Without doing, they don't go away. Normally, one of those activities preceeds the other...

One key way is thinking solo: giving yourself the time, room and environment to think. Daydreaming is often for me the best way of filtering out my surrounds and letting ideas or understanding drift into my conscious view, when I'm least expecting them. Then I at least know what I need to work on. Then it's a case of separating myself from the others and going somewhere quiet to focus on something.
Brainstorming with colleagues is another method - call a guerilla meeting, half an hour over a coffee, just before lunch to ensure the meeting finishes on time; longer-scheduled DFMEAs is another good way of at least discovering what needs to be determined and proven before a product hits the scrap bin more often than the "goods out" one.

There's a key difference between the solo and the team thinking methods: thinking is often misconstrued as "not doing anything" whereas a team meeting is by default acceptable, no matter how inefficient. Let's have a look at solo thinking, then.

Or rather, look away - solo thinking is by and large impossible where I work and, I suspect, where you work, too.

We have an office with around ten people packed into around twenty square metres. It's not a sweatshop, but it is an open shop. Generally, whenever I need to get any quality thinking done, there will be others gossiping, discussing the price of petrol, mortgages, coffee (in fact, they are always talking about the price of something). Then an empty skip lorry will race past the windows, chains flailing and rattling, simply making an almighty racket. It is simply not possible to concentrate.

So I try to escape.

I go off and make a coffee. Or I'll go for a wander to the labs, but not actually get there. I'll saunter nonchalantly down to a meeting room without any meeting planned or find an unoccupied office, sit down and open up the one thing that I want to be working on at that moment.

I turn off Outlook
I leave the phone on silent and on its charging station so that it doesn't vibrate.
I shut down my browsers.
Then I load them up again (I nearly always need them for research and many of our documents are online). Browsers are a huge distraction or temptaion, but I find that if I'm really focussed I forget to browse the news or check my private emails or Google+.
Sometimes I'll uncap my fountain pen and start sketching, or I break open Excel and start working on tolerance calculations, O-ring compression sets; or I'll start searching the internet for the one key factor that I need to define what I'm working on.

In any case, I have to admit, my task-focussed multimedia shut-down strategy can be a tad one-sided. I often need to call somebody - a colleague or a supplier - for an insight on a particular detail. Or I'll send them an email. And I disrupt their work in the process.

So I can do detail - but, like drawings, I can admire detail but I don't necessarily enjoy it; I can occasionally lose myself in detail work, but in the same way that I am slightly colourblind, I don't see detail like a real clear-headed, focussed checker can. Working on the details of a design is often an effort that is sometimes too much and ends up in frustration. I'm not your stereotypical engineering bureaucrat who will gladly and with a sense of achievement check every last entry on a drawing or bill of materials. I'm not naturally a detail person; but others are and that's why we should work together. It's what teams are for.

p.s.

Jobs I could not do because of this:

• teacher marking exams (= engineer marking PPAPs)
• lawyer (=engineer getting involved in patents)
• customs administrator (= engineer and his paperwork (= engineer))
• forensic scientist (= engineer working on quality complaints)
• politician (= engineer trying to get all parties on board)

Oh. I am all of those.

It's a while ago now, but over Christmas, I was (watch out, this is going to get exciting) doing the washing up after my sister had made the dinner. (Just to write "pork chops" does the meal an injustice, but that's basically what it was). The item I cleaned last, because it had by then rather unappetising looking bits of wet pastry on it, was the beater from our old Kenwood mixer. As I washed, I remembered how this piece of utilitarian design had always fascinated me through its complexity and simplicity. So I took a photo, which I just rediscovered:

It is designed as a 'K', instantly bringing the branding to the forefront. Whether or not this is optimal for mixing pastry I cannot say; but it works very well, generally resulting in great cakes, so its impact on the mixing dynamics of pastry is at least not negative. Its complexity is subtle, but everywhere present. It warps in all three dimensions, combining rigorous straight elements with beautiful curves, tubes with flat and developing blades.

 Some of the joins are no longer quite so beautiful on our example, but after over twenty years of use, that can be expected. Doubtlessly the assembly process has improved significantly since then (or has been made ever cheaper), but the K-Beater design remains to this day and, even when mass production using 3D printing becomes commonplace, it will remain in the future...

 A classic.