Context and risk

A few days ago, I attended another of Christopher Paris's Oxebridge classes.* This one was about using Context of the Organization (COTO) as a tool to address the requirements for Risk-Based Thinking (RBT). The class was entertaining, like all of Paris's classes; but it also had solid content. If you didn't attend the session I did, there's still one more session offered on August 8 and I recommend it.

(No, Chris did not pay me to advertise his class. Do you think I should have asked him to?)

The basic idea behind the class is a simple one, but it's easy to miss: what kind of business you are in determines what kinds of risks you face. If you design medical devices, you face a different set of risks than if you manufacture cars. If you create video games, you face a different set of risks than if you operate a nuclear power plant. This should be obvious.

The reason it's easy to miss is that some organizations skimp on their COTO analysis, because they don't see the point of it. I've audited groups whose COTO analysis must have taken them ten minutes, tops.

Who are your interested parties? Shareholders, suppliers, customers, and society.

What are their expectations? Shareholders want us to be profitable, suppliers want us to pay our bills, customers want good products, and society wants us to offer jobs.

Really? That's it? I probably could have downloaded that list off the Internet too, without even knowing anything about your company.

But organizations get away with this because the documentation requirements for COTO are so thin. ISO 9001:2015 says you have to determine who your interested parties are and what they require of you, but it never says you have to keep records. And so organizations that don't understand the point of COTO do the minimum they think they can get away with, just "to satisfy the auditor." 

On the other hand, if you actually do a thorough job of analyzing your COTO, you can generate a list of your important business risks almost automatically, as a side-effect. Many of these will be topics that you are already aware of, to be sure. But don't be surprised if there are one or two that make you smack your head and ask, "Why didn't we ever think of that one before? It's so obvious now."

Paris's class walks you through how to do this work systematically, and he provides a log file template that is really elegant. It's not the only possible way to organize this information; I've seen at least one other layout I like, which looks rather different. But this one is good, and I'm happy to recommend it. 

If you haven't taken Paris's class yet, sign up for the upcoming session. And even if you pass on the training, spend some time thinking through your COTO. The effort will repay you by giving you clarity on what you are doing today and what you need to do next.    

__________

* I talk here about the last time I attended one of his classes.

Taiichi Ohno was wrong about profit

I may get drummed out of the Quality business for disagreeing with Taiichi Ohno, but I can't let this pass. A few days ago, someone published a post on LinkedIn that quoted Ohno as follows:

“I will say this again: the only way to generate a profit is to improve business performance and profit through efforts to reduce cost. This is not done by making workers slave away […] or to generate a profit by pursuing low labor costs, but by using truly rational and scientific methods to eliminate waste and reduce cost.”

Then the OP* went on to talk about Lean.

I have nothing against Lean, and I'm no particular fan of waste. I also recognize that Taiichi Ohno was a very smart man, so I hope this quote was taken out of context. But saying that the only way to make a profit is to cut costs is false. It is foolishness. It is dangerous rubbish.

Here's the problem in three words: costs are finite. Therefore you can only reduce them so far; and soon after you have used all your "rational and scientific methods to eliminate waste and reduce cost," your competitors will do the same thing and you will lose your advantage. Maybe you can eke out a temporary edge doing the things Ohno says to avoid: "by making workers slave away ... [or] pursuing lower labor costs."** But your competitors can do that too. There's no way to win a race to the bottom.

The only guaranteed way to generate a profit is to create value. Offer your customers something they are willing to pay for. Make it different from what the other guy is offering. Make it better. Do something extra, or something new. Whether you are making a product or offering a service, make sure your work has high quality—objective, indisputable Quality—and then charge a fair price for the quality that you are offering.

This is the only side of the equation that is potentially unlimited. 

Of course cost-reduction matters. I'm not denying that. And if Lean helps you make sense your operations, don't let me hold you back. You want to do the most with what you have, and that means working efficiently. Efficiency and systematic methods are good things, to be sure.

My only point is that they are limited. They can only get you so far. Failure to implement efficient methods can keep you from profitability; but efficiency by itself can never make you profitable.

Only value can do that. So create value.

__________

* Original Poster

** The temptation to do exactly this—and thereby to force inhuman conditions on your workers—is specifically why I used the word dangerous in calling this thesis "dangerous rubbish."             

What do you want me to write about?

Can we take time out for signals?

At this point I've got just about sixty blog posts here since I started publishing a little over a year ago. I've still got some more topics in mind, but I don't know which ones you want to read.

What I have noticed is that some posts are a lot more interesting than others. If I look at the overall view count, it comes out like this:

The really big spike towards the right was this post, which was pure humor. Some of the other often-viewed posts have been about auditing, or about the YouTube video of Steve Jobs talking about Joseph Juran, or about the burning question whether "lying to the public" can be part of your official procedure. But I'm not sure I can tell for sure what the difference is between those posts and some others that generated a lot less interest.

