Perhaps I'll take him up on that idea - it's not a bad one at all. Welcome to a new hashtag: #validationzen

Toyota helped to kick off the 2014 CES show by pronouncing themselves happy with the rate of development and cost reduction on Fuel Cell Vehicles: “Fuel cell electric vehicles will be in our future sooner than many people believe, and in much greater numbers than anyone expected.” Indeed, they intend to have a “vehicle” (by which I understand a car of some sorts) on sale by 2015

 Now, even with my occasionally shaky grip of arithmetic, especially in German that's NEXT YEAR. Whilst it’s usually better to look forward rather than backwards, the history of fuel cell vehicles is long and far from glorious, so it’s worth taking such pronouncements – even from Toyota – with a pinch of salt.

 Having said that, I've always been fascinated by fuel cell technology - as a naive young engineer, I somewhat irrationally invested in what in hindsight was a rather dodgy looking British-Belgian-Russian company called Zevco. This firm at least managed to get a fuel cell into a river boat, a taxi (a recurring theme in fuel cells, as a small fleet of taxis  created for the 2010 London Olympics shows) and an airport tug - before it folded, with the best of intentions to rise again. Admittedly, I wasn't the only dreamer out there, as Zevco managed to sign several alliances and intents of work before going under, with companies much richer than I – but there has never been a convincing commercial case for fuel cells. 

More recently, I was naturally keen to be involved in a project to develop the high pressure lines and connectors between the hydrogen fuel tank and the fuel cell. This was, alas, but from a business perspective sensibly, cancelled by our management as – well, quite simply, there wasn’t a convincing commercial case for it.

 
Money aside, key technical challenges remain:

• H₂ infrastructure (and figuring out where the energy to extract hydrogen should come from)
• Tank and system pressures of up to 900 bar
• Operating fluid temperature -40 to + 85 °C
• When the fuel cell is running at max power, it’s drawing the maximum amount of hydrogen from the tank, thereby reducing the pressure and cooling the feed system to sub zero temperatures
• System permeation & losses
• Sealing all the lines and connections in such a way that they’re quick to assemble and acceptably cheap
• Ensuring that you can leave a car in an airport car park for a week without it emptying of its own accord.
• Refuelling safety and losses

Even before sending cars out onto the roads, developing and validating the system is non-trivial as there are only a handful of test centres capable of handling the full suite of tests required. And they’re not particularly cheap.

The fuel cell endeavour seems to go in waves, with resources built up and then, like GM-Opel's team in Mainz, Germany, discarded. I personally hope that it works out. Perhaps the competitive and commercial might of Toyota, Hyundai, Daimler as well as a range of dedicated system suppliers like Intelligent Energy and Ballard, can result in a compelling case for the technology. But I  fear that, for want of a serious infrastructure, and the insurmountability of storage issues, it won't.

Still, give me a project working on carbon fibre fuel cell cars, and I’ll be one happy engineer…!

As opposed to engineering with hectic grumpiness

Ah, finally - it's the Christmas holidays. At last, I've a chance to divert the kids into the path of their doting and understanding grandparents, then to sneak upstairs for a spot of stolen quiet-time. Time for switching off, for thinking and, in not too big a dose, writing.

Time for calm, quiet reflection is an astoundingly rare commodity. It has to be cherished and nurtured wherever possible, especially in that most unlikely of environments, work, where we happen to spend a goodly chunk of our lives. Reflecting on the the year that is petering out as I write, the biggest theme for me has been focus, or how difficult it has been to apply it with any regularity, and asking why I've not been successful at blanking off the world to exclude everything and everyone save the task to hand.

In the hustle and bustle of this engineering world that we inhabit, it's easy to get caught in the undertow of "actionism" (from that great German word Aktionismus) - doing stuff, doing more stuff, doing the same stuff again, doing more of the same stuff slightly differently; all of it urgent, most of it dull, mostly simultaneous, all of it with consequences for colleagues, suppliers and customers that mean, under the circumstances, we're unable to say "sod it." We're lynchpins without the luxury of deciding our priorities. Well, that's how I've been of late.

So, making use of this Christmas calm, I've tried to slow down, to reappraise how I - how we - work as engineers. The goal, I have decided, after a few sips of tea and a little staring out of the window, is that we must be able to work with grace, patience and precision.

This may sound like a whimsical, romantic view of master watchmakers or coffee roasters at their most reflective - but there's no way around it: it's the best way to approach any task. So let's have a think about what each of those concepts mean, and see if they make sense.

