Someone told me once that all problems in engineering systems are communications problems. Their assertion reminds me of one of my High School English teachers, who had a sign which read: Eschew Obfuscation. For those who don't get the irony immediately, this can be translated as 'avoid confusing your audience'.

Communications channels come in many different flavors, and each has benefits and challenges. However, one of the things common to nearly all of them is that they are imperfect. Messages can be lost or altered, and thus may have varying levels of fidelity with respect to what was originally transmitted. The channels themselves have inherent delays, and thus may deliver messages that are difficult to reconcile with each other at different times. Different communications channels also vary in their tolerance to noise. For example, when presenting concepts to a large audience, oral presentations, visual graphics, and written narratives can each be quite effective for a particular purpose, and yet be inadequate in others.

You may see everything as sunny and rosy, whereas from your audience's entrenched position (often juggling many factors you don't even know about), it's raining cats and dogs. If you do not actively close this 'communications loop' with those you are communicating with, to assure that your intended meanings were understood and accepted, you may be increasing your audience's confusion more than their support of your ideas. This can frustrate everyone, especially if your messages build on each other, when the situation you are describing is novel or complicated from your audience's perspective, or when the approach you are advocating departs significantly from traditional practices of your audience, or is controversial.

The communications researcher Osmo A. Wiio published some rules of thumb about communications a number of years ago, while he was a member of the Finnish Parliment. Osmo's rules include (and elaborate on) the following points:

• The probability of communications success is inversely proportional to the square of the number of paths traveled between the transmitters and receivers.

• Communications is more likely to fail than it is to succeed.

• The more we communicate, the less likely it will be for the communications to succeed.

• If a message can be interpreted in several ways, it will likely be interpreted in a manner that impacts the underlying value of the message in the most detrimental way possible

• Perceptions matter as much or more than facts do.

• There will always be someone who thinks that they know better than you about what you meant by your message. 

To complicate things further, the problem often is with the message itself, rather than with the communications channels. Ambiguities may be the key tools of selected roles in a given situation. For example, if you are a politician, or evangelist seeking to sell a new idea, you likely will favor abstract messages over concrete ones. "We’ll invest all our considerable resources to satisfying the needs of our many constituents" sounds much better than "I’ll spend $10 million of the new taxes you're going to have to pay so I can build a highway that will only benefit my biggest campaign contributor." Finally, when your communications medium is conversational, it does not scale.

The first step in addressing these challenges is to tailor the message to the audience and purpose. Until that is done, it doesn't matter what communications channel you use. Then, realize that there are many reasons why people want (and may even need) to embrace abstract, rather than concrete, concepts:

1. Preferences of communications style

   Part of the reason we often try to use abstract terms is because we are wired to use them to share lessons we have experienced ourselves. Narratives and associated storytelling have become comfortable ways of finding a common history within different cultures, and are used to begin to form agreements with one another for cooperative work. We often work hard for the lessons we've learned in our lives, and we're usually proud of what those experiences have taught us, and enjoy passing those experiences on to others. Abstract terms help us describe things in general ways, rather than relating them to specific events which might not be meaningful to those who have not had our specific experiences.

   Perhaps a friend promises to pick us up at four o'clock, and then leaves us standing there until six. Perhaps your partner promised you a night out on the town, then cancels to do something with someone else. From such experiences, we might realize we can't always trust people. Do we go into each of these specific stories with someone we are mentoring who is in a related situation? More probably, we just tell them "Some people will let you down." It may have taken many concrete, specific experiences to teach you such a lesson, but you try to pass it on to another person with a few general words. Your mind has captured the pattern, and likely has associated it with your perceived risk about unfortunate future circumstances.

   By using abstractions, you may think you will be able to more quickly communicate with your mentor, transferring your lesson without their pain. Unfortunately, the old adage, "No pain, no gain", applies here; the emotional impacts are what originally enabled you to learn this lesson, and the abstract concept which you categorized it as only occurred after the fact. "Some people will let you down" may be a fine title for an essay - but if you want to transfer such lessons reliably, you'll have to communicate the concrete, specific details, and provide an opportunity for dialog with the individuals who have to put such principles into action (perhaps answering their hard questions about when you should trust people, and when you shouldn't). Otherwise, the lessons you are seeking to transfer may not be exchanged successfully.

2. Desire to hide disagreements and promote morale

   Abstract language is often used as a way of pretending that concrete disagreements don't exist. Unfortunately, this often results in use of 'business speak' (or BS) - generalities that no one can honestly achieve, but everyone can collectively engage in the pursuit of.

