In business, assumptions replace unknown information. Assumptions are based on past observations. Usually assumptions place bounds on the outside limits of failure.

In developing a counter measure launcher for use in a submarine, our engineers had developed a sophisticated mechanical launcher. The mechanical launcher created no gas or exhaust bubbles, created very little noise, required no chemical motors, explosions, or the like, and was designed to launch a small counter measure device out through a penetration in the hull of a submarine into the surrounding open sea. I came into the project late, assigned by my manager to assist in developing a computer model for performance of the counter measure launcher.

By the time I was involved, prototypes had been constructed from initial designs, and simulated launches had been tested. However, no computerized analysis or modeling had been performed. Whatever analysis occurred was done one equation at a time, based on a set of assumptions.

Working with basic principles, I developed a system of equations I believed represented the physical events controlling the launcher. The equations reflected the behavior of each key piece. I used the manufacturing drawings to determine the particular shapes, sizes, weights, forces and so forth of all the components acting in the launcher.

When I began exercising the model, running the computer to calculate and chart out the simulated launch of a counter measure by this launching device, I was surprised and disappointed. According to my computer, the miniature torpedo projectile initially accelerated, then speed leveled off as acceleration tapered off. After power to the projectile ended, according to the computer, the projectile reversed direction. It was sucked back into the tube inside the submarine. Of course the tube would be sealed against any water going back into the submarine, but the projectile was sucked back through the penetration, coming to rest inside the tube from which it had been launched. It went nowhere !

I scratched my head and went back through all my code with a fine toothed comb. I went through all of my assumptions. I went through all of my equations. I went through all of my data. I could not match the performance that the prototype had achieved in the test.

The testing data indicated that the projectile should have come up to speed, launched out of the tube and proceeded into the open water. My computer model predicted that the counter measure immediately returned back into the launch tube as soon as the power source was terminated. I could find no errors. I came up with a theory that explained by model, but the data were otherwise. What was I missing?

I interviewed engineers who worked on the prototype. To my surprise and consternation, one said that the velocity and position shown by my computer model were actually the same behavior the launcher system originally exhibited during the initial testing. He said that before the “stand pipe” was connected, that is exactly how the device behaved.

When I inquired about the stand pipe he said that because the counter measure device kept being sucked back into launch tube, the engineers connected a stand pipe to the back of the launcher tube, opposite the countermeasure exit. The stand pipe let the launcher draw in ambient air into the back of the launcher tube, replacing water pushed out with the projectile (counter measure) device.

I pointed out that a submarine at strategic depths was not capable of opening a stand pipe through the hull to draw in atmospheric air to backfill behind the launched counter measure module. Once the tube was sealed, no additional water or air was available to draw in behind the counter measure.

What my model had demonstrated was the absolute reality. The mechanical launch mechanism was producing so much force behind the counter measure module that it actually forced the counter measure projectile out the tube like a piston. The launcher was creating a vacuum bubble behind the counter measure due to the inability of water to pass around the nose of the projectile to refill or re-flood the tube behind it as it moved out during launch. Therefore, the vacuum bubble, once it was no longer being driven by the force of the launcher, immediately collapsed back into itself. As the bubble collapsed, the shrinking volume behind it sucked the projectile like a piston back into the tube.

The engineers who added the stand pipe had never considered that they had added a physical component to the system that would be impossible to provide in the actual strategic submarine. They had physically modeled a scenario that could never be reality.

In dealing with factors that must be considered, remember that they may affect our designs positively or negatively. Factors are realities. If we believe they are obstacles, we must find a way to remove them or avoid them. If we believe they are opportunities or benefits, we want to find a way to cause them to benefit us.

Factors include issues, but the word “issues” tends to be thought of as a negative. Issues are often those circumstances we would like to change, and must somehow resolve. However, “factors” is a broader class. Factors will include all the realities (opportunities and obstacles) of all types along our path that will eventually be navigated. That path through them becomes our strategy. Failing to accurately perceive and deal with all significant factors will lead to a strategy that is impossible of performance.


Comments

You must be logged in to post a comment.