“Who are you going to believe?” Groucho Marx famously asked, “Me or your own eyes?”
The Groucho Question came to mind as I read an intriguing, if conspiracy-oriented opinion piece by James Schmitz Jr., a senior economist at the Federal Reserve Bank of Minneapolis. Schmitz’s contention is that home-building is trapped in 19th century technologies and methods that have prevented productivity increases in that sector for a matter of decades. (“Homebuilding must modernize,” StarTribune, 5/2/2021).
His solution: “Rather than manufacturing homes in factories, they are constructed outside, with a centuries-old technology sometimes called the “stick-built” method.”
He’s the “Me” part of the Groucho-ism. As one who consults on and writes about matters of organizational effectiveness, I found his contention appealing.
As the owners of a downtown condominium who, by HOA mandate had been required to have our balcony door replaced … twice; the first replacement having been problematic … my wife and I recently had the opportunity to see Schmitz’s theory applied in actual reality (and isn’t it strange to live in an era where I have to specify which reality I’m writing about).
We were Groucho’s “… or your own eyes,” as we watched two clearly expert individuals remove the offending door panels and replace them with (presumably) more serviceable ones. To get the job done they had to deal with perhaps six situations that required significant expertise and ingenuity.
It occurred to me that while the door panels had been manufactured in a factory – they were the result of a well-defined process – their installation was clearly and unavoidably a practice.
Why this matters to you: Here in KJR reality we’ve frequently discussed the difference between processes and practices; processes being how work gets done in factories, with their repeatable, predictable steps; practices being how work gets done in hospitals and law offices, where no two cases are ever exactly alike and work must be adapted to each specific situation.
We consultants frequently advise clients to turn case-by-case kinds of work into metaphorical factories so they can perfect their techniques and get results that are more repeatable and predictable. I’ve been guilty of this myself, although I hope with enough qualifiers that I haven’t overpromised the ease and simplicity of the result.
The differences between process and practice aren’t “mere” semantics, not that there’s anything truly mere about semantics in the first place. It’s also fair to say that to the extent it’s possible to redefine how work gets done so it’s less of a craft or practice and more of a manufacturing-like process, defect rates and incremental costs will, in most cases, decrease.
It’s just easier said than done. To turn any craft or process into a factory-like process, a key aspect of the transformation is to view each step in the work as responsible for reducing the variability or, looking through the other end of the telescope, increasing the predictability of what those responsible for the next step in the work will face.
If you’re building a house that means getting started by (based on my extraordinarily limited understanding of the trade) clearing and grading the lot, laying the foundation, and fixing variations in ground compressibility to avoid surprises when pouring the slab and laying cinder block.
When building an application it means (among other things) clearly defining the architecture and coding standards, writing consistent user stories, and determining interdependencies to avoid surprises when, depending on the application architecture, coding each module, service, microservice, or what-have you.
Bob’s last word: When we envision a factory we envision a conveyor belt that carries identical items to each step in the work.
When we envision most of what IT does for a living … or when we envision building a house … we don’t envision anything remotely like that.
Bob’s sales pitch: Looking for help improving the practice of improving business practices and processes? Here’s where to contact me so we can start a conversation.
I think that might be the difference between biology (medicine) and “hard” science like physics. The expectation of reproducible results. In biology, we can’t always guarantee things will happen. Best we can get is vaccines with 90% effectiveness. Even poisons are measured statistically with LD50–Lethal Dose for half the participants.
So there’s still that fractal boundary between process and practice. If we can get the same outcome 90% of the time now instead of 65% of the time by doing whatever the consultant sees in the tea leaves, you might be able to factory-ize some significant portion of your work and even pre-recognize the other 10% that needs practice.
Quite correct, and in fact when I’m involved in process design I usually recommend including a “process bypass process” – a process to follow for the exceptions for which the main process won’t deliver the desired results: https://issurvivor.com/2005/09/19/bypassing-process/ .
My father was a traditional architect. I am currently an infrastructure architect. Parallels between the two fields abound, but this week’s column couldn’t help but remind me of one particular case where the design and construction of a structure served as a metaphor for systems architecture. Back in the early 2000’s our company commissioned the building of a new data center. A design feature of the new building was a curved, downhill breezeway with a flowing, tilting roof paralleling it’s traverse of the terrain between our offices and the datacenter. The roof was to be constructed of tightly coupled aluminum panels, and the architect specified that these panels be precision laser cut at the manufacturer to specifications produced by the CAD/CAM application used for the design, ready to simply drop into the framing. It all sounded very 21st century. The only problem was that when the panels arrived, none of them fit correctly. Why? The CAD/CAM system used had based the panel cutting on it’s own, pre-construction, ‘perfect world’ version of the sloping curved hillside where the roof was to be assembled. Unfortunately, the real world backhoe and shovel based grading at the site was not nearly as precise as the tolerances specified for fitting those panels. As a result of the oversight, each panel had to be individually hand fitted on site, a process that required months of additional work, and significant cost overruns. As I watched the process play out daily over those months, I was constantly reminded of my late father’s concerns that too many young architects were not being taught that part of their job was to serve as a liaison between the conceptual and the real worlds. Always account for the ‘human’ factor.
What a great story and perfect illustration. It reminded me of the old joke about the farmer who wanted to improve hen-house productivity. The consultant he brought in to advise him told him it would be simple. How to go about it? Easy, the consultant explained. “First, assume a spherical chicken.”
To me your story illustrates the difficulty of integrating factory-built with stick-built, a difficulty that should be no surprise to anyone in IT.
All stick-built software: Slow, expensive, but integration is a breeze!
All factory-built software: Quick, inexpensive, but your processes have to conform to the software’s expectations.
Mixing custom and off-the-shelf software: Wow, those integrations are going to get you….