For any issue of meaningful complexity where multiple specialists must come together to develop a solution, systems engineers sit at the technical heart of the solution. We strive to fully understand the problem space, fully understand the bounds associated with the possible implementation technologies, and ultimately expand the trade space to find the right solution. Systems engineers lead the architecture and design, coordinating the technical dimensions with a diverse set of subject matter experts. While systems engineers often focus on the technical dimension and the impact we have on the solution, the communication dimension is just as important, if not much more so. Systems engineers sit at the hub of technical communication for a complex project. We facilitate the problem understanding, elicit concerns, negotiate trade-offs, and broadly serve as the translators that bind the team together. In doing so, our ability to communicate across the interested parties – from stakeholders, customers, and users to managers, systems engineers, and subject matter experts – directly impacts the quality of the solution we deliver.
As systems engineering navigates its way to a model-centric practice, we often focus on the analytical value and the rigor that this transformation represents. The change from low-fidelity to high-fidelity communication is perhaps even more important. It’s not guaranteed that this shift enhances project communication. In fact, high-fidelity mechanisms mismatched to the audience reduces communication effectiveness and inhibits the overall project.
Communication is not about the sender. It’s about the receiver. Effective communication relies upon first packaging information of interest to the receiver and delivering it in a format the receiver can understand. Once that is complete, the communication channel is open, and the sender can transmit additional information of interest or concern. When we think of this in a document-centric paradigm, communication is somewhat simplified. Agree upon the template to use, populate the template with information about the problem / solution of interest, and rely upon the fact that all involved can read the document. It’s a low-fidelity approach fraught with difficulties (information overload, information navigation, and ambiguity to name just a few), but the approach itself spans audiences.
As we communicate in the age of models, we must take a systems perspective. It’s not necessary to sacrifice our communication needs as systems engineers, but it’s foolhardy to believe that we can be effective if we expect those around us to adopt mechanisms tailored to our perspectives and needs. We must address communication across the project team rather than optimizing communication and representations for our personal needs. Otherwise, we cannot effectively engage others, elicit their insights, expose our ideas, and harness the collective knowledge of the team to deliver the right solution. The path to quality and the path to project success lies not in optimizing specialist communication but in optimizing the full system of communication.
Done well, model-based approaches separate model from representation. We can look at the same model from multiple viewpoints, representing the information of interest for that viewpoint in a format appropriate for the specific audience (the concept of fit for purpose views). That may mean activity diagrams and internal block diagrams for systems engineers, dashboards for managers, “architoons” (technical cartoons) for first-level exposure to the problem and the solution, and even traditional specifications to cross the contractual boundary. Putting the information of interest in the format of the receiver enables effective communication, allowing the receiver to bring his or her full intellect and value to the problem at hand. It makes the job harder for the systems engineer who must be part translator and part chameleon, able to work effectively in the language and representation of the audience. But this is our responsibility, one of the classic roles we play as systems engineers and one we cannot shirk.
So when communicating in a model-based age, what do you do? Look to your stakeholders to understand their needs (both in content and notation). Treat project communication as a system itself and deliberately architect it. If you are fortunate enough to have an environment that generates diverse views of your model, leverage it and play the chameleon engaging each audience in their native language. If not, constrain the representations that you use – it’s your responsibility to ensure coherence and consistency across whatever diagrams, tables, documents, and artifacts you choose – but choose those representations based upon the need of the project team rather than optimizing for yourself.
There is a direct correlation between communication, the ability to effectively engage the project team, and our ability to match a solution to the problem. It’s up to us whether we recognize this and optimize for project success or selfishly suboptimize for ourselves.