So let me know what's on your mind. What would you like to see me write about? I can keep thinking up topics out of the blue, but if there are things that interest you it's only fair for me to ask what they are and spend some more time on them. What would be helpful?

I'll be happy to hear from you.

    

Bureaucracy and its discontents

A few weeks ago, this column ran a four-part series about whether the proliferation of international standards would undermine economic productivity, under the umbrella title of "Parasitic certifications?" (Part 1, Part 2, Part 3, and Part 4.) Related to this discussion was a question whether the implementation of formal quality standards drives the growth of bureaucracy. 

The short answer is No. Bureaucracy is caused by the overall growth of the organization, and especially by centralization. It is possible to implement a quality system without adding much in the way of personnel, though admittedly you have to be a little clever about it.

To implement a quality system with minimal growth of personnel, you have to incorporate most of the basic quality functions into the daily work of the people doing the operative tasks. There will always be some irreducibly nonzero quantum of administrative work associated, and it is best to give this to someone dedicated to the task. But you don't need someone from Quality to sit in on design reviews, so long as the designers are doing them. You don't need someone from Quality carrying out inspections on the line, so long as you have institutionalized those inspections as part of regular practice. If people know what they have to do and why, you don't need a lot of extra bodies tasked with enforcement.

So what explains bureaucracy? I claim that there are two drivers: growth and centralization.

Growth is the first driver, because the more people there are in an organization, the more communication links there are: and the number of links grows as the square of the number of individuals. (In principle the number of links among n people = n(n-1)/2.) 

Bureaucracy is just a tool for managing this communication by slowing it down and channeling it. If you think that bureaucracy makes everything slower and more difficult, well, yes, that's the point. In a large organization the alternative, where internal communication is completely free, would be chaos.

But when I talk about "size," I mean the size of the operational unit, not some larger entity of which it might putatively be a part. There's a video on YouTube where Jeff Griffiths tells a story about working in a team that nimbly exploited their members' multiple competencies, well outside of their job descriptions. It's a story that illustrates some of the larger points he makes regularly about the importance of building and leveraging employee competency. And the organization he was part of, at this time, was the Canadian Armed Forces. Obviously the Canadian Armed Forces are not a small organization. The point is that his team numbered only twelve, and they were out on their own in the middle of nowhere. If the team had numbered 120 and they had been stationed near headquarters, it would have been impossible for them to have worked so adaptively.

In other words, if you belong to a small team which is left alone to do your work in isolation, you can work as a small organization: lightly, quickly, and free of bureaucracy. When you are forced to integrate with a larger entity, that's when you get bureaucracy and your work slows down.

Why would you ever be forced to work more slowly, though?

The process that forces you to integrate with a larger entity is centralization, and there can be a lot of motives pushing centralization.

• Centralization is cheaper and more efficient than dispersal. If one Purchasing department and one Human Resources department can service five offices, why would you ever pay for five of each?
• Centralization is simpler than dispersal. It's always easier to deal with one supplier for a given commodity than to manage a dozen. And it's always easier to deal with a few large customers than a hundred small ones.
• At some level, centralization is simply inherent in the nature of organizations. (The sociologist Robert Michels worked on this topic.)  

To be fair, centralization has its drawbacks, too.

• Centralization may be cheaper and simpler than dispersal, but it is a lot more fragile. If you have one Purchasing department supporting five offices and that one department loses power, or loses its Internet connection, or is shut down for a pandemic, you could be in a world of hurt. If each office has its own Purchasing agent, one of them can step in to pick up the extra buying, and business can continue.
• If your single-source supplier goes bust, you have to qualify a new one from scratch. If you have only twelve huge customers worldwide, there's a nontrivial chance that they might all postpone additional purchases during lean times and suddenly you have no income. That's less likely to happen if you have a hundred small customers. 
• Small organizations are far less likely to suffer from employee disengagement, because everyone can see right away how they personally make a difference. In huge organizations it's a lot easier to put in your eight hours and go home, because the big picture is literally too big for you to see it at all.

So what's the answer? Should companies deliberately try to fail, so they can stay small?

Not quite. But there's a lot to be said for decentralization. Interestingly Amazon — which looks like a global behemoth in anybody's book — has taken some steps in this direction.

One is the famous "two-pizza rule": if a team can't be fed with two pizzas, it's too big. This rule forces teams to be small and manageable.

Another is just as important: the API mandate. This rule seems to have grown out of Jeff Bezos's insistence that "Communication is terrible!" The idea is that every team in Amazon is required to communicate with other teams only through a single API and in no other way. Part of the point was to force Amazon to think in terms of service-oriented architecture. But for our current purposes another consequence was that this mandate reduced the amount of internal communication that was possible at Amazon, and forced it all into highly-predictable channels. That's what bureaucracy is supposed to do. In other words, by (1) forcing teams to be small, and by (2) choking off the (otherwise exponential) growth of communication links, Amazon eliminated the need for the kind of massive bureaucracy that a company of 1.6 million employees worldwide would normally require.

Maybe your company doesn't plan to imitate Amazon. But at least there are options.