Training systems and artificial intelligence

A few days ago, I got a message from a man named Momchil Penev, asking what I think about training systems and their vulnerabilities? It was an interesting question, and I had to tell him that I haven't thought about the subject in depth. Then he had a few more questions, and we started a conversation that I'll explain in some detail below. But in the meantime I started to wonder ... why haven't I spent more time thinking about training systems?

How important is training, really?

We all know that training is important to Quality: if people don't know how to do a job, they can't be expected to do it well. It even shows up in ISO 9001—clause 7.2 (c) says explicitly that if your people don't already know how to do the work, you have to make sure they learn. But as an auditor, I've never found that checking training records contributes a lot to the overall outcome of the audit, other than by checking the box for clause 7.2. If I'm going to find problems in the organization, it seems like they are always somewhere else.

But why? I think there are three reasons:

• Training records usually consist of a list of classes (for office staff) or a list of operations (for manufacturing and logistics personnel), each one signed off by a supervisor or instructor. Often there is no indication what the signature actually means, so all I can check is whether the paperwork is complete. (Remember this point, because we'll come back to it.)
• Most of the organizations I've audited are fairly small, or else they are small units inside large companies. It's hard for incompetence to hide in small companies, because people largely know what their neighbors are working on. I've been more likely to find that an employee's training record shows no signature for a skill that he knows very well, than to find a true gap in some mission-critical competency.
• On the whole, when people fail to follow established procedures, I haven't found that ignorance is the root cause. There's always something else going on. At least in my experience, the employees who take shortcuts that end in disaster know what they are supposed to do, but they choose not to do it.   

Sometimes training is not the problem!

This last point is important. Remember Alaska Airlines flight 1282, that lost a door plug shortly after takeoff on January 5, 2024? The best explanation I've ever read of the root causes behind this accident comes from an anonymous account posted to the Internet by a current Boeing employee. You can find it here. 

• This account makes the point that the door plug blew out because four bolts to hold it in place were missing.
• The bolts were missing because they had been removed in order to fix a different problem with the door plug.
• Then after that problem was fixed the bolts were never replaced because the workers forgot about them. 
• But if they had followed the established repair procedures they could not have forgotten. The only way they could possibly forget was by taking shortcuts.
• Why did they take a shortcut? Not because they were ignorant of the correct procedure, but because the procedure was too cumbersome and time-consuming. And they were already under pressure from management to hurry up.

Or consider a story that I tell in this post from a few years ago. In a factory that I represented, an external auditor wrote up one of our manufacturing personnel because he was running a plating bath and the liquid was at the wrong temperature. The procedure told him that if anything was wrong he should shut down the line and call the responsible manufacturing engineer (who was on vacation at the time). But in fact this employee had decades of experience with plating. He knew that he could compensate for the wrong temperature by making minor changes to the chemical mix in the bath. The end product was indistinguishable from one made according to the instructions, and this way we could ship it to the customer on time rather than delaying the order two weeks until the engineer returned. We got an audit finding, but from the customer's perspective his solution was perfect.* In this case, the reason the employee failed to follow the written procedure was that he was confronting an unforeseen situation, and had the deep knowledge to improvise a solution.

This is why I say that in my experience, ignorance of a procedure hasn't generally been the root cause of failure to comply. By the same token, when I am coaching a team through an 8D report to resolve some failure, I don't accept "Retrain employees" as a corrective action. There has got to be something more substantive behind the problem.  

But training systems can still be more robust

All that having been said, training systems are still necessary. And like anything else, they can always be improved. This brings me back to my conversation with Momchil Penev, who wants to use artificial intelligence technology to improve them.

Penev is the founder of skillia.AI, and his idea is an interesting one. It's a bit of a right-angle turn in our discussion, but let me take a minute to explain what he is doing.

As I say, it's an interesting idea. In general I'm something of an AI-skeptic; and as noted above, training by itself won't solve all Quality problems. But it still has to be done, and the records still have to be up to date! If Penev can find a problem and then solve it, that's how Progress happens. I wish him well. 

POSTSCRIPT: During our conversation, Penev told me that he is eager to get feedback from people in the Quality business about the performance and limitations of his tool. This means you! So while I have no financial stake in Penev's success or failure, I told him I would post his Contact page. You can reach him at https://skillia.ai/contact. Tell him what you think of his ideas, or ask how you can test the tool for free. 

__________

* For further discussion of this finding, see the referenced post.     

 

      

How do you manage "special responsibilities"?

One of the first things you learn when you write formal procedures is, Don't use personal names! 

Let's say you are writing a calibration procedure. As long as anyone can remember, Dave has been checking the calibration of all your tools on a rolling cycle, so he checks each tool twice a year and records the results in an Excel sheet. Finally you get around to documenting what he does in a procedure. What you must not write is, "Dave checks the tools twice a year on a rolling cycle." Why not? Because if you use Dave's name in the procedure, sure as anything he'll move to Tahiti next month and you'll have to update the document to name someone else.

So you replace Dave's name with a functional title, and write: "The Calibration Coordinator checks the tools twice a year on a rolling cycle." Note that this isn't Dave's job title. In many companies, Dave's job title is something like "Engineer 2" that can be correlated with his pay grade. And you certainly don't want just any old "Engineer 2" to do this job. The person who does it—Dave, or his successor—has to be qualified by knowing about calibration. That's why you create a special functional title just for the sake of this specific document, and you call Dave the "Calibration Coordinator."

As you write procedure documents for your operations, you'll do this several times—half a dozen, maybe more or less, depending on how complex or specialized your operations are. When you are done, you'll have a collection of functional titles that exist only in your procedure documentation, to account for specific roles your quality management system needs. These functional titles identify your QMS's Special Responsibilities. Of course in practice they just point to Dave and Pat and Sue and Sam, who handle the respective tasks. And when the auditor reads your Calibration Procedure and asks, "Calibration Coordinator? Who's that?" right away you say "Dave."

Then the auditor asks, "How do you know?"

Make a list 

One way to manage these assignments is to make a list. Seriously, it can be that easy. Just read through the formal procedures in your QMS, and write down every Special Responsibility they define. Then publish a List of Special Responsibilities (LoSR). For each entry in the List, identify the following four pieces of information:

• 
  Title of the role? (e.g., Calibration Coordinator)
• What document defines the responsibilities? (e.g., Calibration Procedure)
• Who is assigned to that role? (e.g., Dave Smith)
• Who is the Proxy, in case the regular assignee is out? (e.g., Pat Jones)

And that's it. The next steps are just as straightforward: 

• Make sure the List is formally approved by a suitable authority. (Since the list covers roles throughout your QMS, the "suitable authority" is usually your top management.)
• Formally identify the List as part of your QMS documentation.
• Maintain the List through formal change control, so that it is always up to date and so that the assignments are communicated to all stakeholders.

Enhance your documents

There's one loose end, but it is easy to tie up. Remember I said that not just anybody can be Calibration Coordinator? Spell out the qualifications for the role. 

An easy place to document them is in the same procedure document that defines the role in the first place. For example, your Calibration Procedure explains all the steps required to calibrate your equipment; so you can easily add one extra paragraph that spells out the necessary qualifications for the Calibration Coordinator. 

Then Dave's training records include an entry that shows how he met the qualification requirements. Maybe he took a class and got a certificate; or maybe he learned on the job from his predecessor, who sent an email when Dave was ready. Either way, the assignment and Dave's qualifications are fully traceable.

• The List of Special Responsibilites assigns Dave to his role, and references the document that explains it in detail.
• The document also lists the qualification requirements.
• And Dave's training records show that he meets those requirements.

If you have used other approaches you like better, leave me a note in the comments.

    

The mismeasure of performance

We've been talking for the last couple of months about metrics: how to make them work for you, and what common issues to avoid. And there's no question but that they can be very powerful. Rightly applied, quantitative metrics can give you unparalleled insight into the behavior of a process, allowing you to fine-tune it to improve efficiency and eliminate errors.

If metrics can tell us so much about our processes and machines, it is only natural to want to apply them to our people as well. After all, if Fred is more productive than Max, isn't it only fair for us to know this, and to reward Fred accordingly? It seems like an obvious line of thought, and in fact many companies have some kind of performance appraisal system in place.

So it's interesting that a number of high-profile voices have spoken out against the whole concept of annual performance reviews. Jack Dorsey—co-founder of Twitter and CEO of Block—is famously against them. Perhaps more seriously, so was W. Edwards Deming, who identified annual performance reviews as one of his "Seven Deadly Diseases of Management."

What's wrong with reviews?

If metrics are generally so useful, and if the use of metrics to evaluate human performance sounds so plausible, what's wrong with it? Why are Deming and Dorsey—and others, to be sure*—so opposed to them?

Jack Dorsey By cellanr - ,
CC BY-SA 2.0, Link

Their main objection is empirical: Deming and Dorsey both observe that no system of annual performance reviews ever seems to deliver the benefits that it promises. On the whole, performance doesn't improve. (Indeed, over time it may degrade.) People go through all the motions, but no one's heart is in it. And in the end the organization is left doing no better than it would have done without these reviews.

That doesn't mean that either Deming or Dorsey wants to do away with feedback between manager and employee. Not at all. They just argue that asking employees to hit numerical targets is an unreliable way to generate feedback, and talking only once a year is far too little. 

• More precisely, Deming advises that 90-95% of an employee's performance is determined by the system and not the employee's individual initiative, so improvement efforts have to focus on making the system better and not simply on making the employees more zealous. He agrees that it is important for employees to feel motivated, but argues that the most effective motivations come from the work itself, and from feeling fully engaged by the organization's leadership.
• For his part, Dorsey recommends ongoing, real-time conversation between employees and management on how well the work is getting done, along with focused coaching where needed to improve an employee's skills in the moment. Why wait another eleven months if you can address the topic now and get past it?  

How can this be?

This is all logical, so where did our original line of thought go wrong? What's wrong with applying the basic logic behind metrics to measuring human performance?

The error came in forgetting the cautions we have already observed about the use of metrics, because every single one of them applies to this use case. 

• We can't measure everything, so we have to choose to track this instead of that; but every time we choose a metric, the choice has a hidden bias which will skew the results one way or another. 
• When people know they are to be rewarded or punished based on the outcome of a particular metric, they will optimize the metric at all costs, even if that means undermining the organization's larger goals. 
• And often there are critical facts which can't be quantified, and which are therefore left out of account by any metric. 
• With respect to this last point, it's true that you don't have to quantify everything, and that sometimes a very simple number is enough to give you the guidance you need. 
• But that's mostly true when the choices you have to make are very simple. Human behavior, though, is wonderfully complex and subtle; and for anything complex and subtle, the risk is high of missing it completely unless your measuring tool is equally subtle. 

All in all, managing human behavior with a numerical dashboard is likely to miss all the things you really need to know. 

So yes, measure your processes. Measure your tools. But when it comes to your people, talk to them instead. You'll learn a lot more that way. 

Maybe I can end with a definition I saw recently, posted online by the reliably-entertaining Ralph Aboujaoude Diaz:

__________

* See, purely as an example, this recent post in LinkedIn.

           

What about human error? Part 2 of 2

Last week I talked about the concept of "human error" — and especially about why we in the Quality business always insist that "There's no such thing as human error" when it's obvious that there is. I argued that while of course we all know that humans make mistakes, that's never the place to stop in an incident-investigation: focusing hard on human error makes your participants clam up if they are afraid of being blamed, and it shuts off the chance to find systemic improvements that could make future mistakes less likely. Another way to say this is to say that human error is a symptom but not a cause. Somewhere in your system, there is something else that triggered or allowed the human error to happen, and that's the thing you want to find and control.

But if human error is a symptom then we really need to understand what kinds of human error we might encounter, because each different kind of error is probably a symptom of a different cause and therefore has to be treated in a different way. If you go to the doctor because of pain, he'll treat you differently depending whether the pain is in your head or your elbow.

Fortunately this work has already been analyzed and tabulated. The information that I provide below comes from a website page owned and administered by the United Kingdom's Crown Health and Safety Executive, and I gratefully acknowledge permission to use it, as follows: This blog post contains public sector information published by the Health and Safety Executive and licensed under the Open Government License. The full text of the Open Government License for public sector information can be found here.

So, what are the different kinds of human error?

In the first place, a failure is either:

• Inadvertent (an error)
• Deliberate (a violation)

Errors can be either:

• Action errors (where our action is not as planned)
• Thinking errors (where our action is as planned but we planned the wrong thing)

Action errors can be either:

• Slips (where we do something wrong)
• Example: Flip a switch up instead of down.
• Example: Transpose digits during data entry.
• Lapses (where we fail to do something right)
• Example: Forget to signal before turning at an intersection.
• Example: Skip a step in a safety-critical procedure.

Thinking errors can be either:

• Rule-based mistakes (where we misapply a good rule or else apply a bad rule)
• Example: Misjudge passing the car in front of you, because you would have plenty of room if you were in your own car, but you are in your friend's car which has a lot less power.
• Knowledge-based mistakes (where we have no rules and try to figure it out from scratch)
• Example: Rely on an out-of-date map to plan your route through an unfamiliar town.

Finally, violations can be either:

• Routine (where there is no meaningful enforcement, so everyone ignores the rule)
• Example: A lot of cars on the freeway ignore the posted speed limit.
• Situational (where we cut corners in certain cases, because of features specific to those cases)
• Example: You document your design reviews scrupulously for new designs, but never document them for subsequent Engineering Changes because they always look so obvious you can't see taking the time to write them down.
• Exceptional (where we take a calculated risk in breaking the rules in order to address a highly-unusual situation)
• Example: A huge production order in your factory is due by Friday. On Tuesday, one of your machines comes due for preventive maintenance, but you keep it running (rather than shutting it down the way you are supposed to) because that's the only way to meet the production deadline.

That's the list.

Now what do we do about them?

Notice first of all that an approach which works for one kind of failure really won't help with another kind. Requiring someone to fill out a checklist is very likely to prevent lapses, but it will be completely useless in preventing (say) exceptional violations. A checklist, after all, helps the memory, and in case of a lapse the operator just forgot a step. But in the case of an exceptional violation, the operator knows perfectly well what steps he is choosing to skip — and why — so a reminder (in the form of a checklist) will make no difference at all.

The kinds of steps to consider are things like these.

You can download a useful reminder table, which summarizes all this information and more, from my Downloads Page.

     

What about human error? Part 1 of 2

It's a commonplace in the Quality business that any time we start a problem investigation, we insist that "there is no such thing as human error." I say it in this post here. But what does that mean, anyway? And is it true?

At a superficial level, at any rate, it looks like there is something wrong. About a month ago the topic came up in this post and this one on LinkedIn. If the links don't open for you, the basic point is made by Christopher Paris, who points out that obviously all errors are made by humans! After all, they certainly aren't made by space aliens.

Obviously Paris is right that errors are made by human beings and not space aliens. But sometimes I think he's a little too hard on those of us in the Quality industry.* For myself, I've always taken the principle about human error as a motivational slogan rather than a statement of fact, and I think that in a pragmatic sense it performs two roles.

First, if you want to do a decent root-cause analysis, you have to get all the facts. This means getting the cooperation of whoever was there on-site when the problem happened. Now if this employee thinks you're going to blame the whole thing on him and his errors, he's not going to tell you a thing. So you start off by saying that the problem has to be with the system, not with him, and you just need his help to figure out how to improve the system. With luck this will put him at his ease, so you can make progress.

Second, sometimes when your problem-solving team is in the middle of its work, you'll have someone who really wants to get back to his desk to work on something else instead. So he says, "Look, this whole accident was caused by human error. Next time we just have to try harder, that's all. So can we wrap it up and get back to our real jobs?" The problem is that "trying harder" has never solved anything. Often — nearly always, in fact — there is something that can be improved in the system to make it easier to do the job right and harder to make a mistake. So to keep your team from giving up too early, you remind them that "there is no such thing as human error," and if they really believe in "trying harder" then the problem-solving team should try harder to find a systemic cause.

What do I mean by a "systemic cause"? It's the kind of thing I talked about here (and then expanded on in the next two posts here and especially here). If someone made a mistake out of ignorance, see if you can improve your training system. If someone made a mistake because his hand slipped, see if you can get him a tool that makes the work easier. If someone forgot that those drums were filled with nasty waste until he almost dropped his lunch in one of them (let's say it was a "near-miss" and nothing bad actually happened to the lunch), see if you can label the drums or put up signs. Those are all system-level improvements.

