We can combine the previously discussed practices to devise and execute remarkably complicated projects. However, those practices share an important characteristic that, when articulated, suggests a process gap: they involve satisfaction of needs and intentions that are immediately1 routine for our “in house” Engineering staff. The short-coming, of course, is that sometimes we need some intermediate work done for which mere experience is insufficient.
In those situations, we’ll often find that an abstract technical representation of the problem2 results in solutions that are more efficient (either technically or economically). Even more important than efficiency, an abstract representation mitigates the possibility of subsequent Confirmation Bias3 when we’re deciding whether the overall design is adequate. It explicitly separates the problem statement (of need and intent) from definition of the solution (the design).
Technical characteristics are best-written when they address well-defined topics that can be unambiguously evaluated with relatively few inter-dependencies. My preferred mechanism for that type of work is the sequence of Topical Analysis and Topical Parameterization. I strongly recommend familiarity with those concepts before going further in this material. Although tedious to execute, they’re not difficult to understand.
These abstract practices occur in three basic motifs4:
1) We have needs and intentions for which our staff does not have a good technical understanding, lacks applicable experience, or is not cost-effective. These are situations in which either design synthesis or suitability assessment cannot be completed without some outside help. These circumstances require Development of an Envelope Drawing in order to “export” the problem to some other developing organization.
2) There are significant opportunities to consolidate disparate sets of needs and intentions. These are usually attempts improve the cost effectiveness of any or all of the Development, Production, or in-service Support processes by reducing the number of distinct designs that must be dealt with. This situation calls for Commonality Assessment.
3) We need (or want) to upgrade or modernize to parts that are already in service, e.g., to improve characteristics or cost-effectiveness or adapt to obsolescence. Such situations require Redevelopment. This process is oft-times the most profitable part of the business, so deserves close attention.
←Back to Part II: Intermediate Discussion
Footnotes- That is, without any intermediate work to be done.[↩]
- Which might, or might not, be “requirements”.[↩]
- A type of cognitive bias.[↩]
- Which are covered separately for the sake of focus.[↩]