Grace and patience

Grace and patience are the rhino hide protecting the core of precision, which is the aim of any engineering activity. When they are too thinly applied, actions and deadlines chip away at the "precision" aspect of what we do. If we lack precision, then it's easy to become rattled or ratty when our decisions are questioned.

Grace is the ability to take on board what a task or a product requires, as communicated by people or by circumstance - or, as is more often the case, as not quite communicated by people or by circumstance. Grace means:

• Not being caught up in the emotion of the action
• Not being ruffled by the urgency of the action
• Retaining the ability to think clearly
• Retaining the ability to call in help and assistance from others without transferring the "panic"

... all the while, if possible, without becoming aloof, or putting on the "insufferable smile."

Patience is very much linked to grace, but means having the inner robustness to delve into a task, to keep at it, to maintain the ability to ask the right questions, to wait for the right answers as they develop. It is and requires:

• the ability to focus on a project
• the ability to "plod" through the logic of a project

Precision

Precision is the mark of getting things as right as they can be. It doesn't mean perfection (of which there is very little to go round), but rather getting the small things right, even if it's a version change to 1.1.2, so that the big steps can also be taken later. There are hundreds of examples that I could list, but in our world, understanding tolerances, GD&T callouts, specification callouts. etc spring to mind. They need to be defined them correctly in the context of your product.

Note that I don't mean setting tolerances arbitrarily small - precision is a result of the discussions with production, with suppliers, with customers, in the spirit of grace and patience. Getting things right, properly, defensibly.

Discovering the environment of grace and patience

A corollary of all of the above is that we as engineers need the environment in which to work with grace and patience. I would love to be able to say that we should be developing everything in splendid isolation from business needs. Like an AT&T Bell Labs from the glory days of transistors and lasers, or a 1960s IBM, we should be capable of working on the future. To be honest, though, I can't even imagine working in such a world. It could be wonderful, it could be terminally dull (though I dream it would be the former).

We need to face reality. I work in the automotive industry, which tends to be rather full of rowdy reality, so I know what it means to suffer business pressures alongside engineering and development pressures, in open-plan offices, without air conditioning.

Attaining the "state" of grace and patience in such an environment has to stem from a conscious decision to find and to nurture them first. As far as I can see, the breakthrough needs to be mental.

