“Experience by itself teaches nothing… Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning.”
–W. Edwards Deming, The New Economics for Industry, Government, Education – 2nd Edition
The field of psychology, it seems, shares an issue with the field of operations management.
Wilson and Golonka, psychologists who blog on Notes From Two Scientific Psychologists lament about the lack of a unifying theory in their field in Theory, and Why Its Time Psychology Got One.
This is fairly heavy reading since it is likely from outside your field, but the core message is here (paragraph breaks added for readability):
Theory in Science
As I try to teach my students, the role of theory in science is to provide structure to your data. A good theory rules explanations in and out, and if it rules out the wrong explanation that will become clear over time as you pursue your theory guided research.
Good science means a) restricting your explanatory mechanisms to include things your theory allows, and b) keeping an eye on how well that’s working out for you, while c) allowing yourself to rest on your well supported theory to resist breaking the rules as long as you can.
As Deming points out in the quote at the top of this post, having a theory – a solid statement of what you believe is true is a prerequisite for learning to take place. Without that theory, events and information simply get filed away as “interesting.”
With a theory, each is compared against the prevailing thought and forces us to reflect on our understanding.
Sure, we run into confirmation bias (where we unconsciously exclude things that contradict our beliefs) and other logical flaws, but honestly – if scientific thinking were easy, we wouldn’t have to discuss it.
This is pertinent to us at a couple of levels.
At the macro-level we have the proliferation of “solutions” out there for management. We all talk about “flavors of the month” and “alphabet soup” as we see companies cycle through the various structures for “world class performance.”
Wilson and Golonka’s message, and our problem, is that in attempting to embrace everything, we embrace nothing.
Of course part of the problem is that book authors and management consultants are not, by and large, researchers who are interested in unifying the theory. Quite the contrary. They are interested in differentiation. This causes problems for people who see these various “solutions” as competing somehow. (In reality, they are mostly re-packaging of subsets of the same overall stuff.)
OK, we can’t do much about that in the larger sense, but within your company, you can.
I have yet to encounter a situation that is outside of my baseline theory of “what TPS is.”
As I said in a talk I gave last week, the only faith-based position I am asking you to embrace is that if your results seem incompatible with TPS, look at your understanding and deployment before rejecting it as unworkable.
While we wait for the MBA programs and influential institutions in our field to catch up, we can continue to identify in forums like this one which authors and researchers we think are largely congruent with one another and some kind of common baseline.
The other area where this message is applicable is in our daily approach to process design and problem solving.
Almost all of the “tools of lean” (and many techniques not especially associated with TPS) are really designed to develop and test a working theory of how the process should be working.
Takt time is a great example, though far from the only one.
I set up a process to operate at a certain speed. I say, in effect, “if the process has no unexpected problems, this is how long it should take.”
That is a theory.
I test the theory each and every time I run the process.
When (not if) something unexpected happens – when the team member can’t meet the standard work for some reason, then we have data that is not congruent with our baseline theory.
Now we can get into understanding why – what happened that we didn’t count on. Likely (in this example) something uncontrolled tripped him up. In experimental terms, we didn’t have the baseline conditions.
In our process terms, we now have a problem to solve – how do we keep that issue from coming up again, so that our team member can do the work in the time expected?
As we cycle through this thinking again and again, each iteration either cleans up some issue in the operation (which is continuous improvement), or we realize that we should have included this factor in the original plan (we modify the working theory).
Either way, our knowledge of the process is improved.
In reality, these two cases – micro and macro – point to the same thing. We need the macro (the theory of management) to reflect that we need to incorporate this thinking into the way we manage everything.
3 Replies to “Theory Tests Reality, Reality Tests Theory”
I love the way you think. Almost perfect!
I want to call your post perfect, but I added the “almost” because if I called it perfect you would scold me for holding the theory that you could not improve your writing.
Thank you for your interesting post, Mark.
It made me wonder whether there is a jump between what scholars call “theory” and what you are thinking of. The way I see it, your assertion “if the process has no unexpected problems, this is how long it should take.” is not a theory; it is an assumption (a very convincing one indeed). You might need several assumptions to build a theory on operational excellence or on any other topic.
The point is that most of what I have read on lean thinking is full of assumptions, but very few try to gather all those assumptions into one single theoretical framework. Maybe this is the reason why the field of operational excellence has mainly developed upon heuristics of the kind “trial-error”, with a significant estochastic component involved. Maybe the lack of “a theory”, as in psychology, is what produces such a large amount of airport literature in the field, but much less rigorous (and therefore generalizable) work.
Xosé H. Vázquez
I don’t think there is much difference between an underlying assumption and a theory or hypothesis as long as you are testing your experience against it.
In the takt time example, I am setting up the process assuming I have handled all of the known issues.
If I am correct, then the process will hit the predicted cycle time.
When I say “unexpected problems” I refer to the things I didn’t know about when I set up the process.
These things are, then, beyond my current knowledge, and are therefore, things I must seek to understand about my “experimental conditions” and the actual cycle of work.