At the same time, it's important to notice something else. You remember that there's no such thing as a perfect process, and in the same way there's no such thing as a perfect system. There's even an old joke that says, "You cannot make things foolproof because fools are so ingenious." So while the problem-solving team always has to look for additional system improvements, the organizational management has to emphasize improving the overall competence of every employee. This is because, as we discussed a couple months ago, good people can work under bad processes a lot better than bad people can work under good processes. So the best way to error-proof your operation, so far as you can, is to strengthen both.

Next week we'll look at a typology of human errors, and at the preventive measures which work for each one. It turns out there are several different kinds of human error, and the measures which prevent this kind are no help at preventing that kind. Join me.     

__________

* In fairness, his stated purpose is to motivate us to pull up our socks on a number of basic issues, so it's to be expected that he not go easy on us.

      

Process fragility — or — "People Before Process" Part 3 of 3

In last week's post we saw that there are powerful reasons why companies build up their process systems, while the motives to build up their people are often less obvious or less urgent. But the week before, we saw that in the long run it looks more important for an organization to have the right people than to have the right process; because good people will improve a bad process, while bad people will degrade a good one. What does this mean? Is it just one more case where the easy and obvious motives line up in support of short-term benefits at the cost of long-term ones?

Maybe so, but in the full picture we can see other things as well. The first of these is that a reliance on process is fragile, while a reliance on competence is resilient. Let me tell you a story.