Without coming over too Zen, I think (but can't say from experience) it should be possible to filter out background noise and to focus on the task at hand. We can help ourselves by taking small physical steps like turning off email alert pop-ups, silencing phones and perhaps setting up "do not disturb" signals for our colleagues; big headphones, for example. Occasionally escaping to a lonely meeting room can work, though it does mean leaving a whole desk's worth of tools behind.

What I'm saying is that we (I, at least) need to be clearer of what our mental capabilities are, what we need to learn and how we should develop ourselves, our processes and our communications with colleagues (commercial, quality, purchasing, suppliers - that whole bubble world that we interact with) so that we end up being able to focus on work, permit the minimum of distractions and can take time to research, collaborate and to iterate our way to the future, all in the spirit of grace, patience and precision.

Easy job. Let's have at it in 2014...!

Why do we have quality departments? Even posing the question feels like a minor rebellion on my part, since "Quality" is such an integral concept in the business of producing things. For "integral" we can also read "taken for granted." Sometimes it can be good to tug at the tent poles of the status quo and see whether it collapses in a heap around us, or if we can move it somewhere more interesting.

This post isn't just coming from a theoretical standpoint, of course. I've had so many run-ins with colleagues from quality that I simply have to question that whole role. Too often have they acted as alarmist messengers and chasers of other peoples' actions whilst understanding neither the problem nor the product nor the processes that they are supposed to be monitoring - that is, seemingly doing nothing about it themselves. They don't add value, nor do they seem to save value - they transmit urgency. Unfortunately, transmitting urgency to the wrong sort of person (for example, me) is precisely the least good way of getting things resolved quickly and effectively.

So, whilst we all inherently understand the idea of producing things in ways acceptable both to customers and to our finances, do we really need quality departments, quality managers, quality engineers? I think we could be cannier about the whole thing - and ditch them totally.

The best way to do that would be to design an engineering company from scratch - alas, not something that I've ever done. But for me, the basic idea would be that the tasks that quality departments undertake can be distributed amongst other departments where those tasks make more sense.

The flip-flop question is this: is it better to decentralise those tasks amongst experts, or to collect them all under one roof and standardise? It may well be that the size of a company - tipping around a certain critical morass - is probably a key factor in this decision. But the prospect of ISO / TS audits should not be!

I work for a largish automotive supplier, and we have quality departments coming out of our ears: it's the world I live in. Deleting them (distributing them) would mean for me personally that I would need to get my designs, from material selection through to defining tolerances, just right; my colleagues in production would have to design their processes to produce within the parameters of the drawings and specs I give them and that all needs to be validated and monitored.

In other words, nothing: eliminating the quality department would have no effect on my key role, nor on the role of my friends in process engineering.

However, I'm forever getting involved in quality concerns, analysing returned or quarantined parts, performing root-cause analyses. This can help me understand our product better, but rarely have I had to change a design as a result of these investigations. Enfolding one or two of our colleagues from quality into our test and development organisation would mean that those defects could ben analysed as thoroughly as they are now, and lessons learned could be centralised, whilst freeing me to work on the next generation of products, which is what, I believe, I'm supposed to be doing.

Manufacturing will still need people and systems to check and to confirm that product meets requirements, both at any given instant and over time - that's for sure; such roles will never go away, but these days we can trust our production team's integrity to manage that by themselves rather than abdicating that responsibility to a separate department.

The role of a quality department as independent arbiter, a kind of internal auditor, remains an interesting point: can we be sure that Manufacturing, for example, will always be open and honest enough about things like tool release decisions and scrap rates when deliveries or performance indicators are on the line? Well, if we can't be sure then it would surely be beneficial to work on the culture of the company rather than to add layers of oversight. Again, it's a question of opportunity cost - would it be more effective for a company to pay people to police their own people, or to research and to produce things more effectively?

If we think (or click) back to my post on how Google tests software, we see that the key philosophy there is: the design of the product should include its testing and confirmation methods. So it should be the  product and process design engineers designing this together, which makes sense to me.

And where would the resources come from to ensure that product and process design could cope with that additional work? From the now redundant quality department, of course.

That leaves the audit side of things. Of course, nobody wants to be involved in audits at any stage. But since audits are a fact of life in many industries, the product and process design teams need to be involved in designing the business systems that they use on a daily basis to use, store, distribute and to archive work. And they should be responsible for proving that these ways work both in theory and are used in practice.

So, eliminating quality departments, partially reassigning them to design and development, is the obvious answer to all of this - yet quality departments seem to grow and grow where I am. Am I missing something obvious that would really justify the existence of quality departments? Or can we continue to "Think Canny" in this funny old business of engineering?

Validation testing is a significant part of my life as an engineer these days. Also, I have much more interesting things I could - and should - be getting on with.

Validation is important, but it's largely stupid - like much of work, I suppose. Perhaps stupid is too strong a word. Dumb is probably a better choice, the opposite of smart. Validation is dumb, and there's no escaping it.

What to do?

Well, we can talk about it first (even if this is not doing anything about it). Validation is the antimatter of development - put the two together and you destroy engineering life itself (overdramatising somewhat). What I mean is this: development is subtle, replete with success and failure, nuance, puzzlement and, hopefully, finally, understanding. Validation is a box-ticking exercise that brings nothing of interest to anybody, except the approval to sell product, which is a key aspect of business, I have been led to understand... so validation is important.

Testing is an integral part of development, one that I certainly don't want to discard. When we develop components, we have to pass testing and other approval gateways; based on the resulting performance, either we confirm that parts need to be redesigned because they don't meet a particular specification, we confirm that our parts do meet a particular specification, or we can write our own spec if one doesn't exist already. At the end of a development project, validation confirms that the first parts off the real production process are as good as all those expensive prototype parts that were tested previously: validation can be the joyous culmination of all that development effort, champagne all round. So really, my gripe isn't with concept or process validation testing - these are valid steps in getting a product to market.

Get over it

My gripe is with approval testing; testing that is set as a hurdle to delivery to a given customer.

Hurdles are good in many ways. If everything we did were trivial, anybody could do it. Fortunately, what we do is not trivial, and there is a limited number of companies involved in our market, each with their own strengths and... opportunities. Validation testing from the customer side is a way of filtering out duff suppliers.

But the work that is sucking out the oxygen of development for me right now is not linked to any new development or any new product. It has the Kafkaesque whiff of bureaucracy generating a lot of effort for no tangible benefit at all.

Validation is time-consuming, expensive and is (supposed to be) a key component in my other important-stupid bugbear, PPAPs

So, as I asked before, what to do with it?

The phrase "creative destruction" comes to mind - destroy validation and PPAPs and all of that dumb junk to free ourselves to think creatively. Let's explore that: can we ditch it all?

Ideally, yes: with all the data swilling around in our company, from development results to production and quality control systems, we should be able to show that production parameters haven't changed significantly since the product was first approved, and that the standard production checks will have filtered out any weaknesses.

This can work - but often the customer wants to use an existing part on a new platform, or a new part on a new platform, so wants a full set of confirmation test results, in their unique format. Also, it doesn't avoid the question of whim. A customer can demand results against a particular set of specifications whenever they want. So, you test and you validate.

But why me?

If there's one industry where whim and whimsy is at a minimum, it's motorsport. What do they do there? Well, even if they are producing a "series of one-offs", they test and they inspect and they destroy things, too. Yes, they validate. How they go about it is hinted at in this puff-piece by and from the Lotus F1 team.

The article doesn't tell us much, but the important point is that they have an inspection team. Just as software smithies have test teams, engineers should have inspection and validation teams. This is what I am missing where I am now. We have fallen in slow-motion into the trap of mixing development and validation in one pot. Alas, because the output of validation is a ticked box (or a boxed tick), and since those ticks in boxes are prerequisites to supply and therefore making money, validation more often than not takes priority, thereby hindering development.

Unite and advance, Divide and conquer

The answer, then, is twofold - and also expensive. First of all, the vexing question of validation testing needs to be tackled at the source - with the customer. To be able to come to a sensible agreement on what's relevant and what's useful to test, the onus is on the supplier to show his understanding of the product - how it performs, how stable the processes are, what could potentially go wrong. This is expensive in terms of effort - data-hunting and gathering, condensing it into digestible information and then taking it to the customer for (in all probability) a series of meetings and discussions to come to a sensible arrangement.

Then validation testing must be separated from development. The two should be unique teams with limited overlap, ideally with separate facilities. This, too, is expensive - but not focussing sufficiently on development is more expensive still in the long run.

But perhaps I'm biased.

After letting lady Shanghai go first, gentlemanly North America, along with cousin Mexico, took its turn at being trained by a bunch of know-it-all Europeans (and one Australian), who were airdropped into Detroit last week to bring a breath of fresh thinking to the way our product and processes are treated, and to help make this new air the one we all breathe globally.

(wow, perhaps I should become an industry marketing writer...!)

As one of the know-it-alls, I have to admit to having felt some trepidation at facing the North Americans. Our regions have been working more or less independently for the last several decades and my fear was that the Americans, with their equally vast but differently tuned automotive experience, would be open only in the expression of their hostility to our ideas.

Fortunately, that trepidation, whilst not completely baseless (I had my reasons for such thinking), did not crystallise into anything tangible, for the most part. I did notice participant numbers fluctuating during the two days of training, with some key individuals spending a remarkably small amount of time with us, even considering the typical day-to-day calls upon their time, but those who stayed throughout were attentive, asked good questions and kept us going through all the jet lag and windowless meeting room atmosphere with their overall positivity and willingness to learn.

We certainly brought new ways of thinking (though also some not so new but not fully implemented standards) to the forum, and they weren't dismissed out of hand, as could have been the case. Having the backing of our global management team undoubtedly had a helping hand in keeping the peace there, but I got the impression that what we were presenting made sense and was difficult to argue against. The discussions were mostly about context and capabilities rather than acceptance.

My own presentations, on the engineering behind our product, and on technical problem solving, were well received, even though my first presentation went well over its allotted time. This really was the breath of fresh air that the team were looking for. Again, discussion was constructive and showed that my American colleagues were learning something that they were keen to be able to implement in their own region.

Is there a life beyond the office?

Despite the windowless conference room, which sat as an enclosed island within the sea of cubicles, I have to admit to being quite impressed by our American headquarters. It felt like a rather different company to the one I work at in Germany, altogether more professional. It exuded a quiet professionalism (aided by some careful noise damping, which is fully missing in our offices, and even a soft white noise that is intended to be filtered out by the mind, along with similar frequencies, making the whole thing "feel" quieter).

There was an excellent canteen, with a sandwich-making bar, main courses, cookies and - the pièce de résistance, a soft-whip ice-cream machine. Coffee was always available from the Starbucks bean-to-cup machines, as were various colas and fizzy drinks (in huge 12 oz. cups), with ice of course also being on tap.

Alas, beyond the offices and hotel, I didn't see much at all. On first impressions, there wasn't much to entice anybody out of the hotel

Room with a view

, even though I really needed to escape - the windows were welded shut, so it was all aircon air and faintly Soviet-looking corridors. 

Accepting the company transfer from airport to hotel wasn't a mistake per se (it was lovely being chauffeured around in a Lincoln Town Car), but it did mean that I didn't have the flexibility of a hire car this time around - and not having a car there is pretty much fatal there…

Whilst it was all about the people this time (OK, the people, the burgers and the beers), and making contacts, not having seen downtown Detroit, Birmingham, Rochester or any surrounding scenery, was a bit disappointing. I'll have to do better next time.

Getting to and from Detroit was fine. I was pleasantly surprised by Delta airlines (I'd always heard pretty negative things about them), but the service was very good, bordering on the excessive when the purser came to shake everybody's hand and to thank us all for choosing Delta. On the other hand, I was disappointed by the support from KLM-Delta when my return flight from Detroit was delayed by connecting flights from Miami and Orlando. Alas, they didn't return the favour with us in Amsterdam Schiphol, meaning that I missed my final flight back to Frankfurt.

That resulted in a jet-lag-groggy four hours in yet another airless lounge and an electronics store, where I managed not to by a new tablet on a whim.

So - the next training will be on home turf in Europe. Will that be the biggest challenge of them all, trying to enthuse those colleagues in the midst of one of the biggest slumps in the automotive industry? It shouldn't be. The biggest challenge will be turning this initiative into a resource that will be available for all new and existing employees. That's going to be fun, for sure - more on that as and when.

At least in Europe I should be able to enjoy more fresh air than I have in the past two trainings...

Corridors of power

December. Time of cheer and good will to all colleagues, rushing for presents, updating projects, Glühwein, clearing out inboxes, eating far too much chocolate, finalising reports and… 

And getting audited. 

Yes, we were audited this week and one of my projects was in the spotlight. It was all going swimmingly until the auditor heat-seekingly locked on to one particular thread of my project that wasn't really parcelled up and tied with string - ironically enough, the DFMEA.

Being shown up as lax in my own project was certainly embarrassing, one of those half-expected shocks to the system; I felt a bit like a child hoping rather than expecting not to be found out about those stolen chocolates. I was hoping rather than expecting to be able to skim over that the incomplete DFMEA (structure present and correct, values not), knowing that it was a weakness without really having polished it off beforehand. I was found out, and rightly so: that’s the reason audits happen.

We were marked down for it, of course, and I’ll have to get things back into shape sharpish.

Reading those words of mine just above (“that’s the reason audits happen”), I surprise myself with how true they ring.

Have I finally come to accept them? And if so, how do I accept them? Gladly, or grudgingly?

For years I’ve harboured a deep suspicion, a dislike of audits and what they stood for. For me, they stood for engineering by checklist, for doing rather than thinking, for rewarding completeness rather than innovation and - for the vast majority of my auditing experience - huge cleaning up operations for close to zero benefit.

When is something that is good enough not good enough? When it’s being audited.

I have experienced both sides of auditing; I have audited and have been audited. From being part of an auditing team, working alongside quite an enlightened auditing colleague, I understand that the mindset of an auditor should be a positive one, aiming to help the subject improve by pointing out the weaknesses and working on agreements to correct those weaknesses before they lead to genuine failures. This mindset should match that of the auditee. When both see the positives that can come out of the (like FMEAs) negative messages, then things are heading in the right direction.

Nevertheless, audits are a not insignificant burden on everybody involved. Couldn’t we just wish audits, along with PPAPs, away?

Well, not easily: auditing is a multi-billion dollar industry in its own right, valid across a whole spectrum of industries, and it’s a difficult edifice to start chipping away at. But even so: wouldn’t our engineering lives be so much more enjoyable without them?

Initially, yes - they would be. We would be freed up again to design and develop as we know best: we know what our products are supposed to achieve and how to get them to that stage, even if not every Excel list has been filled out to the n’th degree en route. We could potentially become more like Google, where “...in the innovative and fast-paced world that [the Google developer] lives in, you get what you get.” (From How Google Tests Software)

We would have more money and time to spend on D&D, too, not having to pay those auditing firms their crust or having to spend all of those man-hours preparing “just in case it’s audited”.

But let’s look at it another way. Let’s say we want to start using a lower-cost supplier, more than likely in the old Eastern Bloc or somewhere (usually very large) in Asia. What are these companies like? Can we entrust our intellectual property, our quality and our good name to them? What better starting point could there be than searching for a certificate alongside customer references? (well, it’s true that there are differences in auditing rigour in China, even amongst the financial big four, as The Economist magazine writes)

Audits cannot guarantee a good name, nor necessarily a good engineering company: there are firms with certificates on their walls that I wouldn’t wish on our fiercest competitors. In the same way that financial audits have missed gaping holes where the subjects have been playing the game better than they have - like Lehman Brothers, Enron and, it seems, Autonomy  - quality audits can almost be guaranteed to miss something big from time to time.

Even the auditors themselves get themselves in a muddle - our December date with auditing destiny came about when the auditing company missed a submission deadline. This swiftly became our problem when our certificates were due to expire and our emergency re-audit date last December became our annual date. Thanks, we appreciate it!

So, what are audits good for, then? Qui bono? For starters, audits are a reassuringly expensive starting hurdle to business: my industry - automotive - and many others have gotten themselves into a standardised twist, whereby an ISO / TS 16949 certificate is a prerequisite for supplying to an OEM. It’s a pay-to-play move gives potential customers a guide that the company won’t royally mess things up when they start a supply relationship.

Audits also place a burden of duty and therefore responsibility on companies and their employees – from management right down to lab technicians – to get things right. Not only to “get things right” but also to “design things right”. This applies both to the product itself and to the process of how you get the product into a customer’s hands. Ideally, an audit should be imperceptible other than having to make some coffee for a visitor and answering a few questions. Why should you have to prepare if you are living the systems that you have declared fit for your own purpose?

Umm, too much other stuff to do, perhaps? Not enough time to focus? Not enough mental energy left for yet another list-trawl?

Well, if audits and all the stuff that we have to prepare for them really are a burden, then - again, ideally - they should become the impulse for genuine improvements in the way we work, in the way we communicate and collaborate. All of that form-filling, report-writing and change log management should have a genuine purpose, even if it is occasionally completed in the grudging spirit of passing an audit. All of these items are part of the company's index of information. When we change and update those forms, we are changing history, improving it. It's about creating a legacy, hopefully one of that will make sense of our successors' past.

The one thing that can make audits bearable is for everybody involved to treat it as a human thing - checks and balances are inevitably required whenever human endeavour is at work, so go with it. Let the auditors ask the good questions and let them discover how you work - even I with my DFMEA fail this time around will have shown that overall we’re working well and are going in the right direction. So, I’ll take that “nonconformity” hit and try to improve on managing my projects along with managing everything else, and let’s see if we can find some mental space to put to use on streamlining our work so we can do better next time.

And so back to my initial question: do I accept audits gladly or grudgingly? Well, of course it’s still the latter, but at least it means that I aim to keep them as low profile as possible: for that, though, I’ll need the support of my management – and I can assure you that the audit result was a wake-up call for them, too. Perhaps better things will come of it (or perhaps more oversight and review meetings – still, they’re a way of switching the focus to projects).

One final note on all of this: I don’t recall ever hearing anything about audits when I was studying engineering at university. That’s something that should change (perhaps it has, already), as they are a real, if occasional and generally unloved, part of this engineering life. If the next generation of engineers know what’s in store for them, they’ll know to focus on how they work as well as what they actually work on.

Quality issues cannot be counted amongst my favourite activities. They can normally be categorised as "urgent-uninteresting", which is just about the best demotivator I can imagine. They're negative, cause huge floods of emails, assumptions, obfuscation and general panic. Some people thrive on this sort of situation. I, generally, don't, as was again proven by a quality concern with some Chinese colleagues.

I get involved simply because our Tech Centre has the best kit, so we can test what others can't. It's annoying, because development people rather prefer looking forwards than downwards at self-shot feet.

Nevertheless, some quality issues are useful ("never let a crisis go to waste" and all that). Some are excellent impromptu team-building exercises and others simply turn up some interesting artefacts, like this beauty below. It stopped me in my tracks - never have I seen an Ishikawa diagram illustrated so literally as by my Chinese colleagues...!

For those not yet in the know, the Ishikawa, or fishbone, diagram is a way of formalising the investigation into the potential causes of a particular issue. It's a methodology that forces you to look at each the 6 M's (others call 7 or even 8) in order to gain the full picture of what might have gone wrong to cause the issue (sorry, problem) that we're working on (the Environment one is clearly an awkward 'M-ification' for the purposes of alliteration):

Machine (technology)

Method (process)

Material (Includes Raw Material, Consumables and Information.)

Man Power (physical work)/Mind Power (brain work): Kaizens, Suggestions

Measurement (Inspection)

Milieu/Mother Nature (Environment)

I can't tell you precisely what the 5 Chinese characters represent in this one. Whatever the causes of this particular quality issue, the discovery of this putrid gem of a rotten, stinking fish amongst the rotten, stinking debris of a quality concern almost made up for it...

Terracotta Warriors photo from romainguy on Flickr

As an Englishman living and working in Heidelberg, I am often asked if I work for SAP, the business software giant based down the Autobahn in Walldorf. I don't, of course. If I did, I'd be writing about software development, the management thereof and how utterly astounding their legendary canteen is.

The question is not a daft one, though: around 10 thousand people work at SAP in Walldorf, forming a more or less willingly thrown together (or at least well-paid) melting pot of 80 nationalities with English as the working language. It’s easy to assume, then, that a middle-class, technically minded foreigner living in Heidelberg earns his crust and her Grauer Burgunders at SAP.

I know a few people who work at SAP, and they are generally of a particular ilk (physicists and mathematicians, i.e., not my type) so I know that I don't need to yearn to work there, but there’s one thing I envy them: resources for R&D. Globally, (2011 figures) SAP has 16 thousand employees working in R&D (12 thousand work in sales…).

16 thousand in R&D...

(drifts into a reverie)



(Snaps back with a jolt)

I’m not in that place. I am a development engineer at an automotive supplier; my development activities really only skim the outer atmosphere of the unique world of R&D. Is this a surprise? Is it a disappointment?

Let’s think about the surprise factor first. When I consider my time at university, I don’t recall ever having heard the word “resource” discussed in any manner other than as a general term for learning material. We picked up the material, used the libraries and even the nascent internet; but I was never a resource myself.

Resource was always a “hidden” theme. We were aware of time pressures with the need to study such a wide range of subjects whilst maintaining sanity and health through extracurricular pursuits, but it was always a case of everybody finding their own balance.

My aerospace engineering course did involve one larger team design project that was formative, but as far as I could see, research projects could run in a business vacuum, free from excessive emails or telephone calls, requests for assistance from around the world and quality alerts to have to jump onto. Ah - there we go. Did you notice that word in there, mentioned for the first time in this post? Team.

Entering the workplace was a relatively soft jump for me: I joined Ford in the UK which at the time was recruiting heavily - and, crucially, I joined a team. By that I mean there were several of us who could do each other’s jobs, if necessary and we worked both on improving the product and on improving the ways we worked on those products.

Recently, I was part of a globally distributed team that developed a new procedure for drawing release and approval. The word 'team' in this case represents more a collection of perspectives than anything that could really work to fight the necessary fights. We had representatives from design, from quality, from manufacturing; but none of us were interchangeable in the way that my team position at Ford was.

Developing the process itself was the fun and interesting part. I managed to find a spare license for Microsoft Visio (alas only the 2003 version which is now looking very old indeed) and used it to create the workflow. As it is a cross-functional process, the workflow runs in lanes - development, manufacturing engineering and quality - so the visual aspect was initially quite appealing. Adding the "if… then" loops and the different entry points for product at the various stages in their drawing lifetimes certainly de-streamlined it, though.

But actually running the procedure has been no fun at all. The problem is that it was implemented as a project in itself without great consideration for the resource implications of centralising what was in effect a totally distributed (and therefore wasteful, if potentially evolutionary) process.

So the current situation is that I am currently the only person in a company of over 16 thousand who can create the drawings that those 16 thousand people need.  Imagine SAP setting up a system whereby those 16 thousand in R&D could only work if I finished one particular task amongst many. It wouldn't really make sense, and this is something that I'm struggling with at the moment.

And so to my second question - am I disappointed not to be part of that resource pool? In a word, no. It's harder to explain, but perhaps this is only because of a lack of imagination: I simply cannot imagine being able (or only being allowed) to work on one problem at a time. Whilst I am trying to relearn the art and discipline of focus, it doesn't come naturally to me. I thrive on bandwidth, even if the transmissions occasionally get muddled up and jam because of it. I'm a variety type.

Coming back to those cohorts of SAPlers, though: despite their numbers, there have been reports recently that even they are feeling pressured to breaking point in their jobs. Which means that you can spread even 16 thousand researchers thinly. R&D resources generally expand to fill the product lines a company is working on; even within the relatively low number of headline products SAP produces, there is a vast number of modules that require development and linking in to others, so there's plenty for lots of clever people to do. (Google has around 33 thousand employees, Microsoft 92 thousand, of which 35k are in R&D).

So today's R&D behemoths are commercial, distributed amongst the universities and amongst the startups that thrive or die on their findings; I'm somewhere in no man's land - where are you?

p.s. Happy 40th, SAP!

There's one thing that I need to get off my chest early on in this blog, as it has been weighing on my mind for some time. It is the bane of my automotive life thus far, the PPAP.

Almost nobody knows or nor really cares these days that PPAP stands for "Production Parts Approval Process," nor that the system is responsible for terabytes of redundant data. The idea behind PPAPs is - I admit - sound, in that each and every part in a car is fully validated before being built into a vehicle. However, having worked on tube fittings for a few years and come across PPAP submissions "weighing" 26 megabytes for threaded nuts weighing 13 grammes, and still being wrong, I feel that the PPAP process itself needs investigating.

The PPAP is an information pack that includes the drawings, measurement data (with capability), test data, measurement and test equipment certification, FMEAs, control plans and process flows for the part in question. All of it needs to be correct to be accepted by the customer.

It was created by the AIAG (Automotive Industry Action Group) that originally consisted of the "Big" (now "Detroit") Three of Ford, GM and Chrysler. One of the driving principles behind it was to standardise the requirements for these three manufacturers so that their suppliers need only produce one data pack per part and not have to reproduce it with tweaks for each customer. The other key principle was and remains that parts will fit and work properly when they are assembled into the cars they are destined for. Equally, the PPAP should prove that the supplier is ready to produce good parts at volume and it provides baseline information for the life of the part ("back then at the beginning is was like that, now it's like this"). However, the PPAP system has become a monster. This monster has generated its own sub-industry; dedicated employees who work only on generating or approving PPAPs, and people like me checking supplier submissions like school teachers marking essays. There are great chains of PPAP submissions, from sub sub suppliers to suppliers to the OEMs, and the whole system is populated by disinterested humans.

The number of submissions that I have checked and rejected in the past for vast swathes of missing information was depressingly large. So these packs (of lies) are being batted back and forth from server to server, person to person and hours are being wasted the world over.

My relative fortune in my secret PPAP life was that I only had to check the technical aspect of the submissions; somebody else in the quality department was responsible for going through all the other documents and certificates (generally "is there something here that looks like a certificate, or not?"). But even the technical side of things, which really should have been simple, always seemed to lead to confusion.

Why should it be simple? Well, there are drawings with dimensions (some with complicated GD&T, admittedly, but still doeable) that need to be measured (and not just reported with the value "OK"). The supplier just needs to check off the dimensions one by one and show that what is being produced on real parts meets those requirements. Fine. But, the drawings also have words on them, sometimes in the form of specifications, which should give the supplier a small hint about some other aspect concerning the parts - like, say, performance - but often somehow don't. Maybe it is actually all just too subtle and not simple at all. It was alas very rare in my experience to receive a PPAP and to be able to complete it there and then, on the spot, no more questions asked. So not only do the PPAP submissions need to be sent along the chain of suppliers, they need to be reworked and resubmitted. Usually this involves testing being (re-) started just as the parts are urgently required, which means that we have to grant deviations for a limited period until all of the testing is completed (corrosion testing, anybody?), we have to request deviations of our customers and we have to keep track of those deviations as well as the versions of those PPAP documents... and so on.

So, there's lots's of time wasted, there are megabytes of redundant and duplicated information sloshing around, repeated for each of the approximately 15000 unique parts in each and every car driving around the world (I'm not sure PPAPs are used by Khodro in Iran, however).

And yet, PPAPs, like audits, are impossible to argue against. I recall hearing that Continental tried to settle on a basic level of PPAP above which the customer would have to pay, but I think that rebellion was quickly crushed. If you've heard more about it, let me know in the comments.

In the end, my recommendation is that, if you're a young budding engineer looking for a first job, try to avoid anything that says "PPAP" on it. If you still want the job, then make sure that the PPAP bit is not too high a percentage of the job and is for a limited period only - and spend that time finding someone else who will do it for you (preferably not an engineer!).