When half a loaf is worse than none

You work in a small office that's part of a big organization, and the experts at Headquarters just issued a new regulation. Everyone has to comply. You don't have the budget to implement the whole thing, but you could do half of it with no trouble. Should you do that half, just to show good faith? Isn't half a loaf better than none? 

Not so fast. It all depends.

Of course sometimes that's the right thing to do. Implement Part One now, and make a plan to implement Part Two next year when you can afford it. Communicate with the people at Headquarters so everyone understands the situation, and make incremental progress.

But evaluate every situation on its own. Sometimes implementing half a loaf will undermine you, and you would do better to wait till you can do the whole thing at once.

I was in exactly this situation once, years ago. I was working for a small, entrepreneurial startup that had just been acquired by a global company. The global company had a lot of systems and regulations that we had to learn in a hurry.

One bundle of regulations addressed security. Every office and every plant worldwide—except ours—issued employee badges. Those badges let you into the building at your site. If there were restricted areas at your site, your badge could be fine-tuned to let you into exactly the areas you were allowed to access. If you went to work in a new location, your badge could be reprogrammed to open the doors at the new location instead. It was a complex, interconnected system.

We had none of that.

And right away, visitors started to comment. 

"What, no badges? How can you work for Big Company without badges?" 

"Gosh, the next time I need a new printer I'll just fly out here and take one from your office since your security is so lax."

"Does Headquarters know that you guys don't have badges?"

Someone in my department decided we should do something right away. She started scheduling appointments for everyone in our office to have a picture taken, and ordered a box of badge blanks. She was halfway through taking all the pictures before I had a chance to sit down with her and ask what she was thinking.

"Well everyone keeps saying we need badges. I figured I could make badges, and then our guests would be happy."

"But badges are just part of the picture," I reminded her. "What about the electronic keys and the huge IT infrastructure that links us into the rest of Big Company worldwide? Where is the budget for that going to come from, and who is going to implement it?"

"I thought we could do that later."

That was the key. She figured half a loaf is better than none, and in a different case she might have been right. But in this specific case, it didn't work, and couldn't possibly work.

I told her, "Think a minute. Suppose it is the day after you issue badges to everyone, and explain they are mandatory. How are you going to enforce them?"

"What?"

"Say that Frank forgets his badge at home. But he can still get into the building, right? Because the badge isn't an electronic key, so it isn't hooked into the security system. Did you think we were going to hire guards to stand at the door and stop people without badges?"

"No."

"That's right. There's no budget for that. Only then what happens is that everyone realizes the rule about wearing badges has no teeth. They can openly ignore it, with no consequences. And then the next time we have to implement a new rule from Big Company, it'll be twice as hard."

"So what do you want me to do? Should I run around the building every day to check that people have their badges on?"

"No. What I want is for us to wait and do nothing until we can afford to implement the whole package all at once."

That's what we did, and it took a couple of years until the electronic entry system became a high enough priority for our management to pay for it. In the meantime, Big Company understood that we were non-compliant with that specific set of security requirements, and treated the situation as a known risk to be managed. Mostly it didn't take a lot of attention, and we all went about our business just fine. When the day finally came, we did everything at once; we were fully integrated into Big Company's IT infrastructure; and, yes, we got our badges.

Every case is different. There is no substitute for thinking through all the details to understand what happens if you take this option or that one. But sometimes it is simpler just to be noncompliant—fully above-board, so that you are known to be non-compliant—than to get tangled in the complexities of trying to do something halfway.

           

How to overcome "Cartesian anxiety"

A few months ago, James Pomeroy of the Arup consultancy group published an article in LinkedIn on what he called "Cartesian anxiety"—the fear that, without proper planning and metrics, we are all lost. And yet, Pomeroy continues, planning and metrics can never prepare us for every eventuality.

Pomeroy's argument should sound familiar to regular readers of this blog. He begins by describing a mindset that he finds to be common among professionals in Quality, safety, and environmental management. He calls this "a PDCA mindset," and describes its fundamental tenets as follows:

• Planning is Paramount
• Variance is to be Controlled
• Measurement is Everything
• Causality is King
• Hindsight Bias

We've discussed many of these topics before. (See the embedded links for some relevant posts.)

But then Pomeroy goes on to point out just how fragile these assumptions are. In normal operations, of course they are fine; in fact, in normal operations these principles more or less define how to function best. But "in situations of significant uncertainty, high levels of complexity or a continually emerging environment, deterministic methods such as PDCA become problematic." These methods break down because they rely on certain preconditions to operate.

• In order to plan, you have to know what the default future will look like (before you act), so that you can assess what to do. 
• In order to measure, you have to know what to measure and you need a way to observe it without disturbing it. 
• In order to form any kind of cause-and-effect analysis, you need enough data to understand what interacts with what, and you need a clear understanding of how they interact—an understanding, so to speak, of which direction the causal arrows point. 

And under conditions of serious uncertainty, high complexity, or rapid change, none of those preconditions obtain.

Does that mean that when things get crazy, then all is lost? Not at all, says Pomeroy. But at that point the organization has to rely on other tools besides planning and measuring. He tells the famous story of the Hungarian soldiers lost in the Alps, who were saved by following the wrong map.* And he argues that in times of crisis it is better for the organization to do something, see the outcome, and react promptly—"feeling" its way through the tumult—rather than to wait for things to settle down far enough that the planning process can engage. He concludes that "by embracing [this kind of] agility ... we can use trial and error to 'feel' our way through complex situations and navigate uncertainty. This is the focus on doing over planning, trialling things and seeing what works, and adapting to an ever-changing situation."