Once upon a time, I helped to support the Quality system in a small factory. The factory had run successfully, under one owner or another, for most of the 20th century; some people operating the lines had worked there all their lives and were nearing retirement age. Recently the factory had been acquired by a new owner, and part of the "post-merger integration" was to implement the new owner's QMS across the board. This meant, among other things, generating Control Plans for every factory operation — something that had never been done before. A couple of manufacturing engineers were assigned the task; they made a quick inventory of all the things the factory could do, listed the steps for each in an Excel table, and published the results as Control Plans.

Then one day it was time for our external surveillance audit. In order to audit section 8.5.1 of ISO 9001:2015, the auditor asked for a Control Plan. We offered him several, and he picked one that covered the plating bath. Then he walked out on the line to watch it in action. Right away he discovered that one of the vats was at the wrong temperature. The defined reaction in the Control Plan was, "Stop the line and call the manufacturing engineer," but the line was still running. Our auditor had been watching the process for less than five minutes, and — presto! — he found a Nonconformity.

When the day was over and the auditor had gone back to his hotel for the night, my boss and I walked out on the line to ask the operator what was going on. What was he thinking, to keep running the line when the temperature was significantly outside of range? He wasn't the least bit bothered. He explained that the plating reaction depended on both the temperature of the bath and its chemical composition. When he saw that the heater for one vat was malfunctioning, he changed the chemical composition of that specific stage of the bath to compensate. The final output would be indistinguishable; the customer would get exactly what they ordered, and there would be no need to delay this production order. And a good thing too, because he happened to know that the responsible manufacturing engineer was on vacation for another week yet. But he assured us it was all fine. The product would be correct, and the customer would be happy.

