We recently halted work on a new engine design because the program team wasn't able to agree upon the best course of action to complete the engineering development. We had prepared power and torque curves, fuel consumption charts, finite element analyses, transient power generation timelines, and all of the other normal analyses. The problem was that we'd encountered the dreaded condition, Paralysis by Analysis.
Whereas normal programs continue to move forward, as planned by their master program schedule, we had reached a point where executive level decisions were being held up pending additional but worthless analytical data. The entire project was paralyzed until a sufficient quantity of ever-expanding analyses could be prepared. It didn't matter that the engine design was still being prepared or that the detail design for production and manufacturing was scheduled to be prepared 2 years down the line-our team was demanding this information now or they would claim that the project contained too much risk to move forward.
I attribute this condition to the computer and its ability to generate reams of paper at the touch of a button. Instead of relying upon the engineer to put pencil on paper and make an informed, intelligent decision based on sound engineering analysis, we're now required to prepare no fewer than 15 analyses of every conceivable condition prior to program management making the engineer's decision for him. Some of the more ludicrous analyses now required include:
-
Performance analysis at 4,500 meter high altitude, 120F temperature, in steady rain
-
Performance analysis at 150 feet altitude, minus 45F temperature with light rain falling
-
Performance analysis of stationary vehicle rotating/pivoting at 7 rpm for 15 minute duration
It doesn't seem to matter that these conditions and scenarios do not exist in any real-world situations, these are vehicle specification requirements and as such they must be evaluated and proven capable through analysis.
Compare, for example, the space program in the 1960s. They managed to send a man into space, put him on the moon and bring him back, and only had the computing capability that now resides inside a tiny, hand-held device. If we were to try another lunar mission, the program schedule would take well over 15 years. The computer analyses alone would generate enough paper to enable the astronauts to walk to the moon and back.
A more recent project I was involved with was an off-road vehicle; I'll call it the Gator so as not to offend too many people still involved on the program. Instead of using the customer's vehicle specifications, the prime contractor decided to prepare his own unique set of vehicle requirements. This new specification contained a requirement for every conceivable operation and condition that might ever be encountered. The worst part was that they demanded a performance analysis for each one of these operating conditions-they even generated a list of 42 different criteria for reverse speed operations, and each one required a separate engineering analysis (for reference, the customer specification contained only 3 reverse speed requirements). One of the 42 conditions requiring analysis was for the vehicle to be capable of backing up a 25 degree slope at 5.5 miles per hour, in mud, while towing a 50 ton vehicle out of a river on a minus 45 degree day (it would have been too easy for them to simply specify the required output torque and speed at the drive wheels). Have you ever checked to see if your new car can do this before you buy one at the local auto shop?
In order to facilitate future programs by constraining the number of nonsense analyses, I've been seeking help to prepare a management guidebook. By providing program management and systems engineering people with an equation to identify the proper number of analyses for any given program, we may be able to eliminate these unnecessary and unwarranted product analyses. So far, I've only been able to define the existing parameters in the following equation for defining the number of analyses that must be completed prior to releasing any product for use by the typical consumer. The equation goes like this:
Na = 1/2 * (D / A) - (d**2 + 1/2*P) - St
Where Na = number of analyses, D = number of drawings in the project, A = number of subassemblies, d = days remaining on the program, P = number of people who prepare analyses, and St = number of supervisors with technical degrees available to review the analyses.
As this equation shows, the number of analyses required drops quite rapidly as the number of days remaining on the project dwindle. The savvy engineer can wisely eliminate any unnecessary analyses by scheduling drawing release near the end of each project.
| Head Work | |
|---|---|
| The center of the geometric figure described by 16x2 - 160x + 9y2 + 36y + 292 = 0 is at the point: | |
| See answer below. Adapted from the Fundamentals of Engineering Examination, Eugene L. Boronow, Prentice Hall Press, 1986. |
|
| A | (-5, 2) |
| B | (3, 4) |
| C | (4, 3) |
| D | (5, -2) |
| E | (25, 4) |
Answer: D