Home

Pflogging

the never-ending quest for pragmatic solutions, useful plans, flawless execution, and designs that endure

Navigation

  • Create
    • Create content
    • Modify attributes
  • Navigate
    • Home
  • Site features
  • Areas of interest
  • Blogs
  • Quotes
  • Technology
  • Demonstration
    • View scheduled work for current day
  • Support
    • Contact me
Home Areas of interest Conventional wisdom Execution discipline

User login

  • Create new account
  • Request new password

A number of key features are only available to registered users. They include:

  • Access to the full content of top-rated material (only teasers are available to anonymous users after the material has been posted for 45 days)
  • The ability to search site content
  • The ability to access reviews of books relevant to site material
  • The ability to access key quotes relevant to site material
  • The ability to access content from partner sites
  • The ability to rate material
  • The ability to post comments
  • The ability to post new information and propose it for publication
  • The ability to request email notification when selected content is added or updated

Translating abstract needs into concrete actions

  • View
  • links
Submitted by Bryan Pflug on Sat, 10/25/2008 - 08:38.
  • Execution discipline
  • Change management
  • Issue management
  • Requirements-driven development
  • Risk management
Towards the lightPeople that are on a development project often use language whose meaning is ambiguous. Unravelling this lack of clarity be a tricky thing to do. Development relies upon effective communications, and achieving this foundational capability requires that all parties consistently understand the meaning behind the words that they are using. Such understanding usually requires careful listening, disciplined synthesis of concepts, and clear and written elaboration and allocation of derived details. Each of these steps involves conscientious and persistent attention in order to be successful.

Abstract terminology is often the biggest source of such ambiguity. Abstract terms refer to ideas or concepts which have no direct physical embodiment. You can’t measure or count an abstraction. For example, concepts like love, success, freedom, goodness, and justice are all abstract terms. While people use such terms all the time, they probably do not have a shared understanding of exactly what they mean when they use them. For example, a speaker might verbally express love, but not exhibit any of the things the things that a listener might be expecting a loving person to do, and thus confuse the listener by these mixed signals. Such a shared understanding can thus be at the core of trust, which is an essential ingredient to the chemistry of any team.

When you try to explore different uses of such abstract terms, you’ll typically find that the meaning of such terms is often situationally or temporally dependent. 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. How about a word like freedom? The word is familiar enough, but when I say, "I want freedom," what am I talking about? Divorce? Self-employment? An extended vacation? Paid-off debts? Owning my own home or car? Finding looser jeans? The meaning of this word - freedom - suddenly won’t hold still. Yet without this concept of freedom, creativity and innovation are more difficult to achieve; yet with too much freedom, chaos can reign. Thus, striking a happy balance for achieving freedom can be awkward - especially if we think we all mean the same thing, and yet in practice, don't even know what it means!

Equivalent abstractions exist in most development efforts, and can trip everyone up, as team members believe that they, too, are communicating, when indeed they are not. Such abstract terms may even be in common use and be familiar within the development team; because we all use and recognize such terms, everyone may think that they understand one another when they are using them.  For example, an important abstraction that usually needs to be clarified on any project is the term success. What exactly does that mean, in terms of cost, schedule, and quality, and is there more flexibility in some of these dimensions than in others?

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, they may be problematic if they are the basis of anyone 'taking ownership' of any concept that's important to an organization, since their meaning can be so slippery. Or if people do accept responsibility for such concepts, it may well be arguable about whether they've really been - well - successful in their efforts.

Instead of blindly adopting abstract terms without defining 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 pretty stable. 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 did when you were four. This doesn't mean it would be easy to write an algorithm to detect fog with a sensor device (say, to decide if we are in sunshine, a fog bank, snow, or in heavy rain). But it does mean that the characteristics of such objects (and the corresponding patterns of our experiences) can become familiar, reliably recognized, and acted upon.

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 that abstract term. On the other hand, if I say "I want a swimming pool in my back yard, and a Porche in my driveway," you will have a more concrete understanding of what I mean (and 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 Porche Boxer, for example). But by just indicating my desire for that particular car type (over other potential car types), I've framed the possibillities considerably. In this way, concrete terms are clearer and more interesting than abstract terms.

The following articles offer insights about the drivers and motivations of people when they using these abstract terms, and offer tips on how to de-fog this ambiguity, in what people want, what decisions need to be made, how to handle unforseen problems, and how manage the flow of value to your customers.


Average rating
 
 
 
 
 
(0 votes)
  • The risks of ambiguity
  • What drives us to ambiguity?
  • Recognizing and prioritizing the stuff to be done
  • The objects of our affection
  • Defining what you love
  • Judgements with justice
  • Soon is not a time
The risks of ambiguity ›
  • Login or register to post comments

Copyright

Copyright © 2009 Pflogging
All Rights Reserved
RoopleTheme