"All fine" is a matter of perspective, of course. My boss and I had to do a lot of talking to persuade the auditor to rate this Nonconformity as a Minor and not a Major. But from the customer's perspective it really was "all fine." The product that shipped to the customer really was going to be indistinguishable from one that had been made at the right temperature and with the defined chemical bath. This means two things:

• From the perspective of the audit, the finding really should have been a Major Nonconformity, because the system was absolutely not working the way it was defined (on paper). The written Control Plan said that if anything was out of adjustment, the whole process should stop until the responsible manufacturing engineer could review the situation and instruct the operators what to do. (And that would have been another week, at least.)
• But if the organization had followed the written Control Plan, the order would have been a week late — needlessly! In this particular case, the operator himself already knew exactly what to do because he was so deeply familiar with the process. Because the operator could rely on his own competence, work did not stop ... the order was not late ... and the customer was not disappointed. Because the operator could rely on his own competence, the organization could confront an unexpected problem and then roll with it — resiliently.

It still should have been a Major Nonconformity from the perspective of the audit. But probably the operator never even looked at the Control Plan. That should have been another Nonconformity, come to think of it.*

This is what I mean when I say that relying on process is fragile. No written process can possibly cover all situations that might arise, so every written process runs the risk that one day the organization will face a situation that the process does not address. When this happens, the process breaks down. But relying on competence is resilient, because a well-trained expert with deep knowledge of the process can figure out a response to any unexpected situation, with a high probability of getting it right.

