The leadership and team members on development projects often use language whose meaning is ambiguous. Unraveling the possibilities underneath their different concepts can be quite challenging. But if you don't confront and solve those challenges, it can cause considerably more pain later, as these misunderstandings must eventually be reconciled. 

Success in development endeavors relies upon effective communications. Such communications involves developing and agreeing on a common, foundational understanding of the underlying key concepts that are threaded through such projects. Achieving such understanding usually requires careful listening, disciplined and coherent integration, and reconciliation of the ideas being expressed by different stakeholders over time. It also requires clear and thorough probing into the implications behind their emerging meaning(s) and reasoning(s), in multiple situations, and under different scenarios. 

The unfortunate fact is that communications will nearly always fail to some degree. This is because transmitters and receivers do not always validate their understandings, beliefs, or contexts during their exchanges. The mediums used to communicate information often have limitations, and may inject noise and delays into the process. And both transmitters and receivers typically have filters which affect receiption of messages, no matter how clear or detailed.

As these communications breakdowns occur, ambiguity is unfortunately always injected into the message, as placeholders search for what the real requirements are. This is especially apparent as people begin to use verbs with relative terms (improve, minimize, maximize, optimize…) without establishing a measurable target that would answer the question "By how much?". Such ambiguity can then lead to fruitless exchanges like the classic Bring Me A Rock exchanges that nearly everyone has experienced.

Abstract terminology is often one of the biggest source of such hand waving. Abstract terms refer to ideas or concepts which have no direct physical embodiment. You can’t measure or count an abstraction, but development projects are full of them. In every day life, we regularly use concepts like love, success, freedom, goodness, and justice. But when we use such terms, we may not have the same meaning in mind of exactly what such words mean that our audience does. For example, we might verbally express love, but not exhibit any of the things that our listeners might be expecting a loving person to do; such mixed signals obviously would confuse our listeners.

If you try to explore the meaning behind such abstract terms, you’ll often find that the meaning of such terms is often situationally or temporally dependent, and the meaning therefore can vary according to the speaker's point of view. For example, the meaning of the word love changes as we grow up, when we marry, as we have children, if we are divorced, or when we reflect on lost ones. Similarly, if we consider a word like freedom, it will be familiar enough, but if I say, "I want freedom," what am I talking about? Self-employment? An extended vacation? Paid-off debts? Separating from a relationship? Owning my own home or car? Finding looser jeans? Suddenly, the meaning of of the word won’t hold still. Yet such concepts remain quite powerful to motivate and focus action - without the concept of freedom, creativity and innovation are more difficult to achieve; yet with too much freedom, chaos can reign. Striking the right happy balance with respect to an abstract concept like freedom can take time and effort. This is especially so if we think we all mean the same thing, and yet in practice, don't discover how different our views are until we begin diving into the details!

Such abstractions exist in many areas within development efforts, and can trip everyone up, if team members believe that they are communicating, when indeed they are not. Such abstract terms may even already be in wide use, and may even be presumed to be understood within the development team. But there will nearly always be abstraction leaks.

For example, consider the term success. What exactly does success mean, in terms of cost, schedule, and quality? Can we measure it? Is there anything about those measures that could make them unreliable as indicators of our ability to achieve success? Is there freedom to emphasize some of these dimensions more than others? Do the customer and program manager have the same perspective on what this success looks like? How about the development team? As the project environment evolves over time, how are these various factors re-balanced with the new situation?

We need abstract terms, in order to talk about ideas and concepts, and we use placeholders for them in the words we use.  They are helpful and necessary when we want to name such ideas, but they are limited in what they can do for us, and may in fact cause more problems than we realize. For instance, when they become the basis of anyone 'taking ownership' of such a concept within a project or an organization, that individual must develop effective ways to scope, refine, and communicate those expectations, fully elaborate the underlying elements associated with the term itself, allocate responsibilities for those elements, and hold accountable those who must achieve those ends. Until this occurs, everyone's just gathering rocks.

Instead of blindly adopting abstract terms without refining our definitions of what we mean by them, we must work to elaborate such abstract terms until they are concrete. Concrete terms refer to objects or events that can be recognized, counted, and occupy a physical extension. Examples of concrete terms include wheels, tables, clouds, nose rings, and walking sticks. Because these terms refer to physical objects, we can see, hear, feel, taste or smell them, and their meanings are much easier to understand and apply. If you ask me what I mean by the word wheel, I can pick up one and show it to you. I can’t pick up a freedom and show it to you, or point to a small democracy crawling along a window sill. I can measure cement and gasoline by weight and volume, but I can’t weigh a pound of responsibility or restrict my intake to less than a liter of moral outrage.

While abstract terms like love can change meaning with time and circumstances, concrete terms like spoon stay pretty much the same. A wbeel or a cloud means pretty much the same to you now as they probably did when you were four. This doesn't mean it would be easy to write an algorithm to detect fog (for example, to decide if we are in a fog bank, cloud, snow, or in heavy rain). But it does mean that we can describe the characteristics of such states (and the corresponding patterns of our experiences as we interact with them) so the object of interest can become familiar, reliably recognized, and more readily acted upon, when we chose to.

Translating abstract terms into concrete ones enables a group to get specific about the problems they are solving. You may think you understand and agree with me when I say, "We all want success." But surely we don’t all want the same things. Success means different things to each of us, and you can’t be sure of what I mean by just using that abstract term. On the other hand, if I say "I want a swimming pool in my back yard, and a Porsche in my driveway," you will have a somewhat more concrete understanding of what I mean (once you find out the size of the pool, and the condition of the Porsche). You'll also be more able to relate whether you want the same things or different things). This doesn't mean you can't continue describing things in even more detail (a red 2008 Porsche Boxer, for example). But by just indicating my desire for that particular car type (over other potential candidates), I've framed the possibilities considerably. In this way, concrete terms are clearer and more interesting than abstract terms, for those who must deliver solutions to problems.

The following articles offer insights about the drivers and motivations of people in using such abstract terms, and offer tips on how to de-fog this ambiguity - by zeroing in on what people want, what decisions need to be made, and how to manage the opportunity value for your stakeholders - thus clearing out enough of the fog and uncertainty for teams to make real and focused progress.