#1 Questions are more important than their answers.
#2 Plan backwards.
#3 Fail quickly.
#4 Seek out & encourage dissent.
#1 Questions are more important than their answers
"A problem well put is half-solved", wrote philosopher and psychologist John Dewey. As Dewey would explain, a problem statement --- the question --- gives direction to research and determines what is relevant and irrelevant to providing an answer. How a question is phrased will determine how quickly an answer is found and if one can be found at all. It will also determine if the answer returned is useful.
The importance of phrasing a question is illustrated by an apocryphal story about Henry Ford. Ford, the creator of the automobile industry, is alleged to have once said, "If I had asked people what they wanted in transportation, they would have said faster horses." If Ford really said this, he would have failed to realize the problem would have been with the question, not the answer.
Sometimes a question needs to be turned on its head before a useful answer can be found. During World War II, the British code-breakers at Bletchley Park wrestled with the question, "How can we quickly determine the correct cipher to decode today's German communications?" Alan Turing finally solved the problem by rephrasing the question as "How can we quickly determine an incorrect cipher... ?" By finding a way to discard impossible ciphers as quickly as possible, Turing's solution (the first electronic computer) could quickly narrow down all possible ciphers to just a few worth studying in depth. The additional research time gained through Turing's computer allowed the correct cipher to be identified soon enough for each day's messages to be decoded that same day. Had Turing and others stubbornly researched the obvious question of "How can we quickly determine the correct cipher...?", they might never have found an answer as useful as the one to Turing's rephrased question.
I cannot leave this topic without noting author Douglas Adams' excellent illustration of this principle. In his humorous science fiction novel The Hitchhiker's Guide to the Galaxy, we read that the answer to "the ultimate question of life, the universe, and everything" is 42. Knowing the answer was useless because no one really understood the question.
For examples of my use of this principle, see my Problem Solving case studies.
#2 Plan backwards
I learned this during my ROTC training: when planning, begin with the objective in mind (the future state) and work backwards to the current state. Only then can I be confident I can reach the objective. I have worked on several projects where managers have planned in chronological order only to discover that the desired state could not be achieved because it did not guide preceding actions. Prior planning prevents problems, but only when that planning is done backwards.
Backward planning does not necessarily mean waterfall development methodology. It is not only compatible with Agile, but is a safeguard against Agile’s iterative process leading to “mission creep.”
I use this principle in all my projects --- research, programming, and quality improvement. The most detailed example can be found in the PDF case study of an intelligence production system I created for Toppan Merrill (starting on page 3).
#3 Fail quickly
This seems outright defeatist at first, but it acknowledges that any plan can fail — and the sooner you know it is failing, the better. That is the point of this principle, one that is the basis of safety testing. While the use of pilot projects and test groups would seem to employ this principle, they do not unless failure has been defined in a measurable way. Otherwise, any negative results can be consciously or unconsciously dismissed as something less than failure.
This bias also arises when a project is measured in terms of what constitutes success rather than in terms of what would constitute failure. If a pilot or an entire project falls short of a definition of success, it is easy to say "the project was mostly successful, so we'll call it a success". Defining failure and measuring for it keeps everyone honest. It also encourages root cause analysis and improvements.
This principle of failing quickly was the key to Alan Turing solving the German cipher problem (see Principle #1). Also, if you studied statistics, you will recognize "defining failure" as the null hypothesis of the hypothesis testing method.
For an example of how I used this principle, see this case study.
#4 Seek out & encourage dissent.
Key to being able to define failure is having someone who can imagine it. Someone with a dissenting opinion is often the best source. Dissent can also reveal gaps in one's understanding and objectives. I have found dissenting opinions, even outright resentment, as helpful in my process improvement projects.
The absence of dissent and an environment that discourages it produces what in NASA is called “go fever.” It has been found to be the underlying cause of the deadly disasters of the Apollo 1, Challenger, and Columbia missions.
If there is no dissenting opinion, I will play devil’s advocate.
For an example of how I used this principle, see this case study.
Copyright Will Beauchemin 2024