The INCOSE Role of Systems Engineers
During the past thirty years, managers have found it advantageous, on projects of moderate size and above, to designate individuals whose primary responsibilities are systems oriented. These people are the “glue” that binds all the sometimes diverse system elements together. They provide the decentralized leadership and paths for the up/down communications that must occur in 1) flowing “down” the system level and project perspectives and 2) flowing “up” the component and subsystem perspectives of problems and difficulties with implementing designs and the associated necessities for changes.
Systems Engineering represents the program manager in managing the program technical effort. Systems Engineering has responsibility for the design and integrity of the system. This Systems Engineering element reports to the program manager as do other design / development elements. The program manager thus maintains direct, two-way communications with all elements of his team (not relayed through Systems Engineering). Systems engineers handle the myriad of daily activities of coordination between system elements.
Each program usually has a Chief Engineer or Deputy Program Manager – Technical, who is responsible for directing the program technical effort. This person may also be the Systems Engineering manager and/or leader of the Systems Engineering team.
The Systems Engineering team designates various individuals to maintain tight liaison with all technical areas of the program, including: analysis, design, manufacturing, and test. These Systems Engineers must be experienced enough to be “hands-on” participants in the process – not just observers/messengers (whom other engineers would resent).
The Systems Engineer’s job includes defining, clarifying, and documenting requirements; performing (or insuring his team performs) the necessary parametric analysis and tradeoffs; recognizing when interface impacts might occur and taking early action to avoid problems. The Systems Engineer should have a good overall perspective of the system to help interpret and explain motivations for requirements to his team members and thereby gain their acceptance and commitment to objectives.
A Systems Engineer may need to explain (and justify) to a subsystem team why its necessary to cut excess “fat” from a concept – in the form of weight, power usage, envelope, operating time, or cost-to-produce. While another may encourage his subsystem team to pursue a more-risky (or less risky) development approach which promises overall system payoffs. Yet another Systems Engineer may help explain to management why his team requires more resources.
Basically, the Systems Engineer, at any stage of a project cycle, works with and between his team(s) and the other teams at equal, lower, and higher system levels to ensure a smooth technical program, with no surprises or adverse consequences.
During project development phases, it has been found that expenditures of twenty to thirty percent of the total engineering budget for Systems Engineering activities are worthwhile. The higher figure is appropriate if Systems Engineering is also responsible for the internal subsystem integration (as opposed to a development engineering integration team).
If no formal Systems Engineering effort is included, projects run the risk of fifty to one hundred percent development cost overruns to fix major downstream integration problems (costs can be very high due to the necessity of keeping a major portion of the project team around until all problems are solved).
Systems Engineers are still essential in the integrated product and process development team environment (for the same aforementioned reasons).