Notice something else. The whole pattern of thought and planning that underlies modern industrial capitalism favors this fragile, process-based approach over the resilient, competence-based one. For consider:

• On the one hand, someone who is simply trained to follow a process (and no more than that) is unprepared to solve problems or handle novel situations on his own. But he is a lot cheaper than the employee with wide experience and deep knowledge.
• On the other hand, most of the time your organization shouldn't be facing problems or novel situations.
• Therefore in principle you shouldn't need your line operators to have wide experience or deep knowledge. If you have one knowledgeable problem-solver for every ten ignorant line operators, that should give you plenty of coverage for the number of problems you are actually likely to face and it's a lot more cost-effective than training everyone.
• What's more, this arrangement means that your line operators are interchangeable human resources. You can move them wherever you need them in the organization. As long as they know how to follow procedures, you can use them to carry out any task that has been defined by a written procedure. And this gives you far more flexibility than you would have if they were tied to specific tasks because that's all they knew. This is what you want.

But look where this line of calculation takes us. By following the ordinary patterns of thought and planning that underlie modern industrial capitalism, we end up adopting a policy towards our people which has been proven to be very powerful, and which supports indefinite expansion; but this same policy makes our whole organization more fragile, and risks bringing us to our knees if something truly unusual happens.

How can this be? Is there something wrong with the theory?

