This post is an article first published in 2006. Re-reading it for the first time in 14 years, I found it as relevant today as it was then, certainly worth a re-post. I hope you enjoy it.
When a consultant walks into a company to help solve a technical problem, it is safe to assume, at the start, that he or she knows less about the product and problem than anyone else on the team. And everyone knows it. Someone is sure to be thinking, “What does this outsider have to offer?” Usually by the time the consultant’s phone rings, the team is frustrated; some want help, others don’t but are told to get it. And someone, often a customer or the boss, is certain to be unhappy. In any event, the first day or so can be a bit tricky.
We at The New Science of Fixing Things bring years of experience solving difficult technical problems. We deal with these difficult situations all the time. We thrive on it. In the early days we mostly worked with people and companies that make planes, trains and automobiles, and their supply chains. Later we expanded into medical devices, consumer electronics and manufacturers of production equipment.
We learned that figuring out how to make the machines you sell to customers run better and longer, and the ones you buy for the factory make good parts for a long time, is a very narrow, specific discipline. It is a profession that is best thought of, from the strategic and tactical level, as a discipline driven by comparative analysis.
If the strategy is to look at differences, we have to remember that the most fundamental question in any field of comparative analysis - to move quickly and efficiently from the strategic to the tactical level is; Compared with what?
Technical problems get solved every day without making much of it. Most problems get solved by one person, working alone without meetings, teams, flip charts or Power Point presentations. Definitely without consultants. Anyone who works for a living solves problems, and many do it all day, every day. Their tactics must be sound. Few ask what are those tactics? Once in a while, a person gets stuck, scratches their head, then asks for help, usually from someone with more experience. Then the two of them figure it out. Given that this is the most often used form of solving problems, and that it usually works, it merits a closer look, up to and including the point where help is called for.
Question 1: What’s Wrong?
When do you ask for help? What do you have to do before you ask? How do you know you have done enough to justify asking for help?
First of all, let’s take a look at the approach used when trying to solve problems at the most basic level. Problem solvers usually ask, What’s wrong? Then they make some sort of comparison to what they think is the ideal, or at least better, state or condition. This approach must have started with cave men after they invented the first tools. When the answer isn’t obvious, they might say, “Can you give me some help? I can’t figure out what is wrong or why this doesn’t work.”
The practice of asking, What is wrong? is the most basic approach to solving problems. In order to get the answer, however, the problem solver has to have a model in his head as to how things are supposed to work, and what are the symptoms associated with specific failure modes. That being said, every person who tries to solve a technical problem understands that some form of comparative analysis seems to help. Typically, the more experience you have, the better the models.
If we fail to get an answer, this is usually down to one single weakness; that is that the model we have in our head for purposes of comparison is weak, either because we do not understand the physics of function or the physics of the failure. This can lead to confusion and the tendency to start guessing, the bane of professional technical problem solving.
Some model of how things are supposed to work needs to be part of any effective approach to solving problems. It is the key to keeping the business strategy in phase with the deployed tactics.
Fixing things is different from inventing. It is about refining rather than redesigning (changing the way the functions are performed) or re-engineering (changing functions being performed). Redesign is a medium-term activity, while reengineering is a much longer-term activity. Within both, a great deal of fixing things type of problem solving takes place. Problem solvers are not trying to invent, but to put things into the order they are intended to be, hopefully the order in which they were at some point. Those trying to refine by inventing their way out of a problem have broken the phase relationship between strategy and tactics.
Question 2: What’s Changed?
When a problem is yet to be solved by the process of asking what’s wrong and comparing it to some better state, some people find it necessary to change the tactical approach rather than find out what is missing from the existing one. This is where the train can really go off the tracks, and cause knowledgeable people to become annoyed. Changing tactics in this situation can be unsettling and is unnecessary. In most cases, this tactical change is not a function of a strategic decision, but of the skill set of the new person placed in charge.
Asking, What has changed? is completely different from asking, What is wrong? By asking, What has changed? There is an implied assumption that some form of statistical stability has been lost and needs to be restored. The world of this type of well-meaning person is based on the assumption that all systems must be stable. They typically also see the world in terms of common causes and special causes. This approach can work, but the model fits only certain circumstances, and it is therefore severely limited. That it works at all could be seen as unfortunate, because today it is usually attempted first, in situations where it will not work. This serves to confuse and frustrate otherwise capable people. It should not be used as a replacement for the physics model, and any well-trained professional statistician will agree. Time is not a causal factor – it is a dimension. The common-cause / special-cause model to s