Systems engineering techniques themselves contribute to disaster because they all are paper techniques and there are only two instead of N dimensions available. What we end up displaying are linear sequential measures of system progress. The PERT diagram and the milestone chart are excellent examples. These both essentially assume that the progress of development and design consists of doing step A, then step B, then step C, etc.
Anyone who has ever done development, or a design (as opposed to setting up a management system for doing so) is well aware of the fact that the real world proceeds by a kind of feedback iterative process that looks more like a helix than like a line. That is to say, you do A, then B, then C, then you look at C and go back and change part of A again, and that causes you to fiddle with B and perhaps bring in a B prime that you bounce against C, and then go back to A and then jump to D, so that there has to be a continual adjustment, going back and forth so that the system is adjusted to itself and to its end objectives as it changes and as the design or development proceeds.
Because it is difficult to predict this process or to diagram it, or to predict its costs very precisely without using competent engineers, the system engineering procedures simply ignore the iterative, feedback nature of the real world because the process has been degraded to clerical reporting.
To a large extent this tends to constrain project managers away from doing the work in the real way, towards doing it in a way that fits with their management tools. This is clearly nonsense.
That was Robert A. Frosch, former Assistant Secretary of the Navy for Research and Development, in “Competition in Defense Procurement,” Hearing before the subcommittee on antitrust and monopoly, July 14, 1969.
This presumption that iterative feedback in development is wasteful or negligent is perhaps what’s at the very heart of today’s defense acquisition malady. All uncertainty in military developments is intended to be resolved in the S&T/prototyping phase in order to provide a strict baseline of cost, schedule, and capabilities that the program will be measured against for the remainder of its lifecycle. Yet clearly if any progress in military capabilities is to be achieved at all, these pre-development controls are as arrogant as they are destructive.
The interesting thing, in my mind, is that even the prototyping phase is expected to proceed in a linear, anticipated way. If a successful prototype is to be transitioned in FY 2022 into a full-scale development, the service would have to start lining up that program’s funding through the PPBE back in FY 2019 in most cases. But in order to be ready to justify funding in FY 2019 for receipt in FY 2022, the service requires completed documentation about the total program lifecycle cost, schedule, and capabilities.
By the time the prototype is in it’s early phases, it will need to articulate exactly what information will be learned and what that will enable them to do in order to avoid the dreaded “valley of death.” Consequently, the “unplanned” innovations are least likely to transition in DoD, while the “planned” innovations that are unlikely to provide great benefit are able to transition.
There is nothing inherently paper or 2-dimensional about systems engineering. PERT and milestone charts are, strictly speaking, project management tools and techniques, not systems engineering. These are minor nits, clearly. However, I believe Mr. Frosch’s challenges/examples are misguided. His overall point about iterative development vice predictive has validity. However, the challenge of systems engineering is inappropriate, as I would suggest what he describes would actually be the iterative application of systems engineering practices and principles.