Well yes, in a sense. Peter Drucker argued for years that our economy is no longer truly "capitalist" because Capital is no longer the most important factor of production. Capital is almost irrelevant these days, because it can be crowdsourced — either in a traditional manner, by issuing shares of stock; or in a contemporary manner, by launching a campaign on GoFundMe. The critical factor of production today, in Drucker's argument, is Knowledge; and the most critical member of any organization is the knowledge worker. (Drucker argued this point in many places but see for example his Post-Capitalist Society (1993).) A knowledge worker is any employee whose unique value comes from the knowledge he carries in his head. And because that knowledge is always of something specific, knowledge workers are in general not interchangeable. (If you have too many quality auditors, it is typically not easy to repurpose some of them as accountants or design engineers.)

Note also that the story above about the plating bath shows that even line operators can be knowledge workers. As a result, the whole approach of treating line employees as interchangeable units starts to look misguided or (at best) out of date.

None of this is to deny that a process focus really is very powerful in the short run. But if anything happens to interrupt normal operations — if, ... oh I don't know, ... say a global pandemic throws the Designated Problem-Solvers out of the office at the same time that it disrupts all the organization's supply chains — then an organization that has relied on a process-focus will be in deep difficulties, while an organization that has built up the competence of all its employees will be able to roll with the changes and adapt.

This development is something that we in the Quality business need to understand and pay attention to. We've heard the message before: W. Edwards Deming insisted in his fourteen key principles on the need for training on the job (point 6), for breaking down barriers between functions (point 9), for pride of workmanship (point 11), and for a "vigorous program of education and self-improvement" (point 13). But we have yet to integrate these concepts into the "common sense" understanding that all Quality professionals carry around with them. We have yet to rewrite our standards — like ISO 9001 — so they give as much attention to people as to processes.

We can do this. Once upon a time, we Quality professionals didn't all think in terms of statistical variation, but now we do. Once upon a time we didn't all think in terms of business processes, but now we do. We can absorb this change just like all the others. But we need to start.

__________

* The attentive reader will have noticed that I describe the very same action as resilient (as well as good for both the customers and the company) and a potential Major Nonconformity. How can it be both? Aren't audits supposed to improve the company's behavior? Or am I trying to criticize audits as counterproductive?

I'm not criticizing audits per se, but the usefulness of any audit depends critically on the usefulness of the management system documentation that you are auditing against. In this case, the root cause of the finding was the slapdash way that the company threw together their Control Plans, aiming to get something written so they could check a box rather than thinking through what the controls should really be. Since what the operator actually did to respond to the condition was correct, it should have been permitted as one option under a proper Control Plan. Or else perhaps the operator's deep knowledge of the process could have qualified him to be designated as a responsible "Manufacturing Engineer" for this particular production line.

