Recently, I’ve heard organizations take the position that systems engineering is an unnecessary expense, and that engineering efforts should push directly to mechanical engineering, electrical engineering and software engineering. This philosophy espouses that problems will be corrected during the integration and testing phases of a project or program. It says that systems engineering has not been able to eliminate all errors, and comes at a not-so-insignificant cost. Furthermore, engineering deliverables today include not only paper, but also computer models and other artifacts. Thus, the thinking goes, with all these supplementary materials, systems engineering is not needed.
The perspective that systems engineering is paper is pretty much true—sort of. In another blog post, I wrote that an important part of systems engineering is communication, and that documents, models, diagrams, and spreadsheets communicate ideas, often very technical ideas.
My mentor, and a person who was influential in the founding of Vitech Corporation, was the late Jim Long, in my opinion one of the titans of systems engineering. As a young engineer, Jim said:
The amount of systems engineering required for a given project is fixed. You don’t get to choose how much systems engineering you do. You simply get to choose when you do it (up front, or during integration and testing), how much positive impact it has, and how much it costs.
My interpretation of what Jim was saying is that no matter what we call setting up a program or developing an architecture, defining requirements has to be done. A person with the job of systems engineer (or another engineering title) may do the work, but there is no escaping performing the tasks. Understanding what the system has to do, when it has to be done, and by whom it must be done, has to permeate throughout an organization or group within the organization if there is any hope of project or program success. Organizations have flexibility regarding the “Five W’s,” but can’t escape them. The problem with the “It’ll all come together during integration and test” approach is that the costs grow by significant dollar values the later in the design, production and sustainment phases we discover problems. Jim Long referred to the following graph:
CeBase Software Defect Reduction Top-10 List, Basili and Boehm, January 2001
The take-away I get from this graph is that it’s important to create a strong project/program foundation early in the cycle by performing fundamental systems engineering. There is no way to understand all of the complexities and high fidelity details of a program from its inception. Systems engineering is the only way to determine the details.
As practicing systems engineers, we have to perform stakeholder interviews and conduct a host of analyses and assessments of alternatives in order to optimize a design. Even after that, systems engineers have to eliminate as much interpretation of design details as possible. The way that happens is through engineering, systems engineering, and by providing logical and consistent design details to the next level of engineering designers in the forms of paper documents, CAD models, block diagrams and other communication vehicles.
What happens when detailed design engineers are turned on too early? They are forced to interpret program intentions without adequate requirements. Those engineers do as good a job as possible, but bring their own experiences and discipline-specific foci to the designs; they address the problems they understand. The problem then becomes one of integration of multiple engineering disciplines without the proper interfaces between them. The end result all too often is that emergent requirements are not addressed until hardware is built and software is written. Alas, then, when “it all comes together during integration and test,” it doesn’t all come together, and now the cost to fix a problem is hugely expensive. Furthermore, at this point, the task of addressing the emergent requirements is still systems engineering, just very expensive systems engineering.
The upshot is: Why wouldn’t we eliminate entire classes of errors when they costs only a few dollars to address versus very expensive hardware retooling, material waste, intensive labor efforts on production floor modifications, and software re-writes?
When your executives or program management propose circumventing or short-changing the systems engineering work breakdown as well as the time to perform systems engineering, whip out Jim’s quote and the graph and remind them that systems engineering will occur no matter what they think. The question is simply how much they’re going to pay to do the work.
Happy engineering!
