9 Characteristics of Good Systems Engineering

What makes for good systems engineering? We all know how difficult systems engineering is, but how well are we doing? As I think about maturity levels of organizations, I realize that definitions in the community can be rather heavy on process. I maintain that, although formal processes are best, organizations can be successful even if informal processes are used.

Good systems engineering certainly calls for good processes, methods, and tools that are fit for purpose to the project at hand. But I know from my long experience that good systems engineering always begins with systems engineers who consistently demonstrate a handful of fundamental—and foundational—characteristics. Even in mature organizations, I’ve seen too many projects go haywire due to a deficit in systems engineering leadership.

Too many times, I would join a project, and, working more as a consultant than as a staff engineer, I would need to quickly identify problem areas and determine how to get the project back on track. These problems, I came to realize, could often have been avoided had there been strong systems engineering in place.

Inspired by that recurring experience, I have identified nine characteristics that I believe signal a strong systems engineering operation.

1. The systems engineering team understands the operational use of the system. One of the foremost characteristics of good systems engineering organizations is how well an organization understands and appreciates the operational use of the system under development. Too often, the operational perspective can be dismissed as quaint and unnecessary. Even worse is when engineering is conducted for the sake of engineering, and the perspectives of the end user and other stakeholders are ignored. Good systems engineering organizations have good relationships with operational stakeholders and understand the mission as perceived through the eyes of those stakeholders.

2. The team demonstrates a shared understanding of the system boundary. I’m surprised and mystified by how often I’ve seen misunderstandings and confusions about the boundary of the system under development. When a systems engineering organization clearly identifies the system boundary and socializes that understanding with stakeholders, it can begin to be effective. The system boundary defines what is being developed by the project, and perhaps even more importantly what is not being developed by the project. Only then can they make significant progress. I’ve seen organizations focus too heavily on some favored part of the system while ignoring other responsibilities entirely. Engineering organizations tend to work in those areas where they are most comfortable and often neglect aspects of the system in which they have little or no expertise.

3. The system engineering team communicates effectively. Another sign of good systems engineering comes down to how well the team is communicating. This means how well the lead systems engineer involves other systems engineering team members, but also how well the systems engineering team communicates with engineering leads of major subsystems, subject matter experts, and the broader stakeholder community. In poor practice, systems engineering teams can turn a deaf ear to concerns raised by stakeholders and become isolated in their own thinking. If a team is communicating well, they will make steady progress however slowly. If they are not communicating well, the team churns on ideas and revisits decisions, and, though busy at work, they do not make forward progress.

4. The team has and maintains a set of quality requirements. Oddly enough, requirement quality was only the fourth item that came to mind as I contemplated characteristics of good systems engineering. But, without good communication or understanding of operations, it is unlikely that requirements will be complete, no matter how well they are phrased individually. After all, it is the quality and completeness of the requirement set that is paramount. Even with good communication and understanding of operations, systems engineering organizations can fail at developing clean, clear requirements. Writing requirements is hard; writing the right set of requirements is even harder. A lot of thought and reflection is necessary.

5. Systems engineers understand their system behavior. Understanding behavior is vital and should probably be higher on the list. In fact, I’ve come to learn that understanding behavior is key to writing good requirements. Understanding behavior is more than simply modeling and simulating the operation of a system. It’s about understanding what the system needs to do before considering how it will be implemented. It is also an iterative process with progressive elaboration of a system design. A good understanding of the system behavior will also lead to a good understanding of the data, signals, and resources exchanged within the system and with external entities. Too often, I find teams confuse design and behavior. I’ve seen too many design diagrams described as functional models (e.g. diagrams of component nodes described with nouns, not verbs, and with data exchanges and not linkages). Also, most importantly, good modeling and representation is an art form. Coming up with the right level of granularity for the problem at the right level of the system design can prove difficult. Too often, we as engineers dive into the details of a problem rather than start with that 30,000 foot view of the problem.

6. Systems engineers consistently model their system design. I find that in organizations with poor systems engineering practices, every engineer devises their own system design from their own particular perspective. Where there is a guiding, high-level representation, it is often vague and cartoonish in nature, leaving too much to interpretation. Just as the team must have a shared understanding of the problem and boundary, it must have a shared understanding of the system solution. This is best delivered through a model-based approach informed by the diverse perspectives of the systems engineering team.

7. The systems engineering team considers the entire systems lifecycle. It is easy to forget about verification and validation. It is easy to forget about maintenance. It is easy to forget about retirement and disposal. Systems engineering may not be rocket science, but it is hard work to make sure all of the angles from first concept through retirement are covered. Good systems engineering is far more than designing the operational system.

8. The project team manages risk effectively, clearly coupling the identification and mitigation of risk with the system design. Risk is everywhere, so if an organization is not cognizant or aware of risk, it will run afoul eventually. Too often, risk is given to a “risk manager” who works in isolation and reports in a different management chain than other engineers. To be successful, risk management must be integrated into the thinking of an organization. In fact, it is possible to manage an entire project as a risk management exercise. Why do verification and validation? To mitigate the risk of operational failure. Why do systems engineering? To mitigate risk of failures during integration. When an organization embraces risk management and does not perceive risk as revealing weakness, it will have another powerful tool to help ensure success.

9. They take ownership. Finally, and I believe this may be the most important characteristic of good systems engineering, good systems engineering organizations are willing to take ownership of system development and the business value the system represents. Do they manage just to the interfaces and dust their hands, declaring their job done? Or do they go the extra mile to ensure all external organizations know and understand how interfaces are working?

In sum, characteristics of good systems engineering are not about what process or framework you use. Processes, methods, tools, and frameworks are wonderful enablers and amplifiers, but not the fundamental drivers. Good systems engineering is characterized more by an understanding of the operational environment, an understanding of the system under development, and by communicating and working effectively as a team with a broader, through-life perspective. More than anything else, embracing these nine characteristics will help drive systematic and systemic success for your systems engineering organization.