In real life, the company analyzed the audit finding and realized that all their other Control Plans were probably just as bad. So they started over from the beginning and rewrote the lot of them more carefully. It was the best possible response to that finding, and I was glad that's what they chose.         

"Why do we always revert to process?" — or — "People Before Process" Part 2 of 3

After I published last week's post, I got a note from Jeff Griffiths asking why I think we in the business world regularly put so much emphasis on process. Among other things, he wrote, "I think the reason organizations always seem to revert to process is that developing people and actively managing competency is hard work, and most front-line leaders aren’t trained to do it, and they certainly aren’t invited to do it. What’s your experience been?"

Of course he's right. But his note got me thinking. And the longer I thought about it, the more reasons I could see that organizations choose to emphasize process development.

In the first place, of course, there are the undeniable benefits of the process approach. A process focus supports continual improvement, by letting you understand the overall flow of your operations so you can see where there are blockages. A process focus permits standardization across functions or locations. A process focus facilitates interaction of multiple functions across an organization. And a process focus makes possible the "checklist effect," which enhances the performance even of deeply trained experts like pilots and surgeons. All of these are good things. Nothing that follows is meant to minimize any of these genuine benefits, and I would never suggest that you try to do without defined processes!   

But there are other reasons for the focus on process, and not all of these reasons are so obviously wholesome.

One reason, for example, is that Quality professionals — people like me — push the process approach so hard. That (in turn) is because the process approach is a major focus of the ISO 9001 standard. Section 0.3 of the Introduction is about nothing else. In the normative sections of ISO 9001:2015 (I mean chapters 4-10), the word process or processes occurs 57 times. By contrast: competence or competent occurs 9 times, training occurs twice, people occurs once, and skills shows up only in Annex B (well outside the normative chapters). So organizations can be forgiven for thinking that process is something they have to emphasize.

Another reason is that organizations know how to write processes — even if they don't follow all my advice from last summer, they can write something that's good enough to get by — but they often don't know how to develop their people. As Griffiths wrote to me, most front-line leaders aren't trained to do it. I can personally confirm that when I first became a manager, nobody took me aside to train me how to develop my people — nor even to give me some basic pointers. Of course there are companies that are happy to step in to help with the task — Griffiths himself works for one — but it seems like there aren't nearly enough of them, and of course none of them works for free.

Related to the foregoing is the simple fact that a process focus is easier and cheaper than a competence focus. A process focus is narrow and finite, while a competence focus is potentially infinite — there's always room to learn more and get better. This means that a process focus is easier to replicate at scale, and therefore supports expansion.

For example, McDonald's is well-known as a process-focused business. Everyone knows that McDonald's has defined an exact procedure for every aspect of running each restaurant. The result is that McDonald's has spread across the globe, with more than 37,000 stores in 120 countries. What is more, the food they serve (with the exception of minor regional specialties) is absolutely uniform. When you place an order in a McDonald's, you know what you are going to get.

Contrast this with a restaurant that is not so process-focused, such as Le Bernardin in New York City. No doubt Le Bernardin uses some recipes, and there must be procedures for how to take reservations or manage the flow of customers. But there is also room for a cook to express personal artistry. And while Le Bernardin has been — in its class and with respect to its own (very different) criteria — every bit as successful as McDonald's, nonetheless there is only one.

For a more dramatic example, consider the situation of American war materiel when the country first entered World War Two. Nearly all weapons required precision optical sighting devices to aim them, and the best lenses in the world were all ground in Germany by deeply trained experts who had served long years of apprenticeship. So far as anyone knew at the time, that was the only way to get lenses ground. Peter Drucker tells the story:

Belief in the mystery of craft and skill persisted, as did the assumption that long years of apprenticeship were needed to acquire both. Indeed, Hitler went to war with the United States on the strength of that assumption. Convinced that it took five years or more to train optical craftsmen (whose skills are essential to modern warfare), he thought it would be at least that long before America could field an effective army and air force in Europe—and so declared war after the Japanese attack on Pearl Harbor.

