Toyota Quality Program - YEAAAAA!!!

Understand that I have no illusions about how difficult it will be to implement an effective quality program. I spent 13 years with GE and 10 years with the now gone, Boeing Information Services, and remembered how hard it was to get an effective quality program going:

• Upper management support - every 3-4 years, they would announce a new quality program and goal with budget and training ... but after the kickoff, their interest decayed until 3-4 years later another 'quality program' would kick off.
• End contributor support - too often we became jaded by the hypocrisy of "just in case" quality training. We knew the mandatory training was given 'just in case' it might stick.
• Middle management - first line managers and supervisors either buy into it or not and that is key. The smart ones realize a quality program can be an effective tool that complements their team leadership ... this is the hard part.

Sorry, this is going to read like a rant but it is also about what I've learned works and doesn't work. But have no doubt in my commitment to the goals of quality as I have life experiences about what works and doesn't work. I will return to Toyota's announcement and what I like and the risks.

Ward Clark's Red Pen

When I began my operating system apprenticeship, I was given an assignment to write an ALLOCATE command. The design process was a team effort where we went into a locked room and discussed (more like argued) about what the user memo would say about the ALLOCATE command. This included all of the options and error message, especially the error messages, until we reached concensus (the absence of violent objections.) This took several days and no work was done on the ALLOCATE command until a final draft of the command was written and agreed to. I was allowed to start researching the system service calls but not write a line of code.

With the User Memo, I could start coding and Ward Clark told me to bring me the first code, even before the compiler, just a listing. Ward took out his red pen and by the time he was done, there was more red ink than black. ... Back to the desk and two days later, I brought back the second version ... again the red pen but less than before ... Back to the desk and a day or so later I brought it back, he took one look and said, "OK."

Ward was training me on how to write code that looked like the code everyone else in our department wrote. It meant when we had to debug something, we didn't have to figure out the coding style but could concentrate on the goal. It also meant that a small system programming team, four brilliant guys, Ward, Bernie, Roland, and Rick, could do the work of six or eight in another shop. We each had our special expertise but we put agreed to code the same way which meant we could 'code share' and not get lost or distracted by superficial things.

DECUS Development vs Maintenance

At a DECUS presentation, somebody selling a configuration management tool showed a chart titled 'Programmer Retention.' He showed two curves, the percent development curve and the percent maintenance curve and they intersected around 18 months. He pointed out that this matches the average employment time of many programmers because:

• Development is fun
• Maintenance is drudgery

Ok, we realized there might have been a little tweaking to make the data fit but the behavior he described was dead-on. Too many times I'd seen professional developers who flittered in at the front of a project and found their new job just as implementation began. Too many times I found junior programmers who were hired to maintain (or complete) projects begun by the developer ... and they would burn out ...

Consolidated Automated Support System

Using embedded comments to generate user and design documents, I was able to write the quality standards for a major GE project. I gave them to our QA team and backed them up. They were shocked that a performing manager backed them up ... when they enforced the goals of the coding standard. But their shock was exceeded by as some of our 'brilliant' but undisciplined programmers when I sided with QA. We met schedule and budget because even when someone 'got stuck,' I or another clever programmer could pick up their work and concentrate on the important parts and not get lost in style.

ISO-9000 (1992)

I had become skeptical about the "Quality" industry having gone through repeated "just in case" training both in GE and Boeing. Then one day I was reading Electronic Design News about something called ISO-9000 and the 20 sections and "the light came on."

Here was a Quality Standard that had hard requirements, independent verification and the skeletal strength of 20 sections to teach what a quality program needs to incorporate. Perfect, no but compared to everything else I'd been exposed to, it was close enough. I still maintain a private library of ISO-9000 documents and use them to train newbies.

Sad to say, ISO-9000 was re-written in 2000 to eviscerate the 20 steps for some vague, weasel-worded nonsense. So now ISO-9000 simply means . . . well it impossible to tell. In the past, an ISO-9000 company had to implement a trouble ticketing system. But today, an ISO-9000 system has no such hard requirement.

WHAT I LIKE ABOUT TOYOTAS POLICY

Understand that a policy lasts only as long as the employees buy-in to it. Great enthusiasm at first followed by enu six months later breeds contempt and justifiable skepticism. But the elements are there:

• Improved Quality Inspection Process - you can't 'inspect in quality' but improvements can mean defects are treated as a teaching moment. It also means looking beyond the surface, the initial symptom.
• Enhanced Customer Research - this hopefully is not just a 'satisfaction survey' meant to prove "we're doing OK." Rather it means farming customer feedback to polish the car and get the specifications for the next release or upgrade.
• Automotive Center of Quality Excellence - GE had an R&D lab that was an excellent resource for programs that needed research quality support, say a mathematician's skills. It can be a place where the science and art can exists as a core, corporate resource.
• Support from Outside Experts - this is risky because some outside experts can be toxic. However, it can also bring in a point of view that breaks through corporate culture that might not have noticed 'the world has changed.'
• Increased Communication - another difficult area that takes deft skill. It is sometimes difficult to listen to what is really wrong from someone whose face is red, shouting and veins bulging from their neck. Concentration on the facts and data in communication is as much an art as anything else and should never be abused as a 'local anesthetic.'
• Improved regional autonomy - if I had to leave the USA, my choices would be coastal Canada, New Zealand, and Australia. Language, culture, and attitude counts a lot and these are places where our strengths and weakness would complement each other. But if I worked for Toyota, I would advise everyone to go back to school until we could read a Japanese newspaper because we need to both understand who and where we live yet effectively communicate with those who make our products.

The beginning of any quality program is a time of great promise and lofty goals. If these goals become practical programs that involve the customers in a closed-loop, it will lead to customer loyalty that will be a bastion for both innovative technology and sustained growth.

Bob Wilson

 

A quality program does not eliminate "end of life" for any product. It just means during the time of the manufacturer warranty, there are effective ways to get problems identified and corrected. It also means that next generation cars are not burdened with previous generation problems. For example:

• HC converter - dropped with NHW20
• Coolant tank - dropped with ZVW30
• NHW11 modules - dropped with NHW20
• flexi-body NHW20 - dropped with ZVW30
• neutral steering NHW11, NHW20(?) - reduced with ZVW30
• lower fuel efficiency above 65 mph - dropped with ZVW30
• weak heating - dropped with ZVW30

Even within the NHW20, there appears to have been a quality improvement around the 2006 model year. A mid-production tweak the corrected the MFD soldering problem and possible a few other tweaks. I'm also curious about the 2009 because the EPA user reported mileage is way out of line with the 2004-08 models.

So I'm looking forward to the quality program with no expectations that the problems with the NHW20, NHW11 or even the NHW10 will be retro-actively be 'fixed.' I'm not even expecting our ZVW30 to be rebuilt at the dealership. Rather, I'm expecting the 2012 Prius to be awesome.

Bob Wilson