3. Underestimating the future costs of ambiguity
   

   As long as things are kept at an abstract level, no tradeoffs have to be made. Yet when push comes to shove, and specific, concrete actions must be implemented, constraints suddenly emerge - usually over time, money,  throughput, or critical resources. An optimist believes that it will be easier to address such constraints and tradeoffs in the future than it will be at present. Determining how to respond to these constraints typically requires a level of common understanding that abstractions will not provide. Decision-makers must have access to meaningful, concrete facts and data to make their decisions, yet such information may not be available if ambiguity has not been isolated and progressively eliminated. The quality of their decisions will directly depend upon the timeliness and integrity of this information, because in such situations, decisions cannot wait for better data to be produced. This is a classic example of one of the hidden costs of abstractions.

4. Gaps in subject matter expertise

   There may be a lack of detailed understanding of the nature or implications of subject matter among those who are communicating. This typically manifests itself in an inability to express exactly what would be required to close these gaps in a given situation (often expressed as "I'll know it when I see it").

5. Insufficient foundation for meaningful communications to occur

   A sufficient foundation may not yet have been established for effective communications. Such a foundation typically includes a standardized terminology, upon which other concepts are based, and that all users can then derive their own planning and principles from. There also may be a forum for the disambiguation of terminology as it is being used, and according to the context in which these terms occur. This is especially true when different people in the communications channel have different contexts or domains that they are operating from.

The terminology which we use may be concrete, yet still may be general, rather than specific. General terms and specific terms are not opposites, as abstract and concrete terms are; instead, they are the different ends of a range. General terms refer to groups, while specific terms refer to individuals, with room in between. Let's look at an example.

Furniture is a general term; it includes within it many different possibliities. If I ask you to form an image of furniture, it won't be easy to do. Do you see a department store display room? a dining room? an office? Even if you can produce a distinct image in your mind, how likely is it that another person will form a very similar image in their own mind? While furniture is a concrete term (it refers to something we can see and feel), its meaning is still hard to pin down, because the group is so large. is it possible to form positive or negative feelings toward furniture? Again, it's hard to develop much of a response, because the group represented by this general term is just too large.

If we make the categorization smaller with the less general term, chair, it's easier to picture a chair than it is to picture furniture. But let's shift our thinking next to a more specific term, like a rocking chair. Now the image is getting clearer, and it's easier to form an attitude toward the thing. The images we develop in response to this specific term are more likely to have similar functionality (though may still differ in size, materials, design, and fabrication). We are therefore much more likely to have similar emotional associations (comfort, relaxation, calm). The less general or more specific a term is, the more clearly it will communicate desirable emotional responses than the more general or less specific terms we might have used before such details were available. We can become more and more specific. Our focus can become a lime green velvet La-Z-Boy rocker recliner with a cigarette burn on the left arm and a crushed jelly doughnut pressed into the back edge of the seat cushion. By the time we get to this last description, we have become very specific, and it is much easier to visualize how we might interact with it. Since our minds are pattern recognizers, when we encounter something new, we try to plug that thing into our minds by relating it to something from our past. If our history included an incident in which we were punished for damaging such a chair, our response would likely be negative rather than positive. This is the risk and the reward inherent in making things more concrete.

In leading a development team, our collective objectives should not be to cloud our intentions, misrepresent what we are building, or pass on ambiguity to others downstream, thinking that somehow things will automatically become clearer with time. Instead, everyone's goal should be to identify the actions required to collect and communicate required information to the stakeholders who must use that information, so they can perform their work effectively. There may be a role for abstractions early in these communications exchanges, but generally, we should seek to have as many of these exchanges as possible be based upon concrete specifics.

Typically, most development efforts are well served by using abstractions as themes within which detailed requirements are captured. Some guidelines will help to frame the characteristics of such requirements. The following steps can help to begin addressing project ambiguities by establishing an appropriate concrete requirements baseline for your project:

1. Begin with the end in mind - what are you trying to accomplish, and for whom?
2. Actively manage the scope of your endeavor - explicitly define what is and is not 'in' that scope, in terms of organizations, customers, products, roles, and resources. Do this for a well-defined period of performance, while preserving the ability to tweak this in later iterations.
3. Identify the reference domain knowledge and terms of reference which are necessary for understanding the focus and context for the endeavor.
4. Solicit and elicit inputs from a broad cross-section of stakeholders to identify the key abstractions that require elaboration, and how those relate to each other and to the architecture envisioned for solutions.
5. Adopt a standard format and repository for how such terms should be described (their definition, interrelationships, etc)
6. Apply George Orwell's six rules from Politics and the English Language to all writing.
7. Provide a means of rationalizing and normalizing inputs about those terms into a composite work product
8. Implement a review and feedback system which assures that the resulting work product is reviewed by knowledgable subject matter experts periodically, using an appropriate quality checklist, and that issues associated with those reviews are given sufficient attention so they are resolved in a timely fashion
9. Establish a change management plan for requesting changes to this work product, publishing concensus decisions on the proposed diusposition of those changes, and providing visibility of in-work items
10. Provide a means to align efforts on the project with this information as it evolves, and a means to track that alignment over time.