We know now [Frederick W.] Taylor was right. The United States had almost no optical craftsmen in 1941. And modern warfare indeed requires precision optics in large quantities. But by applying Taylor’s methods of scientific management, within a few months the United States trained semiskilled workers to turn out more highly advanced optics than even the Germans were producing, and on an assembly line to boot. And by that time, Taylor’s first-class men with their increased productivity were also making a great deal more money than any craftsman of 1911 had ever dreamed of.

(You can find Drucker's article, from which these paragraphs are extracted, here. There is a short video about the same topic, made in 1945, available here.)

In short, there are powerful motives pushing businesses to adopt a process focus, even if it comes at the expense of putting similar effort into developing their people. And yet we saw last week that in the long run, investment in people is more important than investment in process. At the level of the individual firm, this is something to watch. Be careful that you don't overemphasize an approach that will give you only a limited return on your investment.

There are also implications for how we understand the broader economy, and in particular for how we Quality professionals practice our craft. I will address both of those topics next week. 

                     

"People Before Process"

A few weeks ago, I had the good luck to attend a webinar called "People Before Process." This webinar was a real treat. It was clear, engaging, and insightful. And it touched on themes that I have discussed before about the role that defined processes play in achieving Quality — in getting what you want.

Before I forget, here are a few particulars. The talk was sponsored by the ASQ's Quality Management Division, and speaker was Jeff Griffiths ("About" page, LinkedIn). If you are a member of ASQ, you can access the video here. But he discusses some of the same concepts in less detail here (no need for an ASQ membership) and you can find him in a number of video conversations here.

Griffiths's fundamental point throughout these talks is that, if you want to get results, there is no substitute for having the right people to get you those results. Starting from that foundation, he then discusses various ways that an organization can plant, nourish, and grow the needed competencies in their people. In the webinar I joined he introduced the Dreyfus model to distinguish multiple levels of skill acquisition, and described client quality problems that his firm had helped resolve specifically through enhancing worker competency rather than by introducing new procedures.

To make the point that people are more important than process, Griffiths proposed an interesting thought experiment. Suppose, he said, you have a table like the one below, and that your organization can fall in one of the four quadrants depending whether your people are strong or weak and whether your processes are strong or weak.

Of course anyone who has a choice wants to be in quadrant II, with strong people and strong processes. Likewise we can all agree that our last choice is to be in quadrant IV. That part is easy. But what if we have to choose between quadrant I and quadrant III? Griffiths argues that we are far better off in quadrant III, because if the people in the organization are fundamentally strong and competent — but they have been saddled with processes that are weak or badly-designed — the people will change the processes into something that works better, and thus will pull the organization in the direction of quadrant II. But if you have weak people — poorly trained, uncaring, or actively disengaged — the best process in the world can't overcome them.

Quadrant III is better because it is temporary: it is always pulling towards II.

Is it true? I think so. Even when an organization is not in control of their own processes*, they can make improvements at a daily level by interpreting the rules so they support the work, applying and enforcing them in ways that are helpful and productive. There is no single instruction for how to do this that fits all cases, no one-size-fits-all formula. Each situation has to be evaluated on its own. But in my experience it is possible.  

When I look at the table, I see something else too, something Griffiths never says explicitly. I bet that quadrant I is always pulling towards quadrant IV. Think about it. Suppose you have an organization with an excellent set of written processes, but where the people are poorly trained for the work and don't understand the processes — or don't care. What happens? That's easy: Scott Adams has made an entire career writing about it in Dilbert. Look at all the jokes made at the expense of ISO 9001: the standard itself is more or less a body of formalized common-sense, but when it is badly implemented or badly-applied it becomes a punchline. And so, bit by bit, processes which were once helpful and robust are misused and misapplied; enforcement is either too strict or too loose (or veers unpredictably between one and the other); the processes thus become obstructions rather than enablers; and the organization drifts from I to IV.

If people are so much more important than process, why do I write about process? The simplest answer is that I write what I know; further, I never said process was irrelevant. Obviously your business processes and the structure of your QMS still make a significant difference to your outcomes. But the overriding theme of this blog is that any QMS has to be applied pragmatically; this means that the system itself can never solve all your problems. The centrality of your people is one huge reason why not. 

If you find yourself wondering what to do about that fact and where to turn next, check out Griffiths's organization and blog. You'll find some advice there. 

__________

* This can happen in, say, a global company that requires all units to follow the same processes even if they do different work.