I believe that the fundamental difficulty is that we have all gotten so entranced with the technique that we think entirely in terms of procedures, systems, milestone charts, PERT diagrams, reliability systems, configuration management, maintainability groups, and the other minor paper tools of the “Systems Engineer” and manager. We have forgotten that someone, some person, must be in control and must exercise his management, his knowledge, and his understanding to create a system. As a result, we have developments that follow all of the rules, but merely fail.
I can describe the spirit of what I had in mind best by thinking of a music student who writes a concerto by consulting a check list of the characteristics of the concerto form, being careful to see that all of the canons of the form are observed, but having no flair for the subject; as opposed to some one who just knows roughly what a concerto is like, but has a real feeling for music. The results become obvious upon hearing them. The prescription of technique cannot be a substitute for talent and capability, but that is precisely how we have tried to use technique.
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. Here’s more from Frosch on what systems engineers wrongly assume.
I get the idea that DoD needs paper processes to make sure systems reliably get fielded without a high-skilled workforce, but ultimately a better path seems to be focusing on that workforce instead of the weapon system and trust that their talent (with proper incentive feedback loops) can create tomorrow’s wonders rather than slightly improved versions of what exists today.
As a former industrial engineer, it really gripes me that “systems engineering” has come to be interpreted as just paper processes and checklists. Real systems engineering isn’t a different thing from “talent and capability” — it’s the way that talent and capability get applied to manage risk and produce results. But it’s impossible to force people to do real systems engineering — there is no directive or regulation one might craft that can’t be converted into an unproductive box-checking exercise by an unwilling workforce. (I will freely admit that INCOSE isn’t helping to correct this misunderstanding of what SE should be. Their institutional incentives favor volume over quality.)