It's a reasonable argument, and in fact we have seen something like it before. Nearly four years ago, I wrote a series of posts** drawing on a talk by Jeff Griffiths about "People Before Process." Over the course of these posts, I talked about the difference between organizations that have a process focus and those that have a competence focus. Of course in real life, any organization needs both. But I concluded that while in many ways leaning into a process focus scales and replicates faster than leaning into a competence focus, it is also more fragile. A competence focus, by contrast, is more resilient when things go wrong. (See especially the long discussion in Part 3.) The reason is precisely the one Pomeroy highlights: in a crisis, you don't have enough time or data to use the conventional tools of the process focus. You have to be nimble and improvise. And the higher the overall competence of your people, the more capably and creatively you can improvise.

In fairness, I have to make one other point. Pomeroy is not arguing that any organization in crisis should throw its rational tools out the window to navigate purely on vibes. If you look at it, the approach he promotes is topologically identical to the PDCA cycle: decide to do something, do it, see what happens, and react. The difference is in the time-scale. Organizations in crisis don't have time for lengthy data collection or analysis, and often may not even know which data are relevant. So the selection, the analysis, and the decision all have to be done by informal methods. But those informal methods themselves rely on the competence, expertise, and intelligence of the executives making the decisions. Nobody's going to suggest leaving the decisions to the toss of a coin or to ChatGPT.

It's a good article—by all means go read it—and it supports the basic point I always try to make here. All of the Quality principles are sound, as principles. But the point is to get results, not to follow the rules. That's pragmatic.     

__________

* This story derives from a poem by Miroslav Holub, recounting a story told by Albert Szent-Györgyi about a scouting troop of Hungarian soldiers in World War One. You can find the poem here. Briefly, the troops got lost in the snow and expected to die. Then one soldier found he was carrying a map of the mountains. After the troop used the map to return to base, they realized it was not a map of the area where they had been! 

** Here are the links: Part 1, Part 2, Part 3.    

       

What is Evidence-based decision making?

Last week I quoted the Michael Toy on the unpredictability of major improvements. In the same blog post that I referenced, he also remarks, "Reality Is a Good Thing." His point, of course, is that you have to base your decisions on actual facts, however unpleasant those facts might look. If you base your decisions on wishful thinking instead, that doesn't make the facts go away! All it means is that you will be unprepared when you run smack into them.

This sounds obvious. Why do we even need to mention it?

The problem is that if we are not careful, it is easy for us to confuse ourselves about what the facts really say. It is always tempting to believe what we hear from our friends, or what we think sounds obvious, or what we read in the papers, or what we get from a well-advertised numerical model.

What we need is evidence.

Sherlock Holmes looking for evidence.

ISO 9000:2015 recommends a number of "possible actions" that an organization might choose to take, to ensure that decisions are based on objective facts—that is, on evidence. Among these actions are such measures as:

• determine, measure and monitor key indicators to demonstrate the organization’s performance;
• make all data needed available to the relevant people;
• ensure that data and information are sufficiently accurate, reliable and secure;
• ensure people are competent to analyse and evaluate data as needed. (2.3.6.4)     

These measures should look familiar, because they are all fundamental requirements of the corresponding management system standard ISO 9001:2015. It is only a small exaggeration, in fact, to argue that the whole point of the ISO 9001 schema for quality management systems is to ensure that organizations have the data they need so that they can make evidence-based decisions about how to improve. Look at that list again:

• The organization has to determine key indicators of its own performance: but these are just the quality objectives that ISO 9001 requires in clause 6.2, along with the other performance monitoring required in clause 9.1.
• The data has to be made available to all the relevant people (as I discussed in this post from 2021 about process management).
• The data has to be accurate, reliable, and secure: but this is why the organization has to control its own documentation (as provided in ISO 9001, clause 7.5).
• People have to be competent to understand and analyze the organization's data: but this is why the organization has to determine its competency requirements and then take steps to make sure they are met. (All these requirements can be found in ISO 9001, clause 7.2.)

And so on.

For that matter, what is an internal audit (ISO 9001, clause 9.2) but a tool for collecting evidence—"objective evidence" is the technical phrase—of how well the organization is fulfilling its compliance and quality obligations? Then this evidence is discussed in Management Review (Ibid., clause 9.3) to feed decisions about the strategic direction and tactical implementation of the quality system. Again, the whole structure of the standard's requirements is designed to provide factual evidence to management to serve as the basis for decisions. We discussed a couple of years ago why this information has to be factual, and why (in consequence) you should never lie to your auditor!

So yes, in a sense the principle is obvious. But it's still important to state it explicitly. Fortunately, if you work with a standard like ISO 9001, its requirements do much of the work for you.

Of course, the importance of weighing evidence and accepting reality stretches far beyond the cloistered world of quality management system standards. One of the best stories I ever heard about facing reality head-on comes from cattle ranching, which is a far cry from most applications of ISO 9000 or ISO 9001. It goes like this:

A story is told of a Tonopah preacher who was delivering a funeral sermon over the casket of an old range veteran long and widely known in Nye County. The garrulous clergyman was waxing unctuously eloquent. "Old Dan is not dead," he declared. "He has just taken the highest trail ...." The sardonic voice of another old puncher sounded from a rear pew of the church, "I got a hundred sez he's dead!"*

Reality is a Good Thing.

__________

* Owen Ulph, The Fiddleback: Lore of the Line Camp (San Francisco: Browntrout Publishers, 1995